Hi all, During the last RIPE meeting, I presented on research that SURFnet has been doing over the past year into DNS response delivery issues caused by firewalls or other network equipment blocking fragments (see https://ripe64.ripe.net/presentations/91-20120418_-_RIPE64_-_Ljubljana_-_DNS... and the meeting minutes for the last WG meeting). After the meeting, Jim Reid suggested that we write a draft WG recommendation containing some of the suggestions we made for dealing with this issue (specifically, dealing with it by reducing the maximum EDNS0 response size on the authoritative side). Gijs van den Broek, who has performed most of the research, has spent the past couple of weeks writing such a recommendation. I'm circulating the draft document here hoping that we can discuss whether or not it makes sense to issue a recommendation on this. I realise this may be a controversial issue. Many have argued in the past that the only real solution to this problem is that people stop doing second rate Internet by blocking fragments, or that operators of caching recursive name servers should correctly configure their systems according to the maximum response size they can receive. Our approach to this has been a rather pragmatic one. Rather than looking at what should be the ideal situation we are trying to strive for maximum interoperability and ensuring that we maximise the chance that a response is delivered to a query while still not completely giving up on the ideal that fragmentation should just work and be accepted. The reason for approaching this from the authoritative side, by the way, is that there are already a number of recommendations out there that deal with the caching recursive side of things. If there is one thing our research shows its that these recommendations are not followed by most operators, unfortunately. As an operator of a substantial number of zones, we would like to be able to influence the deliverability of responses for the zones we are authoritative for. Since we cannot chase down every operator of a caching recursive name server that experiences delivery issues, even if we wanted to, the only way to do this is to avoid fragmentation on the authoritative side. I will present some more of our reasoning behind the recommendations in the document at the DNS WG meeting. I'm hoping for a good discussion next week :-) The document can be found here: https://dnssec.surfnet.nl/wp-content/uploads/2012/09/Recommendations-for-dea... Remarks, comments, rants, etc. are all welcome via e-mail as well, of course :-) Cheers and see you next week, Roland -- Roland M. van Rijswijk - Deij -- SURFnet bv -- w: http://www.surfnet.nl/en/ -- t: +31-30-2305388 -- e: roland.vanrijswijk@surfnet.nl