[dnsext] comments on draft-crocker-dnssec-algo-signal-03

[Michael Graff <[e-mail]>]

Let me state some reasons I'm opposed to this draft's purpose, even 
though I think some part of it would be very interesting to pursue.

(1)  This becomes a meta-type in practice.  It might prevent some 
lookups initially, but should a client ask for items that were not in 
the cache, the server would have to remember which algorithms it saw in 
the DNSKEY response to know which it could usefully retrieve with 
follow-on queries.  For example, a particular stub might support more 
algorithms than the cache it asks, so additional queries (including 
additional queries for the DNSKEY to obtain its signatures) would have 
to be generated.

(2)  This solves a problem I do not fully believe is a problem, that of 
TCP fallback.  I've said it before, but chat servers, web servers, and 
other types of TCP-based servers handle many, many connections/sec and 
many, many sustained clients today.  I don't understand why DNS is 
different here, excepting perhaps that we have not encountered this 
situation until now.

(3)  It solves a problem that I do not fully believe is a problem, that 
of fragmented packets.  There is no solid solution in this proposal that 
it WILL get packets through, only that it might have a better chance to 
do so.  Key rollover will still cause large packets and/or TCP fallback, 
which means only during rollover events will badness occur.  I'd rather 
it occur all the time rather than only in some situations.

(4)  I believe the knowledge it would allow to be gathered -- that of 
which algorithms, hashes, etc. were in common use -- is very valuable. 
Perhaps a draft on "voluntary reporting of server capabilities" would be 
useful, where the data would be anonymous, infrequently (order days at 
least) reported, and collected into reports.  Knowing that RSA/SHA1 is 
not used any longer is very good information to know in terms of 
deprecating protocols, but using that as a filter seems unwise to me.

--Michael

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>