Re: [DNSOP] signing glue and additional data

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

----- Original Message ----- 
From: "Jim Reid" <[e-mail]>
To: "George Barwood" <[e-mail]>
Cc: "IETF DNSOP WG" <[e-mail]>
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 @a.ns.se + dnssec
> 
> No it doesn't. The name servers for .se are authoritative for the  
> address records for *.ns.se. And ns.se isn't delegated either. The A  
> and AAAA records for *.ns.se 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

http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg02647.html

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

Regards,
George