[dnssec-deployment] DNSSEC in Russia
eoster at cs.ucla.edu
Thu Apr 2 22:55:49 EDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
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.
>> 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.
>> are broken according to reports from the field, and insisting that
>> 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
>> 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),
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (Darwin)
-----END PGP SIGNATURE-----
More information about the Dnssec-deployment