Re: [DNSOP] [dnsext] Re: Priming query transport selection

[Alfred Hönes <[e-mail]>]

Danny Mayer wrote, in a response sent to me, referring to
Olafur Gudmundsson's text proposal quoted in my posting on Jan 13:

>>> Proposed replacement text:
>>>
>>> |2.1.  Parameters of a Priming Query
>>> |
>>> |  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.
>>>
>>> ...
>
> I'm not sure I understand the point to this part. Since this is a draft
> and you would be talking about the next versions of resolvers that would
> be expect to support this (as opposed to existing ones) why would you
> expect there to be any future resolver ignorant of DNSSEC? Aren't we
> trying to make DNSSEC mandatory for future resolvers?
>
> Danny

Danny,
Please note that the quoted block of text wasn't mine, so maybe your
message ought to have be addressed primarily to its author.
But never mind.  It has arrived there and on the lists.

The primary goals of my posting were to point out that:

  - limiting the recommended priming query discussion and advice
    in teh Priming Query draft by a perspective on 1024-bit RSA keys
    and signatures is too narrow-headed if the advice shall last
    for more than a very small couple of years, and

  - with respect to message size issues and efficiency, DNSEXT
    should resume work on ECC keys and signatures for DNSSEC ASAP.

Regarding your argument agaibst Olafur's suggested text, I fear
there will be lots of resolvers for many years that cannot reasonably
be expected to be DNSSEC aware, i.e. performing DNSSEC validation.

I do not want to touch on policy issues -- whether CPE and end
systems are in a better place for providing useful trust by
performing DNSSEC validation than typical large-scale caching
resolvers provided and maintained by ISPs.

However:
DNSSEC is a huge code addition, in particular for embedded TCP/IP
implementations; the proliferation of signature algorithms we are
starting to admit will make things even more complicated.
In contrast, EDNS0 is a rather tiny addition providing general
utility and it indeed really should be supported by such
implementations.
Therefore, I believe that we should give valid advice for such
small-scale implementions as well -- they'll depend on working
priming queries in any case.

As pointed out by other folks in another current thread on DNSOP,
BCP documents should not restrict the advice they are giving to a
single mainstream scenario when the topic is more general in
nature, but better cover various important scenarios.
Thus, I indeed recommend to keep appropriate advice for DNSSEC
unaware resolvers in the Priming Query draft.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+