Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming
Mark Andrews <marka@isc.org> Fri, 16 October 2015 04:06 UTC
Return-Path: <marka@isc.org>
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 255241ACE59 for <dnsop@ietfa.amsl.com>; Thu, 15 Oct 2015 21:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 EGoe6PEV7uDz for <dnsop@ietfa.amsl.com>; Thu, 15 Oct 2015 21:06:10 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2581ACD8C for <dnsop@ietf.org>; Thu, 15 Oct 2015 21:06:10 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 10ED3349315; Fri, 16 Oct 2015 04:06:08 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 50BCF160045; Fri, 16 Oct 2015 04:06:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3D34F16004F; Fri, 16 Oct 2015 04:06:11 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id q5Znq7Ssn59R; Fri, 16 Oct 2015 04:06:11 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id B5BA4160045; Fri, 16 Oct 2015 04:06:10 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 032E23A93C71; Fri, 16 Oct 2015 15:06:04 +1100 (EST)
To: Paul Hoffman <paul.hoffman@vpnc.org>
From: Mark Andrews <marka@isc.org>
References: <8149BC4D-F11E-4E4F-BBB8-C38D865A4184@vpnc.org>
In-reply-to: Your message of "Thu, 15 Oct 2015 17:06:11 -0700." <8149BC4D-F11E-4E4F-BBB8-C38D865A4184@vpnc.org>
Date: Fri, 16 Oct 2015 15:06:04 +1100
Message-Id: <20151016040605.032E23A93C71@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/MHqPWI_d__MAp-4lsDarrtrUVro>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 16 Oct 2015 04:06:12 -0000
In message <8149BC4D-F11E-4E4F-BBB8-C38D865A4184@vpnc.org>, "Paul Hoffman" writ es: > <secretary hat on> > > Greetings. The WG has a draft, draft-ietf-dnsop-resolver-priming, which > has somewhat fallen off the table, and it is time to bring it back. The > draft has two identified open issues, and the authors would like the WG > to clear those up before issuing a new draft, and then hopefully going > to Working Group Last Call. Because the draft is expired, to review it, > please see: > https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-05 > > The two open issues are in Section 4: > > 4. Requirements for Root Name Servers and the Root Zone > > The operational requirements for root name servers are described in > [RFC2870]. This section specifies additional guidance for the > configuration of and software deployed at the root name servers. > > All DNS root name servers need to be able to provide for all > addresses of all root name servers. This can easily achieved by > keeping all root name server names in a single zone and by making > all > root name servers authoritative for that zone. > > If the response packet does not provide for more than 512 octets due > to lack of EDNS0 support, A RRSets SHOULD be given preference over > AAAA RRSets when filling the additional section. I would recommend that the transport family used to make the query should be the determining factor for which additional records are dropped. * A query over IPv6 gets AAAA records in preference to A records. * A query over IPv4 gets A records in preference to AAAA records. If we want to treat these additional records as glue then TC=1 should be set but the response should also be as fully populated as possible. Then client that: * support TCP will get the full response over TCP. * that only support UDP will get what they can from the truncated response. They will be doing this for other responses. * Those behind broken firewalls that block TCP out loose but they loose anyway on other queries where the response has TC=1. > [[Issue 1: EDNS0 is used as an indication of AAAA understanding on > the side of the client. What to do with payload sizes indicated by > EDNS0 that are smaller than 1024, is open to discussion. At the > time > of writing, some root name servers will fill the additional section > with all available A RRSets, only adding some AAAA RRSets, when > queried over IPv4 without EDNS0. Other servers will deliver more > AAAA RRSets, therefore withholding some A RRSets completely > [RFC4472].]] > > To ensure equal availability the A and AAAA RRSets for the root name > servers' names SHOULD have identical TTL values at the authoritative > source. > > [[Issue 2: Do the TTLs for the root NS RRSet and address RRSets in > the root and the ROOT-SERVERS.NET. zones need to be aligned? In > real > life responses, the address RRSet's TTL values vary by name server > implementation. Is this diversity we can live with? Should the > authoritative source prevail? Is it therefore a protocol issue > rather than an operational choice of parameters?]] > > The question at this point is: what should we do about each issue? > Specific wording is appreciated. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Joe Abley
- [DNSOP] Closing out issues in draft-ietf-dnsop-re… Paul Hoffman
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Mark Andrews
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Tony Finch
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… 宋林健
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Shane Kerr
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Bob Harold
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Joe Abley
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Paul Vixie
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… 神明達哉
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Darcy Kevin (FCA)
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Paul Hoffman
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Paul Hoffman
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Paul Vixie
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Shane Kerr
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Paul Vixie
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Joe Abley
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Shane Kerr
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Darcy Kevin (FCA)
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Joe Abley
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Darcy Kevin (FCA)
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… 神明達哉
- Re: [DNSOP] Closing out issues in draft-ietf-dnso… Suzanne Woolf