In message <9506594E9E3CB989AFBC02A8@xxxxxxxxxxxxxxxxxx>, John C Klensin writes: > > > --On Wednesday, May 22, 2013 12:29 +0000 Yoav Nir > <ynir@xxxxxxxxxxxxxx> wrote: > > >> Occasional fantasies about IETF enforcement power and the > >> Protocol Police notwithstanding, it seems to me that, if one > >> wanted to require standards-conforming nameservers, the most > >> (and maybe only) effective way to do that would be > >> requirements in the contractual agreements between TLD > >> registries and their registrants. Recursively applying > >> requirements down the tree is not a new idea; RFC 1591 uses > >> that language more than once. > > > > We should be careful about requiring things like this (for > > whatever value of "we"). Recursively applying requirements > > means that "we" are requiring service providers (in this case > > registries) to pick fights with their customers. So instead of > > having an IETF protocol police, "we" expect service providers > > to act as local sheriffs. > >... > > Seems like a tough sell to me. > > Actually, I was thinking about something a little different (and > should have been more explicit). > > I wouldn't suggest trying to mandate anything top-down. If > nothing else, ICANN's track record for being able to enforce its > mandates is very poor (and that is arguably a good thing). Asking people to run a nameserver which "responds" to queries isn't unreasonable by any stretch of the imagination regardless of their economic circumstances. The nameservers that people used in the 1980's did this correctly. The default nameservers on general purpose OS as shipped for the last 2 decades have done this correctly. This includes free and commercial operating systems. The one exception I am aware of is a Windows release where the server responds to the first EDNS query but not to subsequent EDNS queries. This only becomes a issue when the first response is lost or multiple recursive servers share the same IP address. Microsoft has fixed this issue in later releases. I am not sure if there is a service pack that fixes this. Requiring vendors to supply fixes to code that was never "fit for purpose" regardless of its age is also reasonable. > On > the other, we talk a lot about reputations and the advantages of > end sites being able to base policies on them. If whatever the > actual restrictions that, according to Stephane, forbid TLDs > from imposing "we require you to have a competent nameserver and > will test" were removed then, especially with the coming huge > increase in TLDs, it would make it possible for registries to > compete on the degree to which they wanted to offer assurances > of quality DNS servers and services in subsidiary zones. > Would-be registrants who didn't want to play would have the > option of finding TLDs who did not have those restrictions. > That would create a new opportunity for enhanced competition and > differentiation among TLDs (which ICANN presumably favors along > with favoring security and stability) and would create a basis > for some DNS server certification activities (and even a > business model for them). > > No mandate from the top, just elimination of whatever > restrictions now prevent registries from insisting on quality > operations in registrants if they wanted to. > > It wouldn't get us to "everyone has to run a conforming server" > --which I consider impossible as long as producing > non-conforming servers is legal with governments enforcing the > rules if servers don't conform (and I really don't think we > want to go there)-- but it would at least give a resolver an > indication of where conforming ones were guarantees and what > responses or non-responses they couldn't trust. > > john > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx