Subject: [DNSOP] finalizing draft-ietf-dnsop-no-response-issue-01

From: Suzanne Woolf <[email-masked]>
Date: Thu, 18 Feb 2016 11:44:21 -0500

Hi,

This is a reminder to the WG about this draft: https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-01.

Several people offered to review previously, and we've already pinged them. However, there's no need to limit yourself from participating just because you didn't volunteer :-)

There's a new revision of the draft as of December 2015 (thanks, Mark!). If the WG's earlier questions about this draft are answered, and it's generally ready to advance, the chairs would like to do a WG Last Call. But first it would be reassuring to have some in-depth reviews of the newest version.

If you have some time for a careful reading of the draft, and to send a review to the author and the WG, it will be greatly appreciated. 

It's particularly helpful if you can flag:
	* places where the text might not be clear
	* places where assumptions or recommendations may need additional support
	* things that could be removed (redundant or unnecessary)
	* any issues you think the WG should discuss further

The current requested status is BCP, which means extra review by the IESG and an IETF-wide Last Call, so let's resolve any issues first.

thanks,
Suzanne & Tim

---

From: Bob Harold <[email-masked]>
Date: Fri, 19 Feb 2016 15:51:49 -0500

On Thu, Feb 18, 2016 at 11:44 AM, Suzanne Woolf <[email-masked]>
wrote:

> Hi,
>
> This is a reminder to the WG about this draft:
> https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-01.
>
> Several people offered to review previously, and we've already pinged
> them. However, there's no need to limit yourself from participating just
> because you didn't volunteer :-)
>
> There's a new revision of the draft as of December 2015 (thanks, Mark!).
> If the WG's earlier questions about this draft are answered, and it's
> generally ready to advance, the chairs would like to do a WG Last Call. But
> first it would be reassuring to have some in-depth reviews of the newest
> version.
>
> If you have some time for a careful reading of the draft, and to send a
> review to the author and the WG, it will be greatly appreciated.
>
> The current requested status is BCP, which means extra review by the IESG
> and an IETF-wide Last Call, so let's resolve any issues first.
>
>
> thanks,
> Suzanne & Tim
>
> Typographical concerns:

2.4.  EDNS Flags
"there" should be "they"

4.  Firewalls and Load Balancers
"Requests with unknown EDNS versions is expected client behaviour
   should not be trued as an attack The correct behaviour for unknown
   EDNS versions is to return BADVERS along with the highest EDNS
   version the server supports."
Missing period (".") at the end of the first sentence.
"trued" should "construed"

-- 
Bob Harold

---

From: "John Levine" <[email-masked]>
Date: 21 Feb 2016 19:59:06 -0000

Minor errors:

2.1: "otherwise identical responses" -> "otherwise identical queries"

8.1: something's dodgy with the XML, the html version that xml2rfc
produces puts the examples before the corresponding text rather than after.

Section 2:

I'd use a word other than "class" since it's not used in its DNS
technical sense.

Section 3:

While I agree that it would be a good idea for TLD operators to audit
the name servers to which their 2LDs are delegated, contacting people
who can fix it is a mess.  While there are only three TLDs where the
registrar keeps the WHOIS info, two of them are the large .NET and
the giant .COM so in practice registrars have to do a lot of the work.
Some domains have DNS service from the registrar, some from a hosting
or other provider who may or may not be one of the registration contacts,
some other places.  So you do what you can. but sometimes they'll still
not get it.

As to the advice to TLD operators to un-delegate broken servers, good
luck with that.  For ICANN contracted TLDs it'd require a change to
the RAA which is unlikely to happen, and for everyone else, the
registrant is likely to say "it works fine for me", which it probably
does for simple A and MX queries.  I'm not sure what to say instead,
but it seems unwise to instruct people to do something you know they
won't do.

Section 5: in the last sentence, I don't understand whether it means
that none of them are attack vectors, or that some are and some aren't.

Section 8.1: this list of tests is great.  I stared at it and I think
it's all correct, other than the XML formatting problem, but due to the
length and all the fiddly details the more people who look at it and
ideally who implement it, the better.

Section 9: turning off servers that partly work is likely to have
security implications, like zones disappearing from the Internet.

There are lots of minor typographic and grammar problems that I
haven't mentioned.  A thorough copy edit by someone other than the
author would be useful.  (This isn't saying anything bad about the
author, just that we can't catch our own mistakes.  BTDT, got copies
of Internet for Dummies with egregious typos that went through three
editions.)

One final thought: if the registry or someone is going to test all
those nameservers anyway, should it also check other errors like
lame delegation and broken or inconsistent DNSSEC keys at the same
time?

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Mon, 22 Feb 2016 11:14:17 +1100

> 2.1: "otherwise identical responses" -> "otherwise identical queries"

addressed
> produces puts the examples before the corresponding text rather than after.

It doesn't happen w/ the xml2rfc I have.  I expect this is a bug in
xml2rfc.  That said the .xml is available for anyone to look at
if they have a suggestion.
 
> I'd use a word other than "class" since it's not used in its DNS

Kind(s)?
 
> some other places.  So you do what you can. but sometimes they'll still

You can always contact the registrant, possibly through a registrar,
and through them get the server fixed / changed.  They are responsible
for picking a service that works.  They also are who are ultimately
affected when the remedy if last resort is applied.

For the most part the TLD operators do the correct thing anyway.

https://ednscomp.isc.org/compliance/tld-report.html

> but it seems unwise to instruct people to do something you know they

Parent zone administrators are already instructed to do just that
as the last step in attempting to remediate problems cause by broken
/ misconfigured servers.  This does happen for sites spewing spam.
It can happen for other causes.  I don't want thing to escalate to
the point where it becomes necessary to remove a zone but you have
to leave it there as a tool of last resort.

> that none of them are attack vectors, or that some are and some aren't.

What other word than "All" would you have me use in "All of these
are not attack vectors" ?

> ideally who implement it, the better.

They should be as they were cut-and-pasted from the scripts used to
generate the pages linked from https://ednscomp.isc.org.

> security implications, like zones disappearing from the Internet.

I'm not sure it is but can add something.

> lame delegation and broken or inconsistent DNSSEC keys at the same

They should already be doing that.  RFC 1034 already say to do this.
That said this document is focusing of server/firewall implementation
faults not DNS configuration faults.

   Checking of delegations by TLD operators should be nothing new as
   they have been required from the very beginnings of DNS to do this
   [RFC1034].  Checking for compliance of nameserver operations should
   just be a extension of such testing.

> R's,
> John
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 21 Feb 2016 20:30:35 -0500

> / misconfigured servers.  This does happen for sites spewing spam.

Advice to zone administrators, I suppose, but TLD operators all either 
have contracts with ICANN, or are ccTLDs with some responsibility to the 
country-like-thing.  Having looked in some detail at gTLD contracts, there 
is nothing there that would let a TLD undelegate a partially working name 
server.

> are not attack vectors" ?

"None of these are attack vectors", or "Only some of these can be attack 
vectors."

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Mon, 22 Feb 2016 13:15:08 +1100

In message <[email-masked]>, "John R Levine" write
> is nothing there that would let a TLD undelegate a partially working name 

Yet, that is community expectation as express in 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.

Zones have been excommunicated for various reasons in the past
without words in formal contracts saying that they are required to
do so.

Best current practice does result in zones being removed for various
reasons after due process.  It is the measure of last resort.