Re: [DNSOP] Asking TLD's to perform checks.

[Mark Andrews <[e-mail]>]

Perhaps we should be getting Jari, Suzanne and Andrew to push this
at IGF meetings.

In message <[e-mail]>, Shane Ker
r writes:
> Mark,
> 
> On Fri, 06 Nov 2015 10:54:02 +1100
> Mark Andrews <[e-mail]> wrote:
> 
> > 	I keep getting told the IETF can't tell people what to do
> > 	but that is *exactly* what we do do when we issue a BCP.
> > 	We tell people what best current practice is and ask them
> > 	to follow it.
> > 
> > 	Today we have TLDs that do perform all sorts of checks on
> > 	servers they delegate zones to and some do inform the
> > 	operators of those zones that they have errors.  Those
> > 	checks cover in part tests described in
> > 	draft-andrews-dns-no-response-issue.
> > 
> > 	So do we adopt this or do we continue to lie to ourselves
> > 	about what BCP actually do?
> 
> My guess is that part of the resistance is because you are going to be
> asking people to spend money on something that does not provide them or
> their customers any (direct) benefits. Further, it breaks the
> registry-registrar model in some cases, where registries are kept away
> from registrants by a 1.6 km-high wall.

Who are the customers of a registry?  The registrants and those
that lookup names in the registry.  Yes, everyone else *is* a
customer of the registry and by performing tests and informing the
registrants you help both sets of customers.

As for costs, a machine/vm running checks and sending out email
every 3 months.  That's effectively all
<https://ednscomp.isc.org/compliance/summary.html> is though it doesn't
send the email and it runs the checks daily, it does have to hooks
to send out email built in but they are not activated.  Once this
becomes a regular thing many/most/all tlds do the human costs go
down as it becomes something people can lookup answers for what to
do when they get the email.

You ask the registant to contact their DNS/Firewall vendor for the
fix after explaining the issue.  If they are hosting their own DNS
they should know who that is.  If they are using a DNS operator the
message gets relayed to the operator or they can switch DNS operators
to one which does the right thing.  The DNS operator then needs to
contact their vendors for a fix.

As for the no direct contact this doesn't require direct contact.
The registrars can perform the checks for the servers of all zones
registered through them or they can relay the messages from the
registry.

> My prediction about the eventual outcome is that you would end up with a
> document that works as well as BCP 38; meaning that it is nice to have
> for people that want some recommendations about what to check (and
> can't be bothered to look at other registries' online documentation, or
> contact registries directly and ask what they do).

So we don't say what's right because you fear that not everybody
will perform the actions.  We don't need to get every TLD to check
to have a real impact.  We just need several to check and inform,
preferably big ones.  Lots of zones are hosted by big players and
getting them fixed has a big impact on the overhaul health of the
DNS.  e.g. UltraDNS and related companies fixing their service
resulted in a 18% fix for the root and TLD servers, a 5% fix for
the Alexa top 1000, a 2% fix for Gov servers in the Alexa top 1M
and about the same for the AU servers in the Alexa top 1M.  The
bottom 1000 is too noisy to see if there was a change there.  See
the Sep 28 2015 steps in <https://ednscomp.isc.org/compliance/ts/allok.html>.

> If your true goal is to get ICANN to act as the some sort of enforcer
> for DNS operational purity, then please do so via ICANN channels rather
> than the IETF. ;)

This is actually IETF business.  We can set community consensus of
what is a resonable requirement.  If nothing else ICANN will come
back to us looking for checks to be enforced.  Additionally the
CCtlds are not bound by ICANN but by RFCs.

> To be clear, I am not opposed to a document which lists various checks
> a parent zone may want to do, and the costs & benefits of each, as long
> as it doesn't end up with you screaming at the microphone because TLD
> .XX doesn't implement the recommendations. :)
> 
> Cheers,
> 
> --
> Shane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]