Re: [DNSOP] Priming query transport selection

"George Barwood" <> Sat, 16 January 2010 11:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 635BD3A6921 for <>; Sat, 16 Jan 2010 03:18:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.824
X-Spam-Level: **
X-Spam-Status: No, score=2.824 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=0.001, HELO_EQ_BLUEYON=1.4, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zuwmc7jt+32V for <>; Sat, 16 Jan 2010 03:18:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 53F6A3A6774 for <>; Sat, 16 Jan 2010 03:18:08 -0800 (PST)
Received: from [] (helo=anti-virus02-10) by with smtp (Exim 4.52) id 1NW6fJ-0005C0-V6; Sat, 16 Jan 2010 11:18:02 +0000
Received: from [] (helo=GeorgeLaptop) by with esmtpa (Exim 4.52) id 1NW6fJ-0004lM-Cy; Sat, 16 Jan 2010 11:18:01 +0000
Message-ID: <C7567F001CD94F1891C91E162FD5316B@localhost>
From: George Barwood <>
To:, Olafur Gudmundsson <>
References: <> <C70EBA7D41694531819FB0923455C684@localhost>
Date: Sat, 16 Jan 2010 11:17:56 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5843
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: Re: [DNSOP] Priming query transport selection
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 16 Jan 2010 11:18:09 -0000

> 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 + dnssec

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

dig soa 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 )
"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 ( A )
(2) An RRSIG record 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.