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

[Lawrence Conroy <[e-mail]>]

Hi Mark, Jim, Bert, folks,
 What makes me think this is an IETF mailing list, as opposed to what infests the real world?

Where, in ICANN contracts (choose one), does it say that a gTLD operator has to police the lameness/whackiness of delegated authoritative server responses?
[note -- not the GTLD's responses, those of servers authoritative for delegated domains]
That doesn't even cover the CCTLDs, which are pretty much all over the shop with their disparate policies (and gawd knows what the contracts are each of them have with their customers).

Seriously ... Registries may be OK, but do you expect them to spam their customers' customers?
With thin registries, that will naff off the Registrars (look at the apologetic tone of the spam gTLD Registrars are forced to send each year to ask customers to not do what Jim might have hinted he does to his contact info).

As for fixing the server software: you have to know that this will be seen by the hard of thinking as "all new DNS software is broken".

Don't get me wrong -- I'd love this to happen (as long as I have popcorn and a comfy sofa to watch the fun).

all the best 
  Lawrence
[a poor customer's customer's customer]

On 20 Dec 2014, at 20:43, Mark Andrews <[e-mail]> wrote:
> 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]
> 
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext