Re: [DNSOP] DNS terminology: "In-bailiwick response", "Out-of-bailiwick response"

Andreas Gustafsson <gson@araneus.fi> Thu, 19 March 2015 08:12 UTC

Return-Path: <gson@araneus.fi>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137371A6EF1 for <dnsop@ietfa.amsl.com>; Thu, 19 Mar 2015 01:12:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fo4b4H-iHVy7 for <dnsop@ietfa.amsl.com>; Thu, 19 Mar 2015 01:12:54 -0700 (PDT)
Received: from gullfoss.araneus.fi (gullfoss.araneus.fi [151.236.24.64]) by ietfa.amsl.com (Postfix) with ESMTP id ADD921A894E for <dnsop@ietf.org>; Thu, 19 Mar 2015 01:12:53 -0700 (PDT)
Received: from guava.gson.org (a91-153-49-205.elisa-laajakaista.fi [91.153.49.205]) by gullfoss.araneus.fi (Postfix) with ESMTP id 03AB43C25D; Thu, 19 Mar 2015 08:12:21 +0000 (UTC)
Received: by guava.gson.org (Postfix, from userid 101) id B7009745890; Thu, 19 Mar 2015 10:12:19 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <21770.34019.512024.758709@guava.gson.org>
Date: Thu, 19 Mar 2015 10:12:19 +0200
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: Re: <C3E84A72-AD36-4574-ADE5-646ECF7754D3@vpnc.org>
References: <20150318025644.GA10290@mycre.ws> <20150318212949.GA22886@mycre.ws> <C3E84A72-AD36-4574-ADE5-646ECF7754D3@vpnc.org>
X-Mailer: VM 8.0.14 under 21.4.1 (x86_64--netbsd)
From: Andreas Gustafsson <gson@araneus.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/BiSNr-5NEbvIjP4Py6UUeql0Fjs>
Cc: Robert Edmonds <edmonds@mycre.ws>, dnsop@ietf.org
Subject: Re: [DNSOP] DNS terminology: "In-bailiwick response", "Out-of-bailiwick response"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 08:12:56 -0000

Paul Hoffman wrote:
> Further, I disagree with this being about "deeming". There is a
> simple rule (the owner name is a subzone of the answer), whereas
> "deeming" indicates that there might be other logic that is not
> given here.

Bailiwick checking is not checking that the owner name is a "subzone
of the answer", it is checking that the owner name is a subdomain of
the domain whose servers are being queried.

Suppose we are resolving www.example.com and the "best servers to ask"
(in the algorithm of RFC1034 5.3.3, step 2) are the .com servers.  If
one of them responds with "example.com NS ns1.foo.com" and a glue
record with ns1.foo.com as its owner name, this glue record is
in-bailiwick because it is a subdomain of .com, the domain whose
server is being queried, even though it is not a "subzone of the
answer", which I would interpret as "a subdomain of example.com"
rather than "a subdomain of com".

I believe this is also what RFC 5452 means by "One very simple way to
achieve this is to only accept data if it is part of the domain for
which the query was intended".

This is not limited to glue; the same issues arise with records 
in the additional section and with CNAME chains.
-- 
Andreas Gustafsson, gson@araneus.fi