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(_at_)ietf(_dot_)org [ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Yoav Nir [ynir(_at_)checkpoint(_dot_)com]
Sent: Wednesday, May 22, 2013 8:29 AM
To: John C Klensin
Cc: <iesg(_at_)ietf(_dot_)org>; <ietf(_at_)ietf(_dot_)org>
Subject: Re: Deployment of standards compliant nameservers
On May 22, 2013, at 3:10 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
--On Tuesday, May 21, 2013 11:07 +0200 Stephane Bortzmeyer
<bortzmeyer(_at_)nic(_dot_)fr> 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