Subject: [DNSOP] Asking TLD's to perform checks.

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Nov 2015 10:54:02 +1100

I keep getting told the IETF can't tell people what to do
	but that is *exactly* what we do do when we issue a BCP.
	We tell people what best current practice is and ask them
	to follow it.

	Today we have TLDs that do perform all sorts of checks on
	servers they delegate zones to and some do inform the
	operators of those zones that they have errors.  Those
	checks cover in part tests described in
	draft-andrews-dns-no-response-issue.

	So do we adopt this or do we continue to lie to ourselves
	about what BCP actually do?

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: "Ralf Weber" <[email-masked]>
Date: Fri, 06 Nov 2015 08:46:10 +0100

Moin!

This may be totally in appropriate 

> 	draft-andrews-dns-no-response-issue.
Really TLDs doing repeated checks? I know some do when you 
register domains, but repeatedly? Examples?

> 	about what BCP actually do?
They recommend something. The problems is when your 
recommendations are interfering with business or policy aspects
which this draft clearly does:

"If repeated attempts to inform and get the customer to correct /
   replace the faulty server are unsuccessful the TLD operator shall
   remove all delegations to said server from the zone."

<cynic mode=on>
So you are telling TLD to spend money for checks that will decrease
there revenue. TLDs make money by registering domains. The don't make
money by running DNS, that is cost.
</cynic mode>

I know that a lot of TLDs go to great lengths running a good DNS
service and have sensible policies for there registrars to run a good
DNS service also, and the above comments are not for them, but some 
people only look at the money.

So long
-Ralf

---

From: [email-masked]
Date: Fri, 6 Nov 2015 09:32:38 +0000

> register domains, but repeatedly? Examples?

.is for example - see https://www.isnic.is/en/faq#q4d

--
Marius

---

From: Antoin Verschuren <[email-masked]>
Date: Fri, 6 Nov 2015 18:50:28 +0100

> register domains, but repeatedly? Examples?

.nl f.e.
Registrars get a monthly report on DNS errors with a score of how they technicaly compete to their competitors.
In addition to that, they get sent a feed of validation errors for DNSSEC for the domains under their control.
.nl managed to get validation errors down that way to improve DNSSEC adoption on resolvers.
See https://www.sidnlabs.nl/a/weblog/de-dnssec-validatiemonitor (in dutch, google translate is your friend)

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392

---

From: Mark Andrews <[email-masked]>
Date: Sat, 07 Nov 2015 07:17:18 +1100

In message <[email-masked]>, "Ralf Weber" write
> register domains, but repeatedly? Examples?

Yes.  Daily checks of all delegated server.  I don't believe they are
currently reporting the discovered faults.

	http://bamus.switch.ch/edns/summary.html

Others do as well.

ICANN runs regular checks of TLD servers and they do report when they
fail those checks for atleast some of the TLDs.

>    remove all delegations to said server from the zone."

Lots of BCP's have costs associated with them.  Checking delegations
and getting them corrected has always been part of their responsabilities
as has been removing delegations that cause operational problems

They really are not being ask to do anything that they should not
already be doing.  I would hope that they never have to remove a
delegation.  That sending a number of emails over several months
would be enough.  It will be for many sites.  They just need to be
informed that they have a issue and they will update to fixed
release.

Some will complain that the TLD's are being busybodies, but having
a document that says these checks should be being performed will
backup the TLD's.  Those that perform these checks today need this
backup.

TLD's will decide in the end whether they remove the delegation or
not.  Backing up that action with consensus that they should be
doing it helps the TLD should they do so.

> money by running DNS, that is cost.

If they don't run the DNS they don't get to take in the money.

> people only look at the money.

Part of running a good service is ensuring that the delegations
work.  This has always been part of there operational responsabilities
even if some of them would like to forget that.

TLD have also been required to remove delegations that cause
operational problems.  They do this today for sites that emit spam,
host malware etc.

Sites that use nameserver that are not rfc compliant do cause
operational problems.  Removing a delegation for that after repeated
attempts to get the issue addressed is no different than removing
a delegation for spaming.

Running nameservers that do not answer well formed queries causes
when a option is set or a flags is not zero cause operational
problems.

Running nameservers that return the wrong error code when option
is set or a flags is not zero cause operational problems.

Lookup are failing (present tense) due to these issues.  More will
fail as clients make more use features that should work for all
site and do work for the majority of sites.

We don't yet have clients sending EDNS(1) queries but EDNS flags,
EDNS options, DNS flags, and unknown types are all regular occurances.

Yes, there are sites today that don't repond to DO=1 queries.
Yes, there are sites today that don't repond to AD=1 queries.
Yes, there are sites today that don't repond to EDNS queries.
Yes, there are sites today that don't repond to EDNS queries with a EDNS option.
Yes, there are sites today that don't repond to various query types.

There are sites that respond with NXDOMAIN rather than NOERROR when
you do one of the above.

The operational problems that result from these behaviours should be
obvious to everyone on this list.

There are lots of other incorrect responses that cause operational
problems.

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 07 Nov 2015 16:17:40 +0100

Moin!

On 6 Nov 2015, at 18:50, Antoin Verschuren wrote:

> In addition to that, they get sent a feed of validation errors for 
> DNSSEC for the domains under their control.
Cool. Thanks for the link, and thanks to SIDN for doing this. Seems to 
be effective, though the number doesn't seem to go to 0. If I understand 
it correctly (or google translated it correct) there is no sanction for 
the registrar only information that something is not working.

So long
-Ralf

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 07 Nov 2015 17:10:52 +0100

Moin!

> 	http://bamus.switch.ch/edns/summary.html
Cool, but unless they inform someone it won't help improve anything.
Others do and it's good to see some people on the authoritative side
doing something about it. IMHO it's still a drop in the ocean.

> If they don't run the DNS they don't get to take in the money.
Ever heard of negative registration or the .sucks domain....

[lots of DNS operational failure modes deleted]
> There are lots of other incorrect responses that cause operational
I agree with you on both points, but that doesn't help to get these
wrong behaviours fixed. After working decades on operating recursive
servers I have lost hope that we will get these behaviours fixed.

Whenever such a thing occurs no customer gave a damn about the wrong
configuration of the authority, they all wanted the domain to resolve.
That is the reason why advancing new technologies in the DNS is so
difficult (impossible ;-).

Honestly I'd rather direct my energy to helping the end user with
DNS than fixing all the DNS misconfigurations on the internet, but
maybe this is because I'm getting old and have chased windmills
long enough ;-).

So long
-Ralf

---

From: Antoin Verschuren <[email-masked]>
Date: Sat, 7 Nov 2015 18:20:01 +0100

Op 7 nov. 2015, om 16:17 heeft Ralf Weber <[email-masked]> het volgende geschreven:

> Cool. Thanks for the link, and thanks to SIDN for doing this. Seems to be effective, though the number doesn't seem to go to 0. If I understand it correctly (or google translated it correct) there is no sanction for the registrar only information that something is not working.

The numbers don’t go down to 0 because there are also deliberately bad DNSSEC domains for testing and research purposes.
The registrars that do DNSSEC have another incentive to get this right.
If resolver operators of ISP’s don’t validate because of too many errors, the effort of registrars supporting DNSSEC in the first place will be in vain.
A sanction for regular DNS errors is that domains that repeatedly fail the technical checks can be deleted (by the registrar or registry) without the registrant’s consent according to the legal rules.
This was used quite often by registrars whose customers didn’t pay their bill on time. (simply stop serving DNS and that would give right to delete the registration).

But that’s not the point.
The point is that we need consensus on criteria for what is good and what is bad DNS(SEC).

I agree with you that there is no incentive for parked domains to get DNS right.
In fact, some registries like .nl allow registration without delegation, which is perfectly fine for those domains. It keeps the trash out the DNS.

But we need consensus on what good and bad DNS operation is so registrants have a choice.
For a domain that I don’t use, or only sometimes, some are perfectly happy with a dns-operator that charges $1,- a year but has a "DNS goodness” score of only 10%.
For a domain that is my principal business, I need a dns-operator (and a registrar, and registry, and ICANN!) that has a score of at least 99.999% compliance, even if it costs me $100,- a year.

The question is: What is is compliant, and how can we test that against a set of known errors so we can give them a score that has the consensus of us DNS experts.

And as Mark mentioned, many errors mean operational cost one way or another, not only for the name servers of the zone itself, but also for it’s parents and resolvers of ISP’s.

Parent and child dns-operators can make their own choice in business model in which they trade operational cost against profit and trust, but we need an independent set of criteria for those TLD's and dns-operators that want the reputation to be at the "good DNS” side of that business model. And for that to be possible, we need ICANN and so everyone below the root to be that good. We cannot let the weakest link determine the maximum quality of the DNS.

Perhaps a personal question to you: What score would you like the .de domain (not zone!) to have? And why? What would you do if they only scored 40% ?

- --
Antoin Verschuren

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 7 Nov 2015 19:11:05 +0000

> 	about what BCP actually do?

If this is about:

    https://datatracker.ietf.org/doc/draft-andrews-dns-no-response-issue/

then I for one strongly support its adoption.  I've been doing DANE
SMTP adoption surveys for over a year now, and have run into quite
a few nameserver operators with a number of DNSSEC issues.  I've
found especially the SIDN (.nl) registry very helpful in interfacing
with DNS hosting providers to address the reported issues, but have
also had some help from .cz, .se and .gov.  Today I reached out to
norid.no, they'll likely be helpful too.

It would be great if I did not have to nag each operator or hosting
provider I happened to find, and instead registries would make
periodic efforts to validate the correctness of all delegations.
Recommending this as a best practice seems quite reasonable.

As to what makes a delegation valid, it is not too difficult to
construct a sensible list of tests.  The dnsviz.net site seems to
have no trouble testing for a reasonably comphensive set of warnings
and errors.

In addition to all the obvious tests of the consistency of delegation
records with data at the zone apex, no lame delegations, DS records
having matching DNSKEY records, ... Based in part on:

    https://datatracker.ietf.org/doc/draft-andrews-dns-no-response-issue/

I'd also check for:

    * Not dropping queries for unexpected RRtypes (which are
      misguidedly droppped as a "security feature" by some systems).
      Especially TLSA RRs, which are starting to get used with SMTP.

    * Correct processing of denial of existence in signed zones:

	; Check for valid NXDOMAIN or NODATA (if wildcard applies)
	;
	made-up-label2.made-up-label1.<zone-apex>. IN A ?
	made-up-label2.made-up-label1.<zone-apex>. IN AAAA ?
	made-up-label2.made-up-label1.<zone-apex>. IN TLSA ?

	; Check for valid NXDOMAIN or NODATA (if wildcard applies)
	; if in bailiwick known names exist below the zone apex.
	; Names of MX hosts are often a good source of such names.
	;
	made-up-label2.made-up-label1.known-name.<zone-apex>. IN A ?
	made-up-label2.made-up-label1.known-name.<zone-apex>. IN AAAA ?
	made-up-label2.made-up-label1.known-name.<zone-apex>. IN TLSA ?

For example, papaki.gr returns NSEC RRsets with no RRSIG for multiple
domains:

    @dns1.papaki.gr
    ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24618
    ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    ;_25._tcp.mail.3814.eu. IN TLSA
    3814.eu.                SOA     dns1.papaki.gr. hostmaster.papaki.gr. 2015101800 10800 3600 1209600 3600
    3814.eu.                RRSIG   SOA 5 2 86400 20160218062849 20151018062849 12273 3814.eu.
    mail.3814.eu.           NSEC    webmail.3814.eu. A RRSIG NSEC
    3814.eu.                NSEC    mail.3814.eu. A NS SOA MX RRSIG NSEC DNSKEY

I notified them, whether action will be take is not yet clear.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 08 Nov 2015 10:52:13 +1100

In message <[email-masked]>, "Ralf Weber" write
> maybe this is because I'm getting old and have chased windmills

Fixing misimplementations of the protocol is different to fixing
misconfiguration of servers.  The draft is aimed primarially at
fixing misimplementations rather than misconfigurations though both
need fixing.

To fix misimplementation of the protocol you work your way back to
the vendors to get the server or firewall fixed at the source then
install the fixed server / firewall.  Once you fix a misimplementation
it stays fixed as there is nothing to change other than upgrading
the server / firewall.

I do know that TLD servers get fixed and stay fixed [1].  We are
yet to attempt to do this sort of thing in lots to TLDs at the same
time.

There has never been a concerted effort to fix protocol errors by
asking the parents to check the child servers and informing the
operators that they are broken.

Most servers actually do the right thing and not all errors stop
interoperation.  e.g. echoing back a client cookie doesn't actually
stop DNS resolution.  For some other option this would be fatal
which is why we want to clean the ecosystem of broken servers now
rather than later.  To test more that what is causing immediate
problems.

As a vendor you (Nominum) should be checking the servers you ship
are compliant.  If you find ones that are out of compliance you
should be fixing them and informing your customers that there are
fixed servers available.  Compliance tests should be part of the
QA process.

Mark

[1] https://ednscomp.isc.org/compliance/ts/tld.html
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Ralf Weber" <[email-masked]>
Date: Sun, 08 Nov 2015 10:12:44 +0100

Moin!

> The point is that we need consensus on criteria for what is good and 
Isn't that what the RFCs describe. Is there really a point where someone 
disagrees?

> In fact, some registries like .nl allow registration without 
> delegation, which is perfectly fine for those domains. It keeps the 
> trash out the DNS.
>
> For a domain that I don’t use, or only sometimes, some are perfectly 
> happy with a dns-operator that charges $1,- a year but has a "DNS 
> goodness” score of only 10%.
> For a domain that is my principal business, I need a dns-operator (and 
> a registrar, and registry, and ICANN!) that has a score of at least 
> 99.999% compliance, even if it costs me $100,- a year.
I don't think that this is what Mark wants.

> The question is: What is is compliant, and how can we test that 
> against a set of known errors so we can give them a score that has the 
> consensus of us DNS experts.
My understanding was that Mark was testing protocol compliance and not 
operational aspects. I agree that there might be good and bad 
operations, but defining this is really hard as there are some many ways 
to operate DNS.

> And as Mark mentioned, many errors mean operational cost one way or 
> another, not only for the name servers of the zone itself, but also 
> for it’s parents and resolvers of ISP’s.
I know that. I worked at ISPs and now work at vendor that delivers 
software mainly for ISPs.

> Parent and child dns-operators can make their own choice in business 
> model in which they trade operational cost against profit and trust, 
> but we need an independent set of criteria for those TLD's and 
> dns-operators that want the reputation to be at the "good DNS” side 
> of that business model. And for that to be possible, we need ICANN and 
> so everyone below the root to be that good. We cannot let the weakest 
> link determine the maximum quality of the DNS.
Even if you have ICANN there are some that don't want to bend to the 
ICANN rules and this is an IETF draft.

> Perhaps a personal question to you: What score would you like the .de 
> domain (not zone!) to have? And why? What would you do if they only 
> scored 40% ?
You really have to ask Peter as he is "responsible" for that ;-). The 
.de zone I believe is pretty good as it always had pre delegation tests 
(sometimes with strange rules), but the problem for people on the 
resolving side isn't really if the domain is 40% or 99% good. As long as 
it is not 100% which IMHO it never will be we have to do something to 
make the 1% incorrect behaviour to work.

So long
-Ralf

---

From: "Ralf Weber" <[email-masked]>
Date: Sun, 08 Nov 2015 10:32:34 +0100

Moin!

> fixing misimplementations rather than misconfigurations though both
Sorry I over generalised. To the receiving end everything were one
has to do something because of an unexpected result the work is
the same.

> fixed servers available.  Compliance tests should be part of the
We do that, but we have lot more tests that make sure the server
still works/resolves when someone on the authoritative side screwed
up.

So long
-Ralf

---

From: Daniel Stirnimann <[email-masked]>
Date: Tue, 10 Nov 2015 11:36:25 +0100

> doing something about it. IMHO it's still a drop in the ocean.

True, we are not reporting this information automatically to domain
holders or technical contacts.

I'm using it when I happen to discuss DNS issues with registrars,
hosters are domain owners. Some of the largest .ch hosters got their DNS
server fixed after that. However, overall my effort is a drop on a hot
stone.

Daniel

-- 
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
[email-masked], http://www.switch.ch

---

From: Shane Kerr <[email-masked]>
Date: Tue, 10 Nov 2015 15:25:11 +0100

Mark,

On Fri, 06 Nov 2015 10:54:02 +1100

> 	about what BCP actually do?

My guess is that part of the resistance is because you are going to be
asking people to spend money on something that does not provide them or
their customers any (direct) benefits. Further, it breaks the
registry-registrar model in some cases, where registries are kept away
from registrants by a 1.6 km-high wall.

My prediction about the eventual outcome is that you would end up with a
document that works as well as BCP 38; meaning that it is nice to have
for people that want some recommendations about what to check (and
can't be bothered to look at other registries' online documentation, or
contact registries directly and ask what they do).

If your true goal is to get ICANN to act as the some sort of enforcer
for DNS operational purity, then please do so via ICANN channels rather
than the IETF. ;)

To be clear, I am not opposed to a document which lists various checks
a parent zone may want to do, and the costs & benefits of each, as long
as it doesn't end up with you screaming at the microphone because TLD
.XX doesn't implement the recommendations. :)

Cheers,

--
Shane

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Nov 2015 07:43:30 +1100

Perhaps we should be getting Jari, Suzanne and Andrew to push this
at IGF meetings.

In message <[email-masked]>, Shane Ker
> from registrants by a 1.6 km-high wall.

Who are the customers of a registry?  The registrants and those
that lookup names in the registry.  Yes, everyone else *is* a
customer of the registry and by performing tests and informing the
registrants you help both sets of customers.

As for costs, a machine/vm running checks and sending out email
every 3 months.  That's effectively all
<https://ednscomp.isc.org/compliance/summary.html> is though it doesn't
send the email and it runs the checks daily, it does have to hooks
to send out email built in but they are not activated.  Once this
becomes a regular thing many/most/all tlds do the human costs go
down as it becomes something people can lookup answers for what to
do when they get the email.

You ask the registant to contact their DNS/Firewall vendor for the
fix after explaining the issue.  If they are hosting their own DNS
they should know who that is.  If they are using a DNS operator the
message gets relayed to the operator or they can switch DNS operators
to one which does the right thing.  The DNS operator then needs to
contact their vendors for a fix.

As for the no direct contact this doesn't require direct contact.
The registrars can perform the checks for the servers of all zones
registered through them or they can relay the messages from the
registry.

> contact registries directly and ask what they do).

So we don't say what's right because you fear that not everybody
will perform the actions.  We don't need to get every TLD to check
to have a real impact.  We just need several to check and inform,
preferably big ones.  Lots of zones are hosted by big players and
getting them fixed has a big impact on the overhaul health of the
DNS.  e.g. UltraDNS and related companies fixing their service
resulted in a 18% fix for the root and TLD servers, a 5% fix for
the Alexa top 1000, a 2% fix for Gov servers in the Alexa top 1M
and about the same for the AU servers in the Alexa top 1M.  The
bottom 1000 is too noisy to see if there was a change there.  See
the Sep 28 2015 steps in <https://ednscomp.isc.org/compliance/ts/allok.html>.

> for DNS operational purity, then please do so via ICANN channels rather

This is actually IETF business.  We can set community consensus of
what is a resonable requirement.  If nothing else ICANN will come
back to us looking for checks to be enforced.  Additionally the
CCtlds are not bound by ICANN but by RFCs.

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 10 Nov 2015 13:11:25 -0800

> Perhaps we should be getting Jari, Suzanne and Andrew to push this

Or perhaps we should not.

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Tue, 10 Nov 2015 21:24:37 +0000

> On 10 Nov 2015, at 21:11, Paul Hoffman <[email-masked]> wrote:
> 

+1

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Nov 2015 05:15:03 +0000

> Perhaps we should be getting Jari, Suzanne and Andrew to push this

Not knowing what IGF meetings are, I can't comment on this specific
point.

> the Sep 28 2015 steps in <https://ednscomp.isc.org/compliance/ts/allok.html>.

I strongly support publication of a BCP that expains a best practice
in this space.  Even my meager efforts at remediating problems in
this space, without access to comprehensive domains lists or good
contact information for some of the parties have been effective at
reducing barriers to DANE adoption for SMTP by an order of magnitude,
but we can and should do better, and registries/registrars are far
better positioned to take the appropriate action.

I've been fowarding links to Mark's draft to various guily parties,
as it provides a solid explanation of why their nameservers are
wrong and how they should behave.  It would be even more useful as
an RFC.

The reason that the TLSA records for fbi.gov are not broken is
because they no longer drop TLSA queries, the folly of which is
explained in the draft.

Have not yet had much luck with the disa.mil who operate the
nameservers for mail.mil.  This would be much easier if, for example,
the .gov and .mil conducted periodic tests of their delegated
domains.

> CCtlds are not bound by ICANN but by RFCs.

Indeed.

-- 
	Viktor.

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 11 Nov 2015 07:25:39 +0100

>> Or perhaps we should not.

This discussion on making tests is coming back now and then. In RIPE, in IETF, in discussions around TLDs (specifically ccTLDs).

I have run one such initiative myself.

Everything has so far collapsed into collision between tech people not agreeing on what is right and wrong. It also collapses into clashes between registry policy and the tests made. I.e. just the registration policy is setting blocks and constraints on what tests must be made (or can not be made). And harmonization of such rules is just impossible (we have seen).

That said, initiatives like the one I did run did push errors (for some definition of errors) from 22% to maybe 17% in .SE and my inspection of the rest say that getting errors down to 15% is possible, but more is very hard.

And, having a BCP or such that give suggestions on what can be viewed as "correct" would not be bad, but how to use it must be up to the reader.

I think the IETF should be careful on writing too prescriptive text, I say being one hit by "rfc compliance" people that point at old whois related RFCs that "require" things that in fact is illegal in Sweden. I.e. by being compliant to Swedish law regarding privacy, I violate a very old RFC and because of that I am black listed.

So be careful.

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Nov 2015 17:44:53 +1100

In message <[email-masked]>, "Patrik =?utf-8?b
?RsOkbHRzdHLDtm0=?=" writes:
> This discussion on making tests is coming back now and then. In RIPE, in
> IETF, in discussions around TLDs (specifically ccTLDs).
>
> Everything has so far collapsed into collision between tech people not
> agreeing on what is right and wrong. It also collapses into clashes
> between registry policy and the tests made. I.e. just the registration
> policy is setting blocks and constraints on what tests must be made (or
> can not be made). And harmonization of such rules is just impossible (we
> have seen).
>
> That said, initiatives like the one I did run did push errors (for some
> definition of errors) from 22% to maybe 17% in .SE and my inspection of
> the rest say that getting errors down to 15% is possible, but more is
> very hard.
>
> And, having a BCP or such that give suggestions on what can be viewed as
> "correct" would not be bad, but how to use it must be up to the reader.
>
> I think the IETF should be careful on writing too prescriptive text, I
> say being one hit by "rfc compliance" people that point at old whois
> related RFCs that "require" things that in fact is illegal in Sweden.
> I.e. by being compliant to Swedish law regarding privacy, I violate a
> very old RFC and because of that I am black listed.
>
> So be careful.

Which is why draft-andrews-dns-no-response-issue-13 focuses on
nameserver and firewall behaviour and not data content.  I haven't
had anyone say that any of the tests listed there are wrong.

Fixing this class of error is almost always upgrade the software
to something that is actually rfc compliant.  The only thing which
is tends to be user configurable is turn on/off DNS checks in the
firewall and in reality the firewall vendor shouldn't have been
blocking on what they were blocking in the first place.

Mark

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Nov 2015 06:47:44 +0000

On Wed, Nov 11, 2015 at 07:25:39AM +0100, Patrik Fältström wrote:

> agreeing on what is right and wrong. It also collapses into clashes between
> registry policy and the tests made. I.e. just the registration policy is
> setting blocks and constraints on what tests must be made (or can not be
> made). And harmonization of such rules is just impossible (we have seen).

It may not be possible for everyone to agree on a comprehensive
set of 'wrongs' with no omissions, but it should be possible to
get consensus on a core set of 'wrongs' that are not controversial.

For DNSSEC domains (from actual observations), at least some of
the below should be widely seen as mistakes to avoid: 

  * Dropping TLSA (or other "unexpected" RRtype) queries is wrong.
    A simple NODATA or NXDOMAIN is the right way to go.

  * Returning wildcard responses for children of a sibling empty
    non-terminal is wrong.
 
  * Returning NXDOMAIN with proof of NODATA is wrong.

  * Returning NODATA with proof of NXDOMAIN is wrong.

  * Returning incorrect denial of existence NSEC/NSEC3 records for
    nodes that are not immediately below the zone apex is wrong.
    (Essentially failure to establish the proper closest encloser,
     and proof of non-existence of its immediate descendant and
     child wildcard).

  * Returning an incorrect SOA RRSIG with negative replies is wrong.
    Especially when queries for the SOA itself return a correct RRSIG.

  * Returning NSEC/NSEC3 records with no associated RRSIGs is wrong.

  * Having DS records in the parent zone with no matching DNSKEYs
    at the zone apex is wrong.

  * ...

  * Lame delegations are wrong.

  * Setting the NSEC3 opt-out bit for "non-registry" zones is not
    recommended.

I am sure we can flesh out a list.  A good start might the issues
which "dnsviz" flags as "error" or "bogus".  Even some "dnsviz"
warnings are worth highlighting, such as conflict between the
delegation NS records and the zone apex NS records.

-- 
	Viktor.

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 11 Nov 2015 07:53:25 +0100

> get consensus on a core set of 'wrongs' that are not controversial.

Yes and no. I think going for a minimum will be a good goal, but for example to have lame delegations must by definition be allowed, as some registration policies do require delegation (i.e. NS records). So people add NS records in parent zone, but nothing responds there. Until policy allows registration without delegation, you will see lame delegations.

   Patrik

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Wed, 11 Nov 2015 09:11:45 +0200

For smaller (cc)TLDs it's not only the enforceability that's
difficult (or as mentioned counterproductive) it's also the real
world (Open Source Tools)

If someone writes me a zonemaster based tool that can read a list of
all domain names in the CoCCAtools PostgreSQL (or even a generic
SQL) database and produce a skeleton of a report (per Registrar)
I'll run it for .NA (and I am sure others using CoCCATools might
too).

I do a lot of LaTeX so I can generate reasonably looking PDF
reports.

We have allocated (staff) resources to a whois cleanup anyway and so
this could be incorporated reducing manual labor.

And we have decided to devote some time at the next TechDay at ICANN
Marrakesh to (algorithmic) data cleanup/verification including
badness checks eg via Secure Domain Foundation and others(.

So whatever comes out of that could, eventually, also go in.

el

On 2015-11-11 08:53, Patrik Fältström wrote:
> Yes and no.  I think going for a minimum will be a good goal, but 
> for example to have lame delegations must by definition be allowed,
> as some registration policies do require delegation (i.e. NS
> records).  So people add NS records in parent zone, but nothing 
> responds there.  Until policy allows registration without 
> delegation, you will see lame delegations.
> 
> Patrik

- -- 
Dr. Eberhard W. Lisse  \        / Obstetrician & Gynaecologist (Saar)
[email-masked]            / *     |   Telephone: +264 81 124 6733 (cell)
PO Box 8421             \     /
Bachbrecht, Namibia     ;____/

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 11 Nov 2015 08:20:06 +0100

> On 11 nov. 2015, at 08:11, Dr Eberhard W Lisse <[email-masked]> wrote:
> 

I completely agree.

My only point is that I urge IETF to write text som that any(!) reader can understand there will always be cases where "errors" for various reasons are reasonable or even ok.

Any tests will bring down errors a lot.

But last 10-15% is hard.

So let's bring down errors "some" and declare success.

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Nov 2015 19:23:04 +1100

In message <[email-masked]>, Dr Eberhard W Lisse writes:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Well we have tools that can test every server in a zone.

They can start with a list of domains, domains and servers, or
domains, servers and addresses.  Adding in the registrar so the
output can be sorted by registrar is trivial.  Just another field
to process.

They produce lines like this for each <domain,server,address> tuple.

clinicaltrial.gov. @2607:f220:41e:252::53 (gslb03.nlm.nih.gov.): dns=ok edns=ok edns1=timeout edns@512=noopt ednsopt=ok edns1opt=timeout do=ok ednsflags=ok optlist=ok

Well we have tools that then turn the output into reports like:

* https://ednscomp.isc.org/compliance/gov-full-report.html
* https://ednscomp.isc.org/compliance/summary.html

All in all it is no more than a few shell and awk scripts.

Mark

> On 2015-11-11 08:53, Patrik F=E4ltstr=F6m wrote:
> > =
> >> It may not be possible for everyone to agree on a comprehensive =
> 
> >> set of 'wrongs' with no omissions, but it should be possible to =
> 
> >> get consensus on a core set of 'wrongs' that are not =
> 
> >> controversial.
> > =
> 
> > Yes and no.  I think going for a minimum will be a good goal, but =
> 
> > records).  So people add NS records in parent zone, but nothing =
> 
> > responds there.  Until policy allows registration without =
> 
> > =
> - -- =
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> 
> iQIVAwUBVkLqMZcFHaN5RT+rAQIzlw//SkiY/urbpw/KT0CmqBUKcrmY8R0rChut
> 05SaKNCjdvxgbu2I2ZP7e59xBKgyBJfWY+Dc2VKtl9q9aqygUXLKHPyV0kL5LTzJ
> TwZWE8y8ePJcneHbU0SyeU8TEMMDDcpX8VR4NoLbCmkZ+gKrAvtB4vrh4CQTLKAd
> gUiUmeuw8q8uZVW2pOWoCx4vcc+hcrXLAUC0OVoP7uud22h4fBcl4sRmgLlD79E9
> q7TvM3eXmPIBydW6YvzEc6mx+Jd449ASCBCDXjKqzPE2vGvu8fWui7qFYwrpKMIU
> OZDMGKCT6oM1g88BOctB2e+8hP0GVSCjYg6HGUTiKWiFsXjP5986AlkpWmX+mV2F
> rgN9B6dqxK5omMEQf/inQBAA8Irzrm8HrPy2+Uru7QYq9v7M0xBb05k+vljM5Qhr
> CbGZGbd67CqYROoqC8UvmSXRz8W5IbcHlG3rujB2g18q/LQGIosgXPKE56OWCZIz
> LanWM+n85pUocmUnQEnqG61nPx/+AadxY5Hp/BoWY7VvRzoI3ohsZPcMRp/uObzf
> f81D9RvhWARcmB3qyoT/RAhkx2dFIoz7iWUbgGlnPyyHthP8SL8W0YFKzSfcJAmO
> XAEAk/1At4t8jD4ZJpVEWruVsbL+7h9+E9ZS8xBnaT37XtjXkmV2eCx9PIRdR8rM
> Ih1jXfMw8KM=3D
> =3DKyjz
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Nov 2015 09:00:02 +0000

On Wed, Nov 11, 2015 at 07:53:25AM +0100, Patrik Fältström wrote:

> Yes and no. I think going for a minimum will be a good goal, but for
> example to have lame delegations must by definition be allowed, as some
> registration policies do require delegation (i.e. NS records). So people
> add NS records in parent zone, but nothing responds there. Until policy
> allows registration without delegation, you will see lame delegations.

My quick and dirty list is likely not "the list".  Mark correctly
points out starting with protocol (rather than content) issues is
a good idea.  Since lame delegations are content, they might be
out of scope.  I think that broken denial of existence is also a
protocol (software quality) issue, rather than zone data content.

This is not to say that no content issues can be in scope, but
likely those would need closer scrutiny.

For example, having DS RRs with no corresponding DNSKEY RRs invites
serious trouble, and does not seem to have a plausible reason (like
lame delegations).  But I'm presently setting any specifics in stone.

Just saying that progressing Mark's draft looks like a good idea
to me.

-- 
	Viktor.

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Wed, 11 Nov 2015 11:03:06 +0200

Mark,

please point me to the tools :-)-O

el

On 2015-11-11 10:23, Mark Andrews wrote:
[...]
>> Well we have tools that can test every server in a zone.
[...]

---

From: Paul Vixie <[email-masked]>
Date: Tue, 10 Nov 2015 23:18:50 -0800

> Perhaps we should be getting Jari, Suzanne and Andrew to push this

that's a right-thinking goal but with incorrect implementation semantics.

for IGF to care about this, you'd have to show the cost to end users and small domain 
holders, and i don't think it's compelling on that basis.

the best thing to do is write up a BCP-intended draft on what registrants, registrars, and 
registries should each do to check/maintain their registration information (NS, DS, and 
related AAAA or A), covering both motivation and method, with pointers to current open-
source tools, and references describing who has tried this in the past (or currently) and 
how it worked out for them.

then, ask jim galvin of ICANN SSAC, and andrei robachevsky of ISOC, to consider this as a 
possible topic to cover in next year's SSAC/ISOC panel at IGF. in other words there's not 
time to get this onto this year's schedule, but a well written and non-controversial IETF 
draft (or maybe RFC/BCP by then) would form an excellent basis for a highly relevant 
panel on internet stability.

fwiw, the best registry level checking i ever saw was at .BR by frederico neves and his 
team. you'll want him as a co-author of this draft, IMHO.

vixie

---

From: Havard Eidnes <[email-masked]>
Date: Wed, 11 Nov 2015 11:17:35 +0100 (CET)

> Yes and no. I think going for a minimum will be a good goal,
> but for example to have lame delegations must by definition be
> allowed, as some registration policies do require delegation
> (i.e. NS records). So people add NS records in parent zone, but
> nothing responds there.

I think I don't understand the scenario you're sketching up here.
Furthermore, I don't think I understand why you argue that such a
setup must be acceptable.

Does the scenario look like this?

* Client asks to registrar to set up frobbit.se
* Registrar is lazy and doesn't want to set up a separate zone, so
  instead sets up his own fake .se zone where he puts the data for
  frobbit.se, including delegating NS records which points
  towards the servers serving the fake .SE zone.
* Registrar contacts the registry to have frobbit.se registered
  as a delegation

I've heard anectdotal evidence about folks doing that, and being
denied doing so by registry checks because the SOA record comes
out wrong.

But this doesn't create a lame delegation (does it?) so I don't
think I understand what you're saying.

A zone registered with delegation records, but where none of the
name servers respond to queries for the zone does noone any good,
so why must it be acceptable?  Maybe my imagination can't fathom
the reasons why people insist on creating lame delegations.

> Until policy allows registration without delegation, you will
> see lame delegations.

Again, please explain.

Maybe I'm spoiled by our local CC registry insisting on certain
technical checks passing before registration can be allowed to
proceed.  I'm not saying we're without lame delegations, though,
but I think they occur for other reasons (post-registration
changes, badly-managed transisions).

Regards,

- Håvard

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 11 Nov 2015 11:27:54 +0100

> * Client asks to registrar to set up frobbit.se

Yes, someone want to register frobbit.se domain name. For pure IPR reasons. It should not resolve.

> towards the servers serving the fake .SE zone.

Registry requires NS records and not only a creation of the domain object.

Registrar because of this adds fake NS records.

> * Registrar contacts the registry to have frobbit.se registered

To register a domain name in this example, the TLD do require not only a creation of the domain object, but also link between domain object and some (fake) host records.

The example of your is a way weird though as .SE do allow creation of domain objects without delegations.

Other TLDs are different.

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 11 Nov 2015 11:29:41 +0100

On 11 Nov 2015, at 11:17, Havard Eidnes wrote:

> so why must it be acceptable?

Because only registration of the domain name is what is wanted.

No one want records in the DNS for the domain name. No one asks for such things. Except the registry in some cases.

Some registries even requires MX records at the zone apex! Even more weird.

   Patrik

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2015 10:29:45 +0000

Viktor Dukhovni <[email-masked]> wrote:

A good list of problems. Sounds like it was a lot of hard work discovering
those!

>     at the zone apex is wrong.

It's OK provided that at least one DS of each algorithm has a matching
DNSKEY. You get dangling DS records during a "Double-DS" KSK rollover
(RFC 6781).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Tyne, Dogger, Fisher, German Bight, Humber: Southwest 5 to 7. Moderate or
rough. Rain at times, showers later. Moderate or good, occasionally poor.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Nov 2015 11:42:09 +0100

On Wed, Nov 11, 2015 at 11:29:41AM +0100,
 Patrik Fältström <[email-masked]> wrote 

> Some registries even requires MX records at the zone apex! Even more weird.

Less so now that we have RFC 7505.

---

From: Havard Eidnes <[email-masked]>
Date: Wed, 11 Nov 2015 11:44:04 +0100 (CET)

> IPR reasons. It should not resolve.

Ah, OK.  Then this is first and foremost a registry policy issue:
do you in your policy support registration of a place-holder /
blocker entries without any associated DNS information or not.

The registry in my backyard doesn't support place-holder
registrations, insists on delegation-only DNS information, and
insists on this being fully operational with a minimum of two
name servers before registration can complete.

If your naming policy of your registry doesn't formally allow
place-holder registrations, insists on delegation-only DNS
information, but makes no checks of the supplied information at
the time of registration, I agree that this will more or less
automatically create lame delegations.  That doesn't mean the
resulting setup in the DNS is "OK" from a DNS-technical
standpoint.  However, as a registry or policy body for the
registry you're not forced to put yourself in this particular
position.  (I might have used stronger words...)

> Other TLDs are different.

That we can agree on :)

Regards,

- Håvard

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 Nov 2015 11:48:33 +0100

On Tue, Nov 10, 2015 at 03:25:11PM +0100,
 Shane Kerr <[email-masked]> wrote 
 a message of 49 lines which said:

> My guess is that part of the resistance is because you are going to
> be asking people to spend money on something that does not provide
> them or their customers any (direct) benefits. Further, it breaks
> the registry-registrar model in some cases, where registries are
> kept away from registrants by a 1.6 km-high wall.

+1 && +1

We at AFNIC have a long experience here since, during many years, we
requested successful technical checks before registering a domain (at
this time, there was no registration without delegation). It annoyed
people a lot and we got a reputation of pain-in-the-ass stupid french
people, always insisting on local and anti-american requirments (see
<http://www.circleid.com/posts/afnic_dns_server_redelegation/> for a
good example).

I'm not eager to try it again, unless people pledge to support us
during flames on social networks.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Nov 2015 22:18:58 +1100

> during flames on social networks.

Part of writing the I-D and trying to consensus through DNSOP rather
than going as a I-S is to provide the a backstop for registries
that check.  The more registries that check the better for everyone.
Support in numbers.

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 11 Nov 2015 12:36:21 +0100

> Less so now that we have RFC 7505.

Sure, but still do for example FI, DE and HU this. TR even require a web page.

   Patrik

---

From: Lawrence Conroy <[email-masked]>
Date: Wed, 11 Nov 2015 12:22:05 +0000

Hi Patrik, Jim, folks,
+1

Not an IETF thing, but ISTR that the RRR model can make pushing error reports difficult:
 e.g., if Registry runs tests and finds problems, the Registrar may be unhappy for an email
 to be sent from Registry direct to "the Registrar's" customer.

Quite apart from anything else, do delegated domain DNS validity checks figure within gTLDs?
 If not, then any USE of such a BCP is going to go to ICANN (and take years and years and ...), no?
 ISTM that the IETF isn't in a position to force its suggestions through the 'industry'.

all the best,
  Lawrence

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Nov 2015 18:05:26 +0000

>  ISTM that the IETF isn't in a position to force its suggestions through

Who said anything about "forcing", I thought this was intended to
be a BCP.  As for whether the checks are done by registries or
registrars: ideally both!

    * Registrars check their customer domains and notify the customer.

    * Registries checks all domains to apply soft pressure on
      registrars with whose domains are notably more broken than
      average.

For example, I've worked directly with some .nl registrars, and
indirectly with SIDN to resolve the highest visibility problems
wrt. DANE TLSA and .nl domains.  Small pockets of problems remain,
and SIDN are doing proactive monitoring.

So in the last year or so, we've seen DNS server upgrades that
resolved issues at transip.nl, hostnet.nl, hosting2go.nl,
metaregistrar.nl and sonexo.nl.  Still waiting on axc.nl, but IIRC
they're working on it.  The incidence of broken DNSSEC TLSA lookup
in .nl is down by two orders of magnitude over the last year.

In the .se case, citynetwork.se fixed their firewall that was
dropping TLSA queries, and IIRC I was in touch with someone at at
the .se registry to help encourage them to do that.

My efforts don't scale, and I believe a sensibly worded BCP would
be quite useful.  It would explain what's important to remediate
and why.  I may motivate some proactive TLD operators and their
registrars to do the right thing voluntarily.

-- 
	Viktor.

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 11 Nov 2015 15:56:07 -0500

On 11 Nov 2015, at 13:05, Viktor Dukhovni wrote:

>> ISTM that the IETF isn't in a position to force its suggestions 
>> through
>> the 'industry'.
>

If this thread is really going to continue, in defiance of all logic and 
common sense, can we at least remove the apostrophe from the subject 
line? It makes me twitch.

Joe

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 11 Nov 2015 19:20:01 -0200

...
> That said, initiatives like the one I did run did push errors (for some definition of errors) from 22% to maybe 17% in .SE and my inspection of the rest say that getting errors down to 15% is possi…

Enforcing at delegation and change time and checking and reporing on a
regular basis, weekly and montly respectively, brought us to 5%.

http://registro.br/estatisticas.html

Look at the botton "Status das Delegações" and follow the total error
links to trending graphics.

> And, having a BCP or such that give suggestions on what can be viewed as "correct" would not be bad, but how to use it must be up to the reader.

Agree,

Fred

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 11 Nov 2015 16:30:33 -0800

(as chair)

I was the one who told Mark I liked the document but we needed to do 
less badgering of TLDs (my words, not his) and more on giving them 
advice on the best practices.

I'm stuck in the office in San Francisco this week, but I will read the 
newer versions.  It sounds like something we can adopt, though it may be 
contentious and need some work.  I'm not against contentious drafts, and 
I'm not against doing some work.

tim

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 12 Nov 2015 15:13:09 +0100

+1

I'd like to add that they may be badgered just as hard from the other
side not to do too much in this regard; i.e. registrars telling them
"Don't tell me how to do my work, even if you think it's wrong". Sure,
BCPs may help, but we stopped doing pre-delegation checks for a reason.

As Antoin and others have already mentioned, we still do checks, and we
inform on a number (but not all) of them. One thing we found (at least
that has been my conclusion) is that 'they are doing it better' works
*much* better than 'you are doing it wrong'.

Removing delegations because of a lame delegation is highly likely to be
out of the question.

Jelte

---

From: Dr Eberhard W Lisse <[email-masked]>
Date: Thu, 12 Nov 2015 16:42:57 +0200

Jelte,

don't forget there are ccTLD registries run by third parties for
purely economic reasons, some better some worse.  And a particular
compatriot comes to mind :-)-O

Then there are a number of smaller ccTLDs which are overwhelmed by
all of this.  Never mind those who only answer their email when they
get offered travel funding.

And then there is not only the purely technical DNS accuracy but the
quality of the Registrant data is often very poor, Whether this is
published in the WHOIS or not, this could and should be addressed at
the same time.

But what really is lacking is not only a BCP that addresses all of
this but also an Open Source reference implementation of a quality
that is actually usable.

If I could auto-generate a report for each of or Registrars that
lists all issues we have identified there are some who will try and
fix it because they like to do proper work.

Some will need a little name and shame.

Some I can motivate with our policies which they have contractually
bound themselves to.

Other ccTLDs might not be able to do that, or might choose not to do
that.

But unless we have some actual tools this remains an academic
exercise.

el

On 2015-11-12 16:13, Jelte Jansen wrote:
>> I was the one who told Mark I liked the document but we needed to
>> do less badgering of TLDs (my words, not his) and more on giving
>> them advice on the best practices.
>>
> 
> +1
> 
> I'd like to add that they may be badgered just as hard from the
> other side not to do too much in this regard; i.e. registrars
> telling them "Don't tell me how to do my work, even if you think
> it's wrong".  Sure, BCPs may help, but we stopped doing
> pre-delegation checks for a reason.
> 
> As Antoin and others have already mentioned, we still do checks,
> and we inform on a number (but not all) of them.  One thing we
> found (at least that has been my conclusion) is that 'they are
> doing it better' works *much* better than 'you are doing it
> wrong'.
> 
> Removing delegations because of a lame delegation is highly likely
> to be out of the question.
> 
> Jelte
[...]