[dnssec-deployment] DNSSEC in Russia

[Eric Osterweil]

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


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

>
> In message <8DC099B4-45A3-4F69-BBA1-69C10452C7D7 at cs.ucla.edu>, Eric  
> Osterweil w
> rites:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On Apr 2, 2009, at 2:51 PM, Mark Andrews wrote:
>>
>>>
>>> In message <list-17545150 at execdsl.com>, Lutz Donnerhacke writes:
>>>> Every EDNS0 enabled UDP response from a root server should not get
>>>> fragmented on the way through the net nor needs to generate =20
>>>> multiple packets
>>>> on the root server itself. That's why the limit of the IP packet  
>>>> =20
>>>> size is
>>>> about 1400 byte payload. This limit correspond to a single KSK  
>>>> and =20=
>>
>>>> a single
>>>> ZSK which is rolled regularly. If somebody want's to add another  
>>>> =20
>>>> algorithm,
>>>> the full size doubles. I believe such sizes to be too risky for a  
>>>> =20
>>>> productive
>>>> signed root.
>>>
>>> 	Please cite the relevent RFC that recommend this limit.
>>>
>>> 	If you don't want fragmentation then you need to push it
>>> 	back to under 1200 as that is the what IPv6 responses will
>>> 	be fragemented to.  Nameservers shouldn't be attemting PMTU
>>> 	discover on UDP responses.
>>>
>>> 	In reality the DNS can cope quite well with fragmented UDP
>>> 	and the occasional lost fragment.
>>
>>
>> Not to be totally contrary, but this problem does have to do with =20
>> _path_ MTU, so some sense of PMTU limitations is important.   
>> SecSpider =20=
>>
>> has been tracking this as problem for some time and reports it on  
>> all =20=
>>
>> of its zone drill-down pages.
>>
>> Some recent measurements ( =
>> https://www.dns-oarc.net/files/edns-study/edns-f-root-dsc-20080825.png=20=
>>
>>  ) suggest that many resolvers advertise 4,096 by default.  This =20
>> already is a problem for resolvers.  Some of the paths that get  
>> used =20
>> (on the way to various zones) may have more restrictive PMTU  
>> problems =20=
>>
>> than others and some name servers decide to load up query responses  
>> =20
>> with a lot of extra data if they seem to have room.  For example, =20
>> advertising 4,096 might cause some name servers to return a lot of  
>> =20
>> extra cruft + sigs in their messages' additional section that  
>> causes =20
>> silent drops in the network (no TC bit, no nothing).  When this =20
>> happens your resolver will not know what's wrong, it will just time  
>> =20
>> out.  At the same time, 4096 may not cause other zones to pad out =20
>> their messages, or the paths to still other zones may not affect  
>> the =20
>> availability.  So, from the resolver operator's perspective, this  
>> can =20=
>>
>> seem like an illusive problem.
>
> 	Well if your OS stupid enough to set DF on IPv4 / UDP packets
> 	you get what you ask for.

Who's sending DF bits?  The authoritative servers?  They're the ones  
sending DNS messages that exacerbate the PMTUs.  Are you saying that  
zone operators are running "stupid" OSes, and if so, how would you  
propose to proceed?  I think it's more likely that any lack of clue  
belongs to those who have heard of this problem and then ignore the  
implications of overstuffing their DNSKEY sets (or blame widely used  
OSes?????).

I think the salient point here is consider this as a problem, don't  
ignore it.

>
>
> 	Path MTU discover was known to be a problem for DNS/UDP
> 	over a decade ago.  Having the ability to disable PMTU
> 	discover on a per socket basis was written into IPv6 over
> 	a decade ago to prevent this being a problem.

And yet, here it is... a problem.  What is the point you're trying to  
make?  Mine is that people need to consider the impact of adding too  
many/large keys or should at least be conscious of the fact that  
resolvers may have trouble depending on their PMTUs if zone data  
bloats up.

>
>
> 	Path MTU discover is good for TCP as it is the IP stack
> 	that handles the outages.  Path MTU discover should NEVER
> 	be turned on by default for anything else.  If your OS does
> 	this then complain to your OS vendor/developer.

I don't know who is proposing to run pmtud for DNS, but I haven't  
heard that.  My point is about PMTUs of the network (as in, there are  
issues there).

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

iEYEARECAAYFAknVQ2EACgkQK/tq6CJjZQJ9igCgg4yZcx1ln1yC1JXS/EoYuqoK
Yq8An1rFWA43lwf7AVZ8E/ZAYUXBOBL9
=t8Vp
-----END PGP SIGNATURE-----