[DNSOP] Priming query transport selection

Olafur Gudmundsson <ogud@ogud.com> Wed, 13 January 2010 18:19 UTC

Return-Path: <ogud@ogud.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 736873A6A38 for <dnsop@core3.amsl.com>; Wed, 13 Jan 2010 10:19:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.685
X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id gaNhEeAsolad for <dnsop@core3.amsl.com>; Wed, 13 Jan 2010 10:19:37 -0800 (PST)
Received: from stora.ogud.com (stora.ogud.com []) by core3.amsl.com (Postfix) with ESMTP id 4BA793A6860 for <dnsop@ietf.org>; Wed, 13 Jan 2010 10:19:37 -0800 (PST)
Received: from valholl.ogud.com (nyttbox.md.ogud.com []) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0DINxYv068180 for <dnsop@ietf.org>; Wed, 13 Jan 2010 13:23:59 -0500 (EST) (envelope-from ogud@ogud.com)
Message-Id: <201001131823.o0DINxYv068180@stora.ogud.com>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 13 Jan 2010 13:19:30 -0500
To: dnsop@ietf.org
From: Olafur Gudmundsson <ogud@ogud.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.67 on
Subject: [DNSOP] Priming query transport selection
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 13 Jan 2010 18:19:38 -0000

Draft http://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-02
"2.1.  Parameters of a Priming Query

    A priming query SHOULD use a QNAME of "." and a QTYPE of NS.  The
    priming query MUST be sent over UDP (section of [RFC1123]).
    The UDP source port SHOULD be randomly selected [RFC5452].  The RD
    bit MUST NOT be set.  The resolver SHOULD also use EDNS0 [RFC2671]
    and announce and handle a reassembly size of at least 1024 octets

    [[Do we need a fallback strategy for EDNS unfriendly environments?]]

Going forward I think this is a bad recommendation.  I would like to
propose that the document take the plunge of recommending that
modern DNSSEC capable resolvers perform the priming query over TCP.

The benefit is that a single query can retrieve the signed root NS set
and all the signed glue records.
The alternative is that a resolver that really cares about DNSSEC will have
to issue up to 27 UDP queries in order to get all the records that are
related to the NS set.

26 signed glue records will require about 5K answer if each RRSet is
signed by a single 1024 bit RSA key.
This will never fit into an ENDS0 answer as number of implementations
have 4096 byte hard limit on answer size.
As of today all the root servers instances that my host reached answered a TCP

Proposed replacement text:
    A priming query MUST use a QNAME of "." and a QTYPE of NS, QCLASS of IN,
    with RD bit set to 0, the source port of the query should be randomly
    selected [RFC5452].

    A DNSSEC aware resolver SHOULD sent the priming query over TCP.
    If TCP is refused a different server SHOULD be tried, after 3 tries
    the resolver SHOULD fall back on UDP.

    A DNSSEC ignorant but EDNS0 capable, resolver SHOULD issue the
    priming query over UDP, ENDS0 option MUST be included with buffer
    size of 1220 or larger.  If the UDP query times out TCP SHOULD be tried.

    An EDNS0 ignorant resolver MUST issue the priming query over UDP.

By making this change section 2.4 can be dropped, the one
on not asking for signed answers.

In section 2.2 the draft allows "pre-fetching" of the priming answer when
75% of TTL has passed. I think this should be higher more like 85%..95% or
a fixed minimum time like 6 hours.

IANA consideration section mentions TTL recommendations for the root zone, but
does not make any, I think the document should document what the current values
are and the group should pass a comment if it thinks the values are 
reasonable or
can be improved. If the values are going to change based on signature 
life times
when the root is signed then that should also be reflected in the document.