[dnssec-deployment] DNSSEC in Russia

[bmanning at vacation.karoshi.com]

On Thu, Apr 02, 2009 at 04:05:16PM +0000, Lutz Donnerhacke wrote:
> * bmanning at vacation.karoshi.com wrote:
> >> That's not that easy. Please remember the constraint, that the query
> >> response for "DNSKEY . +dnssec" must fit into an UDP packet. So we have at
> >> most space for two keys and signatures, in order to allow seamless key
> >> rollovers.
> >
> > 	and just for completeness, what is the size of an unfragmented UDP
> > 	packet these days?
> 
> 1400 Bytes = 10000 usable bits for keys and signatures.
>            =  5000 usable bits for keys
> 	   =  2500 usable bits for KSKs
> 	   = a single 2048bit KSK and two 1024bit ZSKs (incl. rollover)
> 

	Not sure thats how I read RFC 2671...  
-----
4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
     field) is the number of octets of the largest UDP payload that can
     be reassembled and delivered in the sender's network stack.  Note
     that path MTU, with or without fragmentation, may be smaller than
     this.

4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
       reassembly buffer.  Choosing 1280 on an Ethernet connected
       requestor would be reasonable.  The consequence of choosing too
       large a value may be an ICMP message from an intermediate
       gateway, or even a silent drop of the response message.

and

4.5.5. Due to transaction overhead, it is unwise to advertise an
       architectural limit as a maximum UDP payload size.  Just because
       your stack can reassemble 64KB datagrams, don't assume that you
       want to spend more than about 4KB of state memory per ongoing
       transaction.
-----
	that being said, my handy local OS seems to think that a 
	9k UDP packet is just fine, thank you.  I think I have room
	for a few more keys and signatures than the two you seem to 
	be constrained to.

	And think of poor Ray!  He's stuck behind some crap CPE that
	drops everything larger than 512.  He's going to have a tough
	time w/ anything of reasonable strength.

	Clearly EDNS(0) support is a requirement ... and with that in place,
	I suspect that we might even get  enough keys/sigs in multiple alogrithms
	into a packet.

--bill