In message <53fe03ef-9c40-40dc-a403-50c0a339c...@fl1ger.de>, "Ralf Weber" write s: > Moin! > > On 6 Nov 2015, at 21:17, Mark Andrews wrote: > > > In message <8d78b784-34d3-421e-b82c-52dd32e22...@fl1ger.de>, "Ralf > > Weber" write > > s: > >> Really TLDs doing repeated checks? I know some do when you > >> register domains, but repeatedly? Examples? > > > > Yes. Daily checks of all delegated server. I don't believe they are > > currently reporting the discovered faults. > > > > http://bamus.switch.ch/edns/summary.html > Cool, but unless they inform someone it won't help improve anything. > Others do and it's good to see some people on the authoritative side > doing something about it. IMHO it's still a drop in the ocean. > > >> <cynic mode=on> > >> So you are telling TLD to spend money for checks that will decrease > >> there revenue. TLDs make money by registering domains. The don't make > >> money by running DNS, that is cost. > >> </cynic mode> > > > > If they don't run the DNS they don't get to take in the money. > Ever heard of negative registration or the .sucks domain.... > > [lots of DNS operational failure modes deleted] > > The operational problems that result from these behaviours should be > > obvious to everyone on this list. > > > > There are lots of other incorrect responses that cause operational > > problems. > I agree with you on both points, but that doesn't help to get these > wrong behaviours fixed. After working decades on operating recursive > servers I have lost hope that we will get these behaviours fixed. > > Whenever such a thing occurs no customer gave a damn about the wrong > configuration of the authority, they all wanted the domain to resolve. > That is the reason why advancing new technologies in the DNS is so > difficult (impossible ;-). > > Honestly I'd rather direct my energy to helping the end user with > DNS than fixing all the DNS misconfigurations on the internet, but > maybe this is because I'm getting old and have chased windmills > long enough ;-). > > So long > -Ralf
Fixing misimplementations of the protocol is different to fixing misconfiguration of servers. The draft is aimed primarially at fixing misimplementations rather than misconfigurations though both need fixing. To fix misimplementation of the protocol you work your way back to the vendors to get the server or firewall fixed at the source then install the fixed server / firewall. Once you fix a misimplementation it stays fixed as there is nothing to change other than upgrading the server / firewall. I do know that TLD servers get fixed and stay fixed [1]. We are yet to attempt to do this sort of thing in lots to TLDs at the same time. There has never been a concerted effort to fix protocol errors by asking the parents to check the child servers and informing the operators that they are broken. Most servers actually do the right thing and not all errors stop interoperation. e.g. echoing back a client cookie doesn't actually stop DNS resolution. For some other option this would be fatal which is why we want to clean the ecosystem of broken servers now rather than later. To test more that what is causing immediate problems. As a vendor you (Nominum) should be checking the servers you ship are compliant. If you find ones that are out of compliance you should be fixing them and informing your customers that there are fixed servers available. Compliance tests should be part of the QA process. Mark [1] https://ednscomp.isc.org/compliance/ts/tld.html -- 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
