Back when I worked at a service provider, we helped customers with their DNS configurations, Sendmail, usenet news (yes, it was a long time ago), and other services. If they were new customers, we would help them with the setup or if something was broken we would look at the configuration, look at dig results, etc. Shouldn't we be at the point where the applications running DNS services can ensure configurations are correct? Wouldn't it be more efficient to work with the implementations to provide configuration validation or have easier input screens? It was fine in 1997 to call someone at you SP, but this does not scale even with lots of service providers. While tying this to contracts seems like a good idea, that is out of our hands at the IETF. If we went down the path of enforcement through contracts, I wouldn't view this as picking fights, but rather a proactive service to 'help' customers. Having said that, I think if we can improve the applications that generate their DNS files, it would be more effective long term. While some teams are technical enough to validate their own DNS, others prefer more full service applications. Maybe a review of existing applications would be helpful for the community? I just see the following on Wikipedia: http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software and http://en.wikipedia.org/wiki/DNS_management_software How about adding a column for compliance to RFCs? Or a description that makes people aware of configuration problems caused when using certain packages? This may start with known problems and work arounds, but ultimately lead to fixes in the products with automatic configuration validation. This may not be the job of the IETF, but there must be groups we can work with to accomplish things like this. Just a thought... Best regards, Kathleen ________________________________________ From: ietf-bounces@xxxxxxxx [ietf-bounces@xxxxxxxx] On Behalf Of Yoav Nir [ynir@xxxxxxxxxxxxxx] Sent: Wednesday, May 22, 2013 8:29 AM To: John C Klensin Cc: <iesg@xxxxxxxx>; <ietf@xxxxxxxx> Subject: Re: Deployment of standards compliant nameservers On May 22, 2013, at 3:10 PM, John C Klensin <john-ietf@xxxxxxx> wrote: > > > --On Tuesday, May 21, 2013 11:07 +0200 Stephane Bortzmeyer > <bortzmeyer@xxxxxx> wrote: > >> ... >> Although these tests certainly contributed to the good >> technical quality of the name servers, they were removed both >> for commercial reasons (a registry has to make money to pay >> its employees) and because it was easier to have the same >> rules for ccTLDs and gTLDs (and ICANN forbids these technical >> tests in gTLDs). > > 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. It's not that service providers would never do this. There is some success in getting ISPs to shut down spammers, but they are likely to cooperate when the actions of the offenders are likely to damage either the service provider's infrastructure, or harm other customers. This is not the case here. A DNS server that ignores unknown record types does not hurt anyone who only queries for A and AAAA records. And MX. It hurts people who try to deploy new record types, so for now, it hurts experiments. It reduces the likelihood of a major browser deploying a version with DANE enabled by default. This is definitely harm, but beating one bad server into compliance does not fix the problem. So "we" would be asking service providers to take a step with positive costs (periodically testing servers, contacting customers, threatening them, and following up), all to prevent a kind of harm that would only be prevented if all other registrars in the world (or at least a vast majority) would do the same. And if that harm was mitigated, and all the DNS servers in the world were fixed, hardly anyone would notice. Seems like a tough sell to me. Yoav