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

Mark Andrews <marka@isc.org> Fri, 16 October 2015 04:06 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255241ACE59 for <dnsop@ietfa.amsl.com>; Thu, 15 Oct 2015 21:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGoe6PEV7uDz for <dnsop@ietfa.amsl.com>; Thu, 15 Oct 2015 21:06:10 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2581ACD8C for <dnsop@ietf.org>; Thu, 15 Oct 2015 21:06:10 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 10ED3349315; Fri, 16 Oct 2015 04:06:08 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 50BCF160045; Fri, 16 Oct 2015 04:06:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 3D34F16004F; Fri, 16 Oct 2015 04:06:11 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id q5Znq7Ssn59R; Fri, 16 Oct 2015 04:06:11 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id B5BA4160045; Fri, 16 Oct 2015 04:06:10 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 032E23A93C71; Fri, 16 Oct 2015 15:06:04 +1100 (EST)
To: Paul Hoffman <paul.hoffman@vpnc.org>
From: Mark Andrews <marka@isc.org>
References: <8149BC4D-F11E-4E4F-BBB8-C38D865A4184@vpnc.org>
In-reply-to: Your message of "Thu, 15 Oct 2015 17:06:11 -0700." <8149BC4D-F11E-4E4F-BBB8-C38D865A4184@vpnc.org>
Date: Fri, 16 Oct 2015 15:06:04 +1100
Message-Id: <20151016040605.032E23A93C71@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/MHqPWI_d__MAp-4lsDarrtrUVro>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] Closing out issues in draft-ietf-dnsop-resolver-priming
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2015 04:06:12 -0000

In message <8149BC4D-F11E-4E4F-BBB8-C38D865A4184@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: marka@isc.org