Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming

[Bob Harold <[e-mail]>]

On Thu, Oct 15, 2015 at 8:06 PM, Paul Hoffman <[e-mail]> 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