> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
