Re: [DNSOP] signing glue and additional data

"George Barwood" <> Sat, 16 January 2010 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C7413A69F6 for <>; Sat, 16 Jan 2010 06:55:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.639
X-Spam-Level: **
X-Spam-Status: No, score=2.639 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_20=-0.74, 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 oH5y7QzNjwEw for <>; Sat, 16 Jan 2010 06:55:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8FAFD3A69F2 for <>; Sat, 16 Jan 2010 06:55:04 -0800 (PST)
Received: from [] (helo=anti-virus03-10) by with smtp (Exim 4.52) id 1NWA3G-0005Jl-0l; Sat, 16 Jan 2010 14:54:58 +0000
Received: from [] (helo=GeorgeLaptop) by with esmtpa (Exim 4.52) id 1NWA3E-00073q-Vz; Sat, 16 Jan 2010 14:54:57 +0000
Message-ID: <5F83DF543FF0440E8D295E5C5B11C9D6@localhost>
From: George Barwood <>
To: Jim Reid <>
References: <> <C70EBA7D41694531819FB0923455C684@localhost> <C7567F001CD94F1891C91E162FD5316B@localhost> <>
Date: Sat, 16 Jan 2010 14:54:52 -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] signing glue and additional data
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 14:55:05 -0000

----- Original Message ----- 
From: "Jim Reid" <>
To: "George Barwood" <>
Sent: Saturday, January 16, 2010 1:25 PM
Subject: signing glue and additional data

> On 16 Jan 2010, at 11:17, George Barwood wrote:
>> To correct my statement, the following query shows that glue records  
>> may be signed
>> dig soa se + dnssec
> No it doesn't. The name servers for .se are authoritative for the  
> address records for * And isn't delegated either. The A  
> and AAAA records for * in this response are not glue. They would  
> be glue if they were in a referral response from a server for .se's  
> parent.

Ok, you can argue over the definition of what a glue record is.
From the client's point of view, the A record is not authoritative
( although a valid RRsig could prove the A record is authoritative? ).
I was using "glue" here in the weaker sense : "An A record for an in-zone
NS record included in the additional section".

>> The question then is "is the additional RRSIG data useful" ?
>> My answer is "probably not".
> So authoritative servers shouldn't volunteer helpful/relevant data in  
> the Additional Section of a response, should they? If the server's got  
> additional data that might benefit the client -- like an A or AAAA  
> record for a hostname in the RDATA of an answer -- it makes sense for  
> the server to include it provided there's room for that data in the  
> response. That also applies to any RRSIG(s) over that additional data,  
> assuming of course the client had set the DO bit.

It's not clear. You can argue that it's best to include as much additional data
as possible, to minimize the number of transactions. On the other hand if this is at the
expense of a lot of wasted bandwidth, or might cause failures or vulnerabilities for EDNS0
packets > MTU, maybe it's not a good policy. It does depend on whether
the resolver is bothering to validate "Name server data" immediately.

This partly goes back to the question I raised at

where I argued that servers should by default limit EDNS0 responses to ~1500 bytes,
to mitigate amplification attacks and avoid UDP fragmentation problems.