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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, "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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]