getting TLDs to fix other people's problems

Jim Reid <[email protected]> Sat, 20 Dec 2014 16:21:25 +0000
Newsgroups gmane.ietf.dnsext
Message-ID <[email protected]>
On 20 Dec 2014, at 14:25, Mark Andrews <[email protected]> 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?".

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.

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.
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext