[dnssec-deployment] DNSSEC in Russia

[Eric Osterweil]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Apr 2, 2009, at 8:48 PM, Mark Andrews wrote:

>
> In message <list-17545916 at execdsl.com>, Andrew Sullivan writes:
>> On Fri, Apr 03, 2009 at 09:48:18AM +1100, Mark Andrews wrote:
>>>
>>> 	Well if your OS stupid enough to set DF on IPv4 / UDP packets
>>> 	you get what you ask for.
>>
>> Yes, of course, what we really need is a protocol in which end users
>> need to know whether their OS sets DF on v4 UDP packets.  Yep.   
>> That's
>> gonna be a successful protocol.  I'll just tell my mom to see whether
>> her OS sets DF on v4 UDP packets.
>>
>> And before you say, "How likely is she to be using Linux?" I'll point
>> out that my bank _gave away_ a certain well-known Linux-using netbook
>> as an enticement to move your bank accounts to them (alas, I'd been
>> there for some time, so no netbook for me).
>>
>> Being dismissive of the way certain OSes work is fun and everything,
>> but we have a practical, operational problem to overcome here.   
>> Things
>> are broken according to reports from the field, and insisting that  
>> the
>> field reports can't possibly be right because RFC NNNN says so
>> suggests we might have fetishized the standards over the end goal
>> (which I think is getting things that work).  We can stamp our feet  
>> as
>> much as we like about non-conformance with various bits of protocol:
>> it will do us no good.  We have to make our stuff attractive so that
>> people can't see a better way to achieve the same goal.
>> (Alternatively, we can shut up and wait for something barely designed
>> to take over.)
>
> 	The same email also showed that named at least works around
> 	the idiotic default by turning it off on a per-socket basis.
> 	At the moment I'm aware of only one OS where DF is the
> 	default for UDP and there is no per-socket method to disable
> 	it.  It can be disabled globally but that turns it off for
> 	all protocols.
>
> 	Nameserver vendors can work around this but they shouldn't
> 	have to as it is a bad default from the OS vendors.

This is a bigger problem than just the name server (as two other  
replies have mentioned).  You cannot necessarily fix a _path_ MTU  
problem at the source by just playing w/ the DF bit.

>
>
> 	There are lots of zones today that have DNSKEY RRsets big
> 	enough to cause IP fragmentation with only the DNSKEY and
> 	associated RRSIG being returned.  Named already turns on
> 	minimal response to reduce the likelyhood of a fragmented
> 	response to a DNSKEY query.

And the only way it would know to do this iirc is if the EDNS0  
advertises a small enough buffer size (rather than 4096 which appears  
to be the overwhelming majority from the measurement I pointed out),  
right?

>
>
> 	I can see no reason to artificially restrict DNSKEY set
> 	sizes to prevent fragmentation.

This problem is already happening, so we're not talking about anything  
artificial afaik.

Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (Darwin)

iEYEARECAAYFAknVer0ACgkQK/tq6CJjZQJOvACeJorJ6UVqjQuUALa89w1XsUKD
/UoAnA19kjhZbOsPanEMFm/z6aPRmYIJ
=d1jv
-----END PGP SIGNATURE-----