<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.
[[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
