Re: [DNSOP] Priming query transport selection

[Simon Leinen <[e-mail]>]

Olafur Gudmundsson writes:
> 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.

After reading the entire discussion, I support Olafur's suggestion in
this form.  It's simple enough, and it falls back gracefully if TCP
somehow fails to work.

As for whether we should "encourage more TCP usage of DNS": I really
believe that this is a non-issue.  Priming queries from sane
implementations that follow the specs are NOT what we should be worried
about.  Sure, TCP requires more resources than UDP, especially as
implemented in today's nameservers.  That's why it is important to have
a fallback to UDP for priming: Otherwise it would be too easy for an
attacker to stop resolving nameservers in their tracks during startup.

As to Ed's point that how priming works is not that relevant, especially
with DNSSEC at the root: That's probably true.  But I also sympathize
with Olafur's desire for a warm fuzzy feeling about priming.  Plus, it
would provide a nice opportunity to log issues with TCP queries early
on, with a high chance for server operators to actually notice.
-- 
Simon.