Re: getting TLDs to fix other people's problems
Mark Andrews <[email protected]> Sun, 21 Dec 2014 07:43:37 +1100
| Newsgroups | gmane.ietf.dnsext |
|---|---|
| Message-ID | <[email protected]> |
In message <[email protected]>, Jim Reid writes: > 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?". 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: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dnsext mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsext