Re: [dnsext] getting TLDs to fix other people's problems

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Jim Reid writes:
> On 20 Dec 2014, at 14:25, Mark Andrews <[e-mail]> wrote:
>
> > What we really need is for TLD operators to audit all the delegated
> > servers and inform their owners when they see a broken one.
>
> Mark, this is a ridiculous idea. It's utterly unworkable.  just like it
> would be to get TLDs to act as the lame delegation police. It simply
> isn't going to happen. Even if this contact was viable, it will be rare
> to find a registrant who understands this aa=0 issue and is willing to
> fix the broken implementation: "the DNS for my domain is working just
> fine for me, so why should I care about the troubles it causes someone
> else or pay to fix their problem?".

The problems listed in my draft are problems with the software.
You tell them to contact the DNS vendor for a fix.  The DNS vendor
should understand and fix it themselves in the case of a hosted
service or be able to advise them of which version of the software
they need to run or generate a fix and advise them to run it.

Most of the problem is that the operators don't know that there is
a issue.  You would assume that your DNS supplier actually produces
protocol compliant software.  Informing them that they have a problem
is the first step to getting it fixed.

> I wish you every success getting ICANN to adopt that policy for gTLDs and
> then steering it through the policy-making machinery and/or legislation
> for each of the 200-odd ccTLDs. Once that's done, good luck with
> implementing and enforcing those policies.
>
> > They are the ones with the lists of authoritative servers and the
> contact
> > information.
>
> No they are not. Lots of registrants hide behind proxy/privacy services.
> Some of them publish non-functioning contact data for the registrant,
> Other registrants supply ficticious contact data, myself included.
> Draining these festering swamps will take forever and no matter how hard
> registries try, they will always be stuck with them. Don't take my word
> for it. Ask the IPR and law enforcement types who have been screaming for
> years at ICANN about bogus whois data.

They still have the lists of registrants.  If they choose to hide behind
proxy/privacy services then the contact is through them.  It is their
job to sort out what is legitimate communication from spam.

> Remember too that the two largest TLDs (which have ~50% of the world's
> registered delegations) operate the thin registry model where the
> registrars and not the registry hold registrant contact data. Verisign
> couldn't even contact the holder of domain-with-aa=0-issues.com if they
> wanted to.

Then they go through the registrars.  They and the registrars choose
to operate in then model.  They need to deal with it.  It isn't
like registries didn't know that this is part of their job.  Contacting
the parent to deal with problems in the child zone is listed as
part of the problem resolution proceedures so that should have the
mechanisms to do this.  If they don't then they failed to do due
diligence when they got into the registry business and they need
to rectify their proceedures.  The registrars should have also
realised that they are part of the compliants process.

RFC 1033, COMPLAINTS

   These are the suggested steps you should take if you are having
   problems that you believe are caused by someone else's name server:

   1.  Complain privately to the responsible person for the domain.  You
   can find their mailing address in the SOA record for the domain.

   2.  Complain publicly to the responsible person for the domain.

   3.  Ask the NIC for the administrative person responsible for the
   domain.  Complain.  You can also find domain contacts on the NIC in
   the file NETINFO:DOMAIN-CONTACTS.TXT

   4.  Complain to the parent domain authorities.

   5.  Ask the parent authorities to excommunicate the domain.

With systemic problem you often modifiy the proceedures to identify the
problem sources enmass which is what I'm trying to arrange to happen here.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]