Subject: [dnsop] WGLC on draft-ietf-dnsop-bad-dns-res-03.txt

From: Rob Austein <[email-masked]>
Date: Fri, 19 Nov 2004 16:58:05 -0500

This is a working group last call on the "Observed DNS Resolution
Misbehavior" draft, draft-ietf-dnsop-bad-dns-res-03.txt, which we
hope to submit to the IESG for consideration as a BCP document.

This last call will terminate at 17:00 UTC on 6 December 2004.

Please clearly state to the mailing list whether you support or oppose
this draft going to the IESG.

Please do not express an opinion if you have not read the draft.

As always, please discuss substantive issues on the WG mailing list.
Minor editorial comments may be sent directly to the draft authors
(please CC the WG chairs on any such comments so that we can track
this).

Thanks,

Rob & Dave
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Rob Austein <[email-masked]>
Date: Fri, 19 Nov 2004 19:35:31 -0500

<hat wg-co-chair=off just-another-bozo=on>

  Speaking only for myself: I think this draft is an excellent piece
  of work that we should publish as a BCP.

</hat>
.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 20 Nov 2004 08:37:09 +0200 (EET)

>  of work that we should publish as a BCP.

Ditto.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Andras Salamon <[email-masked]>
Date: Sat, 20 Nov 2004 08:55:53 +0200

> hope to submit to the IESG for consideration as a BCP document.

I support this draft being submitted to the IESG.

It is a solid document with sensible recommendations.

Could the authors release, perhaps informally to this mailing list, some
of their specific findings: which implementations are faulty as described?

-- Andras Salamon                   [email-masked]
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Sat, 20 Nov 2004 16:09:32 -0500

>this draft going to the IESG.

I support this draft to be published as is.

         Olafur

.

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 21 Nov 2004 16:56:44 +0000

> >hope to submit to the IESG for consideration as a BCP document.

I support publishing this draft as a BCP.

My only reservation is with the use of standards-track language in a
BCP. The recommendations are good and useful in substance, but I'm not
entirely comfortable that we're doing as much as we reasonably could
to discourage errant vendors in future. 

I don't want to see the draft held up on that account, though, so I'd
publish as-is and also open some discussion of whether the included
recommendations should be pursued as a separate standards-track
document (presumably in DNSEXT).
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Sun, 21 Nov 2004 21:47:43 +0200 (EET)

> document (presumably in DNSEXT).

I think I'll have to re-iterate my earlier point, from June 2004, now, 
because it was probably forgotten:

http://darkwing.uoregon.edu/~llynch/dnsop/msg02940.html

Have these changes been reviewed and/or adopted by DNSEXT WG?

We've produced a similar document like this one at v6ops, and the IESG 
stomped on it, because they wanted that the concerned WGs fix the 
problem, e.g., by new specifications, not that possible fixes are just 
described in an informational RFC -- check out 
draft-ietf-v6ops-v6onbydefault in the I-D tracker if interested.

That is, if a dnsop document is proposing protocol fixes, those fixes 
must actually get in the dnsext pipeline, and we must actually wait 
for those fixes to be finalized before going forward. (Or, then we 
just remove the recommended protocol fixes.)

---

From: Rob Austein <[email-masked]>
Date: Sun, 21 Nov 2004 17:26:08 -0500

It would help if folks who think they see protocol changes coming out
of this document would clearly identify the protocol changes they
think they're seeing.  Eg, the NS RRset ordering issue identified in
the message that Pekka cited is not (in my opinion) a protocol change,
since the DNS specs are already reasonably clear that RRsets are and
always have been unordered.

Many of the recommendations in this draft are what I'd classify as
implementation advice, which is something of a grey area, but since
this implementation advice follows directly from analysis of bad stuff
that's been happening to deployed servers out in the real world, I
think it's reasonable to keep the implementation advice in the same
document as the analysis that motiviates it unless there's a strong
reason to move the advice somewhere else.

If the IESG has a problem with this, they'll tell us, and Dave and I
can certainly ask our AD for an opinion, but let's not borrow trouble.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 22 Nov 2004 03:54:47 +0000

> always have been unordered.

In case it wasn't clear, I was suggesting that we investigate whether
some of the implementation advice might be more persuasive as
protocol, not that there's anything wrong with what the dnsop draft
already does. IOW, what Rob is asking for here is noble, right,
necessary....and not on any critical path for forwarding bad-dns-res
as a BCP.

I really want to see this draft go forward-- having it published at
all would give us a stick we don't presently have, so I don't want to
see the WG bog down on the question of whether it's cut from the right
tree.

There's a difference between saying "the Internet would be a better
place if implementors and/or operators did <x>" and "Implementations
that don't do <x> are not compliant with the standard." In the case of
the recommendations in bad-dns-res, it might be appropriate and useful
to "promote" some of them from recommendations to DNS protocol. This
is, however, outside of the question of whether they should be
published as implementation advice to curtail specific problems as
described in the draft.

I personally suspect that standards-track language (MUST and SHOULD)
sometimes causes confusion in BCPs, since we live in a world where
people are often a bit unclear on what's a standard anyway? -- but the
words are nearly unavoidable in a situation like this. However, the
draft itself is a little ambiguous on this point. The Abstract
describes its purpose as including "minor additions to the DNS
protocol specification and corresponding changes in iterative resolver
implementations", and uses RFC 2119 words.

I'd specifically suggest:

1. Clarify in the abstract and, if necessary, elsewhere that these
recommendations may or may not become protocol but they're still
really, really good ideas and following them means you'll be compliant
if they *are* standardized....and still a good citizen if they're not.

2. Take up a separate work item, if the WG so desires, of determining
which, if any, should be protocol. With bad-dns-res to motivate such
changes, they'll be easier to justify in DNSEXT if there's something
to be gained thereby.

.

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 22 Nov 2004 21:44:16 +0100 (CET)

> this draft going to the IESG.

I support this draft going to the IESG.

 	jakob
.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 29 Nov 2004 11:42:13 +0100

Executive Summary

 Although I think that most of it is fine, I have an issue with
 section 2.9, "Queries for domain names resembling IP addresses".
 I fear the recommendation(s) in 2.9.1 will create more problems
 then they will solve. Therefore I propose to drop this section.

Details:

Section 2.9 makes the observation that the root servers receive a
lot of queries, which are actually IP numbers and notes that it
would be desirable that these queries won't end up at the root
servers at all. Therefore it is suggested that

	(1) ...  implementors consider the option of synthesizing
	Name Error responses at the iterative resolver.  The server
	could claim authority for synthesized TLD's corresponding
	to the first octet of every possible IP address, e.g. 1.,
	2., through 255.  This behavior could be configurable in
	the (probably unlikely) event that numeric TLDs are ever
	put into use.

or that

	(2) ... root servers delegate these domains to separate
	servers which are currently already delegated the in-addr.arpa
	zones corresponding to RFC 1918 for the AS 112 "black hole"
	project.

Suggestion (1):

 I consider it a bad idea that resolvers synthesize answers for
 some class of specific names as suggested in (1), it is simply not
 in the dns specifications. Making configurable in case numerical
 become existing is not a good idea, because when they do, it will
 be difficult, if not impossible, to have the configurations of all
 caching forwarders changed timely and consistently whenever this
 needs to be done.

Suggestion (2):

 This means the root server operators change the root zone data on
 their own, bypassing the usual channels.

Also:

- The observation in 2.9 concentrates on ipv4 like addresses used
  as names, but that is just a subset of the problem that too many
  queries end up where they don't belong.  There are other ones,
  such as queries for ".localdomain" and I won't be surprised that
  ipv6 like addresses are showing up as well.

- Using technical tricks as suggested tolerates misbehaving resolvers
  or bad configuration issues and thereby removes the motivations
  of getting these things fixed. Where will this stop?

- If these solutions are going to adapted be anyway, there might
  be impact on DNSSEC, which will require further study.

So, in conclusion, I ask the Section 2.9 be dropped from the document.
Although the problem is real, the recommendations to fix it create
more problems then it tries to solve.

	jaap
.

---

From: "J-F C. (Jefsey) Morfin" <[email-masked]>
Date: Mon, 29 Nov 2004 17:20:37 +0100

Full support of this comment, from previous projects using so called 
numeric names (X.121, post codes) and from the current important usage of 
"numeric names" for their soundex meaning in non ASCII countries (China, 
Korea, etc). A generalization of numeric names in considering the current 
DNS character set as "-0Z" numbers is also a simple and culturally 
acceptable way to keep ASCII DNS used for technical purpose or common 
reference in ML.ML environment. Other projects for supporting company EIN 
or individual SSN exist through the world. Introducing such a 
discrimination seems impossible today, even for special projects/TLDs.

There is NO structural difference in DNS between a figure and a character. 
There should not be any in usage and code. Most TLDs impose no restriction 
on all numeric names.

I will note that "domain names resembling IP addresses" was the main 
problem we met 20 years ago when interfacing the DoD ARPA Internet to the 
International public packet switch network . The International names order 
was left to right (left being the root name - in Internet speak the TLD) 
and did not use dots. They added ".arpa" to internet names (see the RFC of 
the time), so we got the names we needed and made them "ARPANAMES" on the 
fly at the gateway. It worked well and we pasted our com, net, ISO 3166 
table as every where. But this created a conflict with IP addresses when 
they also shown-up (when we tested with Telenet too if I am correct). 
Because their reversed concatenation could be understood as an X.121 
address: we supported foreign network addresses as a numeric names in 50 
countries. The solution they agreed and we accepted was the trailing 
dot-root, as IP have no root. We only checked the last byte for a dot or 
not. I do not know the details on the Internet side, but this turned to be 
reliable (I assumed the international support and we got only a few 
problems), but I am sure nobody was really happy with that kind of trick. 
It made the entire interoperability between two major systems depending on 
a single y/n parameter in pasted files by unaccustomed techies (each team 
only had one machine to operate among many others not using that specific 
feature).

I will add that one of the nice feature of numeric names is flexibility 
(for example variable length addresses). You will never prevent people to 
use that flexibility. So, this option will probably meet a lof of 
exceptions. A probable nightmare.

However, experience shows that virtual zones can be proposed in filtering 
all the names to split the load among machines. In particular the "xn--" 
names could be supported by separated servers?
jfc

At 11:42 29/11/2004, Jaap Akkerhuis wrote:
>..

.