Re: [dnsext] RFC3596: A/AAAA records and additional section processing
Mark Andrews <marka@isc.org> Fri, 04 March 2011 07:00 UTC
Return-Path: <marka@isc.org>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445963A691F for <dnsext@core3.amsl.com>; Thu, 3 Mar 2011 23:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfaMD2FTNV13 for <dnsext@core3.amsl.com>; Thu, 3 Mar 2011 23:00:52 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by core3.amsl.com (Postfix) with ESMTP id CF7E03A68B8 for <dnsext@ietf.org>; Thu, 3 Mar 2011 23:00:51 -0800 (PST)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.ams1.isc.org (Postfix) with ESMTPS id 624F05F983B; Fri, 4 Mar 2011 07:01:45 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 66916216C22; Fri, 4 Mar 2011 07:01:43 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 55FE0BA8196; Fri, 4 Mar 2011 18:01:41 +1100 (EST)
To: Colm MacCárthaigh <colm@allcosts.net>
From: Mark Andrews <marka@isc.org>
References: <AANLkTik6zTfBcq129pX_uQC-adruhVGnk=CjRn29=fpt@mail.gmail.com><AANLkTin_GMbCxTV8XTqMKM5RE=+3uwYSWp2Di_mBwZjU@mail.gmail.com>
In-reply-to: Your message of "Thu, 03 Mar 2011 22:50:46 -0800." <AANLkTin_GMbCxTV8XTqMKM5RE=+3uwYSWp2Di_mBwZjU@mail.gmail.com>
Date: Fri, 04 Mar 2011 18:01:41 +1100
Message-Id: <20110304070141.55FE0BA8196@drugs.dv.isc.org>
Cc: dnsext@ietf.org
Subject: Re: [dnsext] RFC3596: A/AAAA records and additional section processing
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Mar 2011 07:00:53 -0000
In message <AANLkTin_GMbCxTV8XTqMKM5RE=+3uwYSWp2Di_mBwZjU@mail.gmail.com>, =?IS O-8859-1?Q?Colm_MacC=E1rthaigh?= writes: > The good news is that it is standard - section 3 of the same RFC says; > > "3. Modifications to existing query types > > All existing query types that perform type A additional section > processing, i.e., name server (NS), location of services (SRV) and > mail exchange (MX) query types, must be redefined to perform both > type A and type AAAA additional section processing. These > definitions mean that a name server must add any relevant IPv4 > addresses and any relevant IPv6 addresses available locally to the > additional section of a response when processing any one of the above > queries." > > (e.g. dig MX example.stdlib.net @ns-191.awsdns-23.com.) . > > The section you've quoted is just pointing out that a query for a > q-tuple of type AAAA would not normally by itself trigger any > additional-section processing. As worded, I think it's actually wrong. > A query of type AAAA might trigger additional section processing if > the query arrives at the parent of a delegated zone. For example the > query; > > dig AAAA www.google.com @a.root-servers.net. > > plainly does trigger additional section processing. (though one might > argue it was the name, not the type, that pulled the trigger). No. That is not addition section processing. That is referral processing. Additional section processing would be returning A and AAAA to NS queries. > 2011/3/3 Jehan Pag=E8s <jehan.marmottard@gmail.com>: > > Hi all, > > > > I have a small question about the IPv6 resource records extension (RFC359= > 6). > > As section 2.3 states: > > =AB=A0A type AAAA query does not trigger additional section processing.= > =A0=BB. Fine. > > > > But I noticed that some DNS servers (like the one installed on my > > server, a bind 9.7.2) would return the A records in additional section > > on a AAAA query and AAAA records in additional on A queries. > > And when I thought about this, I realized it was a pretty good logics. > > Usually when people will try to contact a server, they will want both > > A and AAAA records. > > So the question is: why wouldn't this be standard? > > Thanks. > > > > Jehan > > _______________________________________________ > > dnsext mailing list > > dnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsext > > > > > > -- = > > Colm > _______________________________________________ > dnsext mailing list > dnsext@ietf.org > https://www.ietf.org/mailman/listinfo/dnsext -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- [dnsext] RFC3596: A/AAAA records and additional s… Jehan Pagès
- Re: [dnsext] RFC3596: A/AAAA records and addition… Colm MacCárthaigh
- Re: [dnsext] RFC3596: A/AAAA records and addition… Mark Andrews
- Re: [dnsext] RFC3596: A/AAAA records and addition… Jehan Pagès
- Re: [dnsext] RFC3596: A/AAAA records and addition… Colm MacCárthaigh
- Re: [dnsext] RFC3596: A/AAAA records and addition… Mark Andrews
- Re: [dnsext] RFC3596: A/AAAA records and addition… Dave Lawrence
- Re: [dnsext] RFC3596: A/AAAA records and addition… Dave Lawrence
- Re: [dnsext] RFC3596: A/AAAA records and addition… Jehan Pagès