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

Robert Edmonds <edmonds@mycre.ws> Wed, 18 March 2015 21:29 UTC

Return-Path: <edmonds@mycre.ws>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 449971A90EC for <dnsop@ietfa.amsl.com>; Wed, 18 Mar 2015 14:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5aNXtDIgDS6D for <dnsop@ietfa.amsl.com>; Wed, 18 Mar 2015 14:29:51 -0700 (PDT)
Received: from chase.mycre.ws (chase.mycre.ws []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5085B1A90DC for <dnsop@ietf.org>; Wed, 18 Mar 2015 14:29:50 -0700 (PDT)
Received: by chase.mycre.ws (Postfix, from userid 1000) id 72D2515650E1; Wed, 18 Mar 2015 17:29:49 -0400 (EDT)
Date: Wed, 18 Mar 2015 17:29:49 -0400
From: Robert Edmonds <edmonds@mycre.ws>
To: dnsop@ietf.org
Message-ID: <20150318212949.GA22886@mycre.ws>
References: <20150318025644.GA10290@mycre.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20150318025644.GA10290@mycre.ws>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/RhL7Ts0nAAFPEBy1n763uGDaYh0>
Subject: [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: Wed, 18 Mar 2015 21:29:53 -0000


draft-hoffman-dns-terminology-02 has the following definitions:

   In-bailiwick response -- A response in which the name server
   answering is authoritative for an ancestor of the owner name in the
   response.  The term normally is used when discussing the relevancy of
   glue records.  For example, the parent zone example.com might reply
   with glue records for ns.child.example.com.  Because the
   child.example.com zone is a descendant of the example.com zone, the
   glue is in-bailiwick.

   Out-of-bailiwick response -- A response in which the name server
   answering is not authoritative for an ancestor of the owner name in
   the response.

A few comments:

 * A zone can't send a reply; the authoritative server for a zone can.

 * "Response" isn't defined(!), nor is "reply".  I was (pedantically)
   thinking of an RFC 1035 §4 message with the QR bit set to 1 at first,
   but that doesn't fit well in the context of "the owner name in the
   response", because a response message can contain RRs with different
   owner names, and records within a response message can be
   individually considered in-bailiwick or out-of-bailiwick.  It would
   be good to clarify which owner name is being compared.

 * RFC 5452 §6, though it uses "in-domain" rather than "in-bailiwick",
   uses the concept of "deeming" the authoritativeness of a record.
   RFC 3833 §2.3 refers to "the long-standing defense of checking RRs in
   response messages for relevance to the original query".  I think
   these two RFCs are alluding to the same or a similar bailiwick
   concept being defined here.

   Is "in-bailiwick" / "out-of-bailiwick" a property of the data in the
   DNS and how authoritative servers are configured to use it, or is it
   a determination (a "deeming") by a recursive server that the data has
   this property?  I favor the latter, because it is useful to have
   dedicated terminology for the process of determining a server's
   authority, but maybe a separate definition would be helpful:

   Bailiwick checking -- The process of determining whether a record in
   a response message should be considered "in-bailiwick" or

Robert Edmonds