In message <8149bc4d-f11e-4e4f-bbb8-c38d865a4...@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: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
