On Thu, Oct 15, 2015 at 8:06 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> <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 TTL's are part of the zone, transferred from the master, and should not vary by name server, if I understand correctly. Does DNSSEC signing not cover the important glue records? If we could get them signed, I think it would be more secure, but it might be too late for a change like that. As for whether the parent and child agree on the TTL's is a separate issue. I believe that the child TTL's usually overwrite the parent TTL's in a resolver's cache. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
