Re: [DNSOP] Priming query transport selection

["George Barwood" <[e-mail]>]

> Why would glue records be signed? That's not normal in DNSSEC, AFAIK.

To correct my statement, the following query shows that glue records may be signed

dig soa se @a.ns.se + dnssec

wich has a response size of  2944 bytes. However, most of this is Additional Section RRSIGS, and

dig soa se @a.ns.se + dnssec +bufsize=700

shows that the "vital" data is much smaller, and truncation will not ocur for 
an EDSN0 buffer size of say 1400 bytes. The same will apply for the priming query.

The question then is "is the additional RRSIG data useful" ?

My answer is "probably not".

DNS data can be broadly classified as 

"User data" ( e.g. A record for www.google.com )
"Name server data" ( e.g. NS records, and the associated A and AAAA records )
"Signature data" ( e.g. RRSIG, DS and DNSKEY records )

In order to obtain validated User data, a client needs 

(1) The record itself ( www.google.com A 1.2.3.4 )
(2) An RRSIG record  www.google.com RRSIG ..... )
(3) The appropriate chain of signed DNSKEY / DS records.

It's not necessary for the "name server data" to be signed at all, that data
is merely used to locate servers where the essential secure data is located.

It might be argued that having signatures for the "Name server data" increases
some warm fuzzy feeling, and prevents some Denial of Service attacks.
But DNSSEC is not designed to prevent "Denial of Service" attacks.
Some "Denial of Service" attacks may be prevented by using stronger
transport, but generally I don't think these attacks are too much of a concern.

There is a particular type of Denial of Service attack that might be prevented
by signing "Name server data". For example, suppose a particular root server
has been compromised, and is issuing bad data. If the client checks the signature
of the "name server data", it can detect the bad data, and try another root server.

So, as I see it, the question is whether it's worth preventing a certain class
of Denial of Service attacks ( and also accidents where a name server is
mis-behaving ).

I think this is up to recursive resolver. Some resolvers may choose to validate
"Name server data", at a small cost in performance, others may choose not to
( or adopt hybrid strategies : assume name server data is ok until a failure occurs,
and then back up and start checking, or check as a background activity ).

Therefore I would argue that the priming query transport need not be specified
in the standard.

George