In message <22386.397.521817.331...@gro.dd.org>, Dave Lawrence writes: > On 22 Jun 2016, at 11:13, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > > It is not "fun", it is the only way to have broken implementations > > (Akamai, djbdns) fixed. If we do not name them, they will continue forever. > > Even ignoring the loaded "shaming" terminology that Jim added to this > thread, I still have to disagree a bit. It is not the only way, and > certainly there is brokenness that gets fixed without publicly > pointing fingers. > > For example, in the case of the conceptual failure of the Akamai > nameserver to properly identify empty non-terminals in all necessary > answer-seeking paths, this was a problem that I noted internally a > decade ago. Yet it was triaged well below other work because it had > no practical operational impact at the time and fixing it was > non-trivial. > > Only when the qname minimisation draft came around did it really > become an operational issue, and the priority of the change request > was immediately raised. No one needed to point out to us either that > we had the problem or that operational evolution made it matter. > Working on fixing it was going to happen regardless. > > As to why it has taken so long, the public deployment of a fix was > delayed when we discovered that some customers actually relied on the > non-compliant behaviour. Believe me, I was frustrated by this > probably more than anyone else. > > All that said, I don't really object to Akamai's nameserver having > been publicly named as a problem for qname minimisation. Identifying > potential problems is obviously a crucial part of protocol > development. Just remember, though, on n'attrape pas les mouches avec > du vinaigre. We are all colleagues here, working to the same end -- a > better Internet.
The problem with that it takes time to get fixes deployed. For Akamai the path to fix has distance 1. For other nameservers the path has a much higher distance with each link in the deployment chain introducing delays and quite often you have to argue that the operator / developer / os maintainer needs to do something. You have clearly broken nameservers where operators say they have no problems when you report a issue due to depending upon a protocol feature. If we were to deploy EDNS(1) we would have to fight with 15-30% of the servers dropping the queries because firewall developers are overly paranoid. Yes, nameserver developers mishandle EDNS(1) but not to the extent where you need to block the queries. The biggest problem is that they ignore the EDNS version field and after that they return formerr. Firewalls are a bigger problem than the broken nameservers. When deploying a EDNS option you have nameservers that return FORMERR, BADVERS and echo the option back. These are 5 minute fixes for the developer and really should be made. Firewalls dropping the queries are luckily a very small percentage of the errors seen. Mark > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
