Subject: [dnsext] Empty AA=0 AD=1 answers to AAAA queries: your thoughts pls

From: bert hubert <[email-masked]>
Date: Sat, 20 Dec 2014 13:58:06 +0100

Hi everybody,

I have a question if I am right in concluding something is a protocol
violation, and if we should reward it by papering it over or (finally)
concluding that enough is enough.

A few weeks ago we posted this
http://mailman.powerdns.com/pipermail/pdns-users/2014-December/011004.html
about Microsoft Azure nameservers sending empty answers (AD=1 no less) to
AAAA queries. Microsoft has indicated they'll get to addressing this early
2015, by the way (thanks Mehmet).

However, we're now seeing more and more of this, for example from the most
popular news site in the Netherlands nu.nl: 

$ dig +trace -t aaaa nu-nl.gslb.sanomaservices.nl.

Which ends on:

$ dig -t aaaa nu-nl.gslb.sanomaservices.nl. @62.69.175.251
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58444
;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;nu-nl.gslb.sanomaservices.nl.	IN	AAAA

Note that this is the same pattern as Microsoft Azure. But this empty AA=0
answer leads PowerDNS to:

 nu-nl.gslb.sanomaservices.nl.: Trying IP 62.69.175.251:53 1, asking 'nu-nl.gslb.sanomaservices.nl.|AAAA'
 nu-nl.gslb.sanomaservices.nl.: Got 0 answers from gslb2.sanomaservices.nl. (62.69.175.251), rcode=0 (No Error), aa=0, in 6ms
 nu-nl.gslb.sanomaservices.nl.: determining status after receiving this packet
 nu-nl.gslb.sanomaservices.nl.: status=NS gslb2.sanomaservices.nl. (62.69.175.251) is lame for 'gslb.sanomaservices.nl.', trying sibling IP or NS
 nu-nl.gslb.sanomaservices.nl.: Failed to resolve via any of the 2 offered NS at level 'gslb.sanomaservices.nl.'
 nu-nl.gslb.sanomaservices.nl.: failed (res=-1)

And this means we send out a SERVFAIL to our client, since all servers are
'lame'.  This makes some programs very unhappy.

We are (as is any resolver implementor) receiving pressure not to do this,
and to paper over this behaviour. There is a workaround available in the URL
above.

We think the time has to come to say 'no, if you run a non-confirming
implementation, you deserve all the pain you get'. 

But before we make a stand, what do you think? Should we accept empty AA=0
AD=1 answers as "NO ERROR"? 

Please let us know.

	Bert

---

From: Mark Andrews <[email-masked]>
Date: Sun, 21 Dec 2014 01:25:06 +1100

> concluding that enough is enough.

I've been thinking for a long time that enough is enough.  Named tried
to reject all non referral "aa=0" from supposedly authoritative servers
a while back and we had to reverse the change.  While pandora.tv has
fixed the aa=0 issue they still return malformed answers.

What we really need is for TLD operators to audit all the delegated
servers and inform their owners when they see a broken one.  They
are the ones with the lists of authoritative servers and the contact
information.

See draft-andrews-dns-no-response-issue.

>  nu-nl.gslb.sanomaservices.nl.: Got 0 answers from gslb2.sanomaservices.nl. (
> 62.69.175.251), rcode=0 (No Error), aa=0, in 6ms
>  nu-nl.gslb.sanomaservices.nl.: status=NS gslb2.sanomaservices.nl. (62.69.175
> .251) is lame for 'gslb.sanomaservices.nl.', trying sibling IP or NS

Personally I would like to take a stand.  Whether we can convince others
is another matter.
 
> Please let us know.
> 
> 	Bert
> 
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: bert hubert <[email-masked]>
Date: Sat, 20 Dec 2014 15:41:30 +0100

> fixed the aa=0 issue they still return malformed answers.

What about if (say) ISC, NLNetlabs, Nominum, PowerDNS and Google DNS say
"enough is enough"?  

Because right now, the dynamics we all know are "yeah but you must fix it
since it works on X" (where X isn't you).

If we had a nice manifesto to point to, we could make this stick.

I estimate that >25% of the PowerDNS recursor now consists of "stuff we have
to do because the internet sucks". 

The horrible thing is that every workaround we add increases the chance we
break legitimate things, or open ourselves up to attacks that make good use
of our willingness to bend things to make them work.

> Personally I would like to take a stand.  Whether we can convince others

Benno, Wilmer, Ted, Kumar, what do you think? We could coordinate off-list
perhaps?

	Bert

---

From: Jim Reid <[email-masked]>
Date: Sat, 20 Dec 2014 16:21:25 +0000

On 20 Dec 2014, at 14:25, Mark Andrews <[email-masked]> wrote:

> 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.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 21 Dec 2014 07:43:37 +1100

In message <[email-masked]>, Jim Reid writes:
> 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.
>
> 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.

---

From: Lawrence Conroy <[email-masked]>
Date: Sun, 21 Dec 2014 01:34:58 +0000

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]

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 21 Dec 2014 06:34:02 +0100

A few examples of where the world is from my perspective:

As long as...

- ...policy in some registries require NS records for registrations of a domain (i.e. no difference between registration and delegation), there will be lame delegations

- ...policy in some registries require NS records for registrations of a domain (i.e. no difference between registration and delegation), there will be proxy registrations and registrants that lie

- ...data sent to a registry/registrar, regardless of data protection legislation, is available freely "on the net", there will be proxy registrations and registrants that lie

- ...policy make it impossible to register domain names in some registries, there will be proxy registrations to circumvent the very same rules

- ...there is no agreement on what data to send to registries for DNSSEC signed zones, it will be very hard to get lots of DNSSEC signed zones

- ...policy in some registries that the registrant should contact them directly, registrars will lie to the registry during registration period so that they can give the registrant the service the registrant ask for

I.e. the world out there is so messy that what you talk about is a light warm breeze...

Just the notation of "the TLDs" to fix things is confusing to me. Does "the TLD" imply the registry, whoever is the administrative contact for the TLD in the IANA database, or the backend provider, or the technical contact or the one holding the whois record of the delegation the question is about, or...

   Patrik

---

From: bert hubert <[email-masked]>
Date: Sun, 21 Dec 2014 10:44:54 +0100

> - ...policy in some registries require NS records for registrations of a domain (i.e. no difference between registration and delegation), there will be lame delegations

To clarify, nothing like this is what I intended. Perhaps a prototype will
help:

"Dear domain operator, nameserver vendor, or load balancer purveyor,

The domain x.y.z fails to resolve using our software, and we have determined
that this is because the software or hardware publishing the DNS details of
x.y.z is not conforming to the DNS standards.

The violation is: Sending empty non-aa answers to AAAA queries
The result is: our software generates a SERVFAIL response, confusing
Microsoft Exchange.
The product at fault is: Citrix Netscaler 

Please find further details attached to this message.

While some other software or service is able to resolve your domain, we are
not going to work around this issue. 

For years, all resolver vendors and service providers have papered over DNS
protocol violations if one of the other big resolver implementations was
able to resolve a domain. There is now a staggering amount of papering over
in each nameserver implementation.

As a DNS community, we have decided that enough is enough. We encourage you
to contact the responsible vendor (see above). We are more than willing to
talk to them if this helps them resolve the issue.

Kind regards,

PowerDNS, also on behalf of ISC, .., .. and .."

This would then come with a website with further explanations, and perhaps
even a registry of faults that has been decided we're not going to fix.

I'm open to providing specific workaround configurations to individual
operators if this helps them in the meantime, but they'll hate having to
maintain all these workarounds, thus generating rising pressure on the
vendors of broken equipment.

Ideas?

	Bert

---

From: Jim Reid <[email-masked]>
Date: Sun, 21 Dec 2014 09:47:53 +0000

On 21 Dec 2014, at 01:34, Lawrence Conroy <[email-masked]> wrote:

> Registries may be OK, but do you expect them to spam their customers' customers?

Indeed. My earlier rant overlooked that one.

Most registrars do not want registries to contact registrants - ever. Registrars like to have total control over the communications to their registrants, usually to the point where the registrant is unaware of the registry's existence. Quite a few ccTLD registries have policies which forbid the registry from contacting the registrant.

---

From: Jim Reid <[email-masked]>
Date: Sun, 21 Dec 2014 10:18:19 +0000

> even a registry of faults that has been decided we're not going to fix.

Bert, your prototype email is all very well. Of course it would be nice if there was some botnet (say) which went looking for these broken DNS servers and sent an email from the aa=0 police like the one you suggested.

However this is howling at the moon. For decades the DNS industry has been unable to get people to fix their lame delegations or get them to stop using BIND8 or to use software which does EDNS or... So an attempt along these lines to fix the aa=0 problem will be yet another Epic Fail. If DNS lameness can't be cured, contacting registrants -- assuming that was possible and it isn't -- to get software replaced surely won't succeed either.

Everyone here should already know by now that contacting registrants en masse will never produce the desired outcome. We should also know why that approach is guaranteed to fail every time. Now who was it that said “The definition of insanity is doing the same thing over and over again, but expecting different results”?

The only sensible approach to take here is to notify the vendors of the broken software and hope they do the Right Thing. If they don't, or their customers can't/won't upgrade, the rest of us just have to suck it up. 'Twas ever thus. At least the DNS developer community is small and fairly easy to reach.

BTW, your Subject: header is appropriate. There's been more than enough discussion of this deeply flawed approach to fixing the aa=0 problem.

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 21 Dec 2014 11:33:17 +0100

> On 21 dec 2014, at 10:44, bert hubert <[email-masked]> wrote:
> 
:
:

As Jim says, your idea is nice as it is, and there is nothing wrong with the email -- but we have no idea what so ever where to send it.

The best path forward is I think still for you to publish clear and crisp information like this on your web page so that it is found when searching for help with Google and other search engines.

I.e. as long as no one have any issues with the brokenness, it will not be fixed.

And obviously it is not broken enough. The parties involved (the one looking things up and the domain name holder) obviously either can communicate anyways with the brokenness or they do not find lack of communication is bad enough to fix whatever is to be fixed.

I feel very sad to have this view today, because I did not have it earlier. I have though given up on the mass market operational community and feel one have to spend time where it actually matters, on software, best practices etc.

If not even TLDs are hosted correctly, and registry policies are such that it encourages broken DNS configurations, I feel there is not much The Protocol Police can do about it.

   Patrik

---

From: Alex Bligh <[email-masked]>
Date: Sun, 21 Dec 2014 13:01:08 +0000

> What about if (say) ISC, NLNetlabs, Nominum, PowerDNS and Google DNS say

There are options between SERVFAIL and work-around. One such would be
'delay responses in respect of non-conformant replies by 3 seconds'.
I would bet pretty Google Pagespeed etc. will start including a
test to see whether the DNS server is broken and thus causes excessive
delay with certain resolvers.

That's far less antisocial than "surely you didn't you really mean
'aa=0'? Let me just ask you 255 more times to make sure in case you
change your mind", no matter how tempting ...

-- 
Alex Bligh

---

From: bert hubert <[email-masked]>
Date: Sun, 21 Dec 2014 15:33:11 +0100

On Sun, Dec 21, 2014 at 11:33:17AM +0100, Patrik Fältström wrote:
> As Jim says, your idea is nice as it is, and there is nothing wrong with
> the email -- but we have no idea what so ever where to send it.

Actually, as the authors of a resolver, we know exactly where to send it. To
the people telling me I need to fix my resolver so it works with broken
domain X. 

And in turn, we've found that (together with resolver operators) we can
quickly find out what broken hardware or software is behind the issue -
Citrix Netscalers this time round. It helps if large operators (people with
tens of millions of customers) tell them they need to clean up their act.

The REAL issue right now is that we can't resist fixing a broken domain
"because it works with Google/Unbound/Bind/Microsoft, so you must fix it". 

What is needed is a pact that none of us will respect that argument on its
own if a domain actually should be broken.

> The best path forward is I think still for you to publish clear and crisp
> information like this on your web page so that it is found when searching
> for help with Google and other search engines.
> 

Exactly. It should actually break therefore. If you own dodgy equipment or
use bad software, your domain should receive lots of reports of brokenness.

> If not even TLDs are hosted correctly, and registry policies are such that
> it encourages broken DNS configurations, I feel there is not much The
> Protocol Police can do about it.

I'm afraid this is true. But if all big implementation decide to no longer
play the game, the (mostly) load balancer implementations will have to clean
up their act.

I also note that quite a lot of problems are AAAA related. This in itself is
an impediment to IPv6 adoption!

	Bert

---

From: Jay Daley <[email-masked]>
Date: Mon, 22 Dec 2014 08:54:30 +1300

> On 21/12/2014, at 10:47 pm, Jim Reid <[email-masked]> wrote:
> 

Indeed.

We (.nz) are just about to launch a redesigned registrar portal that includes notifying registrars about 'bad' data, where 'bad' data includes errors we see in our zone scan (some example classification below) and also errors we see in the registrant data.  There's no obligation on the registrars to do anything with this data but in beta testing we saw most of them act on the data, where they could, because they wanted to be 'good' registrars.  Of course they could all do this scanning themselves but it's not a high enough priority for them to write the code themselves and it turns out that they are pleased that we are doing it for them.

To be clear, we are one of those registries where our policy forbids us from contacting registrants but that doesn't matter here because in our view there would be no point at all in contacting registrants with this same information.  The only gap is third party DNS providers but we'll get round to them at some point.

cheers
Jay

Domains with broken delegation
Domains with lame delegations
Domains with inconsistent nameserver set
Domains with extra nameserver at child
Domains with extra nameserver at parent
Domains with inconsistent serial numbers
Domains with missing glue at child
Domains with inconsistent glue
Domains with nameserver pointing to CNAME
Domains with no MX record
Domains with nameservers in 1 ASN
Domains with at least one nameserver with open recursion 
Domains with at least one nameserver with open transfer
Nameservers with open recursion
Nameservers with open zone transfer
Nameservers not answering TCP queries
Nameservers not answering UDP queries

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

---

From: Mark Andrews <[email-masked]>
Date: Mon, 22 Dec 2014 15:06:53 +1100

In message <[email-masked]>, Jim Reid writes:
> Bert, your prototype email is all very well. Of course it would be nice
> if there was some botnet (say) which went looking for these broken DNS
> servers and sent an email from the aa=0 police like the one you suggested.
>
> However this is howling at the moon. For decades the DNS industry has
> been unable to get people to fix their lame delegations or get them to
> stop using BIND8 or to use software which does EDNS or... So an attempt
> along these lines to fix the aa=0 problem will be yet another Epic Fail.
> If DNS lameness can't be cured, contacting registrants -- assuming that
> was possible and it isn't -- to get software replaced surely won't
> succeed either.

To my knowledge no one has attempted to get nameservers upgraded
by sending email to delegated server operators.  Sending email to
TLD operators does have a effect.  Whether that can be replicated
the next level down we need to see.

Additionally classic lameness will come back over time as it is a
configuration issue.  Once you fix software it stays fixed.

The more TLD operators that come on board the more likely it is to
succeed.  A DNS hosters getting complaints from all TLD operators
is much more likely to pay attention to them.  Similarly individual
operators in multiple TLDs.

> Everyone here should already know by now that contacting registrants en
> masse will never produce the desired outcome. We should also know why
> that approach is guaranteed to fail every time. Now who was it that said
> "The definition of insanity is doing the same thing over and over again,
> but expecting different results"?

> The only sensible approach to take here is to notify the vendors of the
> broken software and hope they do the Right Thing. If they don't, or their
> customers can't/won't upgrade, the rest of us just have to suck it up.
> 'Twas ever thus. At least the DNS developer community is small and fairly
> easy to reach.

Vendors also need to fix their software and no the DNS developer
community isn't small enough to reach everyone.  Going through zone
operators is the only way to reach some of the players.  Ultimately
the zone operators need to update their nameservers and firewalls
to be DNS compliant.

Expecting them to learn that the need to update without a active
campain will fail.

> BTW, your Subject: header is appropriate. There's been more than enough
> discussion of this deeply flawed approach to fixing the aa=0 problem.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 22 Dec 2014 06:50:33 +0100

> On 21 dec 2014, at 15:33, bert hubert <[email-masked]> wrote:
> 

Ok, good. That is exactly what I claim is the most effective way of solving the issue.

> tens of millions of customers) tell them they need to clean up their act.

Yes.

> an impediment to IPv6 adoption!

Yes.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 22 Dec 2014 06:55:27 +0100

> On 22 dec 2014, at 05:06, Mark Andrews <[email-masked]> wrote:
> 
> by sending email to delegated server operators.

Maybe because one do not know who these name server operators are. And in the cases one do (like in some ccTLDs), that has other drawbacks.

> Sending email to TLD operators does have a effect.

Well, well...

> Whether that can be replicated the next level down we need to see.

Some TLD registries have tried to contact DNS operators, some contact the registrant, some contact the registrar.

> Additionally classic lameness will come back over time as it is a configuration issue.

And my point was only that enough registries do have a policy that REQUIRE lame delegations to be able to just register a domain name (i.e. one can not register without delegating at the same time). Crazy!

But as you say, this is a configuration issue, and not a software issue.

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Mon, 22 Dec 2014 17:58:00 +1100

In message <[email-masked]>, =?utf-8?Q?Patrik_F=C3=A4lt
str=C3=B6m?= writes:
> Maybe because one do not know who these name server operators are. And in
> the cases one do (like in some ccTLDs), that has other drawbacks.

Send it to the SOA RNAME.  If that does not work send it to the
registrant (by the registrar if need be).  They are ultimately
responsible for the domain.  If those contact methods bounce initiate
the proceedures for broken contacts.

> registrant, some contact the registrar.

The registrant is ultimately responsible for picking the registrar
and DNS operator if it is not themselves.  It is the registrars job
to contact the registrant on behalf of the registry where the
contract precludes direct contact.

> > configuration issue.
> And my point was only that enough registries do have a policy that
> REQUIRE lame delegations to be able to just register a domain name (i.e.
> one can not register without delegating at the same time). Crazy!
>

No.  That is a policy issue.

Just because you do not like the policy is not a reason to not
configure servers if that is the policy of the parent domain.  It's
not like they won't be running some servers for some zones.  Those
servers can be configured with minimal zones (soa + ns records).

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 22 Dec 2014 08:55:43 +0100

> On 22 Dec 2014, at 07:58, Mark Andrews <[email-masked]> wrote:
> 

That is exactly my point. As long as registrant and registry disagree about _policy_ we will see issues like these, regardless of what the protocol police say.

You see it, as I expressed in my list, regarding proxy registrations, lame delegations and more.

If you look at the various TLDs, you see much less issues with proxy and lame delegations where the policy is such that:

- One can register a domain name without delegating

- Anyone can register a domain name

And my point is that before we have those basic rules in a TLD, chasing down registrants, registrars, DNS hosting providers and whoever else will have limited if any effect.

In TLDs where those are the basic rules, then the protocol police might have effect.

   Patrik

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 22 Dec 2014 10:16:28 +0100

On Sun, Dec 21, 2014 at 10:18:19AM +0000,
 Jim Reid <[email-masked]> wrote 
 a message of 34 lines which said:

> However this is howling at the moon. For decades the DNS industry
> has been unable to get people to fix their lame delegations or get
> them to stop using BIND8 or to use software which does EDNS or...

An experience at AFNIC: between 1996 and 2012, we had a mandatory
pre-delegation (and also pre-registration, which was not a good idea)
technical test, implemented by the Zonecheck program.

During this period, we had a lot of angry customers, many insults
(ranging from "incompetent bastards" to "lazy civil servants"), many
calls upon the ghost of Postel ("you should accept what is obviously
broken") and our dose of french-bashing
<http://www.circleid.com/posts/afnic_dns_server_redelegation/>

Registrars complained, bloggers complained, industry analysts
complained. Nobody supported us, not even the people and organisation
who have their mouth full of big words like "security and
stability". And noone tried to imitate us...

Even if you are a non-profit organisation, you have to pay the bills
(and the employees) so in the end, the forces of the free market won.

Zonecheck mandatory testing was retired in december 2012
<http://www.afnic.fr/fr/l-afnic-en-bref/actualites/actualites-operationnelles/6473/showOperational/maintenance-arret-de-la-chaine-d-enregistrement-le-17-12-de-18h30-a-20h30-1.html>
(french only)