Subject: Re: Fw: Impending publication: draft-iab-dns-assumptions-02.txt

From: Paul Vixie <[email-masked]>
Date: Wed, 02 Mar 2005 14:49:17 +0000

> The IAB is ready to ask the RFC-Editor to publish
> 
>           What's in a Name: False Assumptions about DNS Names
>                       draft-iab-dns-assumptions-02
> 
> as an Informational RFC.  This document reviews the potential
> assumptions that may be made based on domain names, as well as the
> potential implications (and pitfalls) of those assumptions.
> 
> The IAB solicits comments by March 29, 2005. Please send
> comments to the IAB ([email-masked]), or to [email-masked].

i think this document is just silly.  and highly subjective.  there is
no way to edit it to correct its problems -- it should just quietly die.
IAB should preserve its relevance and integrity by limiting its focus
to objective technical matters (such as the excellent work on wildcards
back when COM and NET each had wildcards), rather than fluff like this.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Mar 2005 12:21:16 -0500

> no way to edit it to correct its problems -- it should just quietly
> die. IAB should preserve its relevance and integrity by limiting its
> focus to objective technical matters (such as the excellent work on
> wildcards back when COM and NET each had wildcards), rather than fluff
> like this.

I think the intent of the document is timely and appropriate, though I
think it needs another rev before publication.  Mostly it could be
condensed to:

"automata should not make any assumptions about the meaning of a domain
name"

...but then nobody would read it because it would get lost in the
boilerplate.  Still, maybe they should add this in a final section, and
put it in the vertical center of the page with 4 inches of white space
above and below, just on the off chance that people will get it.

other comments:

section 1, bottom of page 3:  the comment about SRV records seems
misleading and possibly specious.  there's an important difference
between a client making an assumption about the meaning of a domain
name, and the owner of a domain name encoding some information about
that domain name.  yes, SRV records can be misleading in that they can
get out of sync with reality, but it's entirely reasonable for a client
to believe the SRV record and then fail when the SRV record turns out to
be wrong.  what's not reasonable is for a client to second-guess a SRV
record.  if the protocol says to use a SRV record, the client should
follow the protocol even if the SRV record is wrong.  if the protocol
doesn't say to use the SRV record, the client should never consult it. 
in all cases the right thing to do is to follow the specification for
that protocol.

(similarly for MX records - if a MX record is malformed or points to a
nonexistent domain, it is NOT appropriate for the sender to assume
something else and e.g. talk to the SMTP server at that A or AAAA
record.  the appropriate thing to do is to bounce the message)

easiest fix is to not mention SRV records.  the document is cleaner if
it only talks about how the DNS names (as opposed to the RRs) are used.

section 2: the model shown here is such a limited case that it may do
more harm than good to use it.  far too many analyses make the
assumption that apps are two-party (e.g. client-server).  many more
problems crop up in many-party (distributed) apps or p2p apps.  for
instance, if there are conflicts between the way that hosts in a
many-party app interpret dns names or dns records, those apps will
experience failures which would not be observed in a two-party app.

(anytime someone uses an analysis like this it should raise a red flag. 
something important is almost certainly being missed)

section 3: the analysis is incomplete due to limiting assumptions in
section 2, and is missing cases relevant to many-party apps.

section 3.3: the server can also make unreasonable assumptions about the
client's domain name, or about the domain name associated with the
client's source IP address.

section 4: other possible consequences: degraded security (weak
encryption algorithm assumed by client or server due to domain name)
possibly leading to compromised data and further security breaches (e.g.
leaked passwords), degraded performance (inappropriate assumptions about
available bandwidth or QoS made by looking at domain name).

section 5: there is often a need for hosts to keep their domains when
migrating from one network (or network interface) to another.  this has
two implications: one is that it's unreasonable to expect a host to have
a domain name which reflects the kind of network to which it is
attached; another is that it's unreasonable to trust that a domain name
that appears to claim a particular capability.

section 5.3 is fine regarding sub-delegation, but the point about the
lack of centralized control is broader than just sub-delegation.  in
particular the people who control domain names and the people who
control hosts are usually different, which makes it difficult to keep
hosts and domains in sync.  (it's hard enough just to make
name-to-address lookups work).  the more demand we create for hosts and
DNS to be in sync, the harder it is to get apps to interoperate.

section 6.  make the point clearer - the behavior of the protocol engine
should not change based on the dns name of a host.  follow the protocol
spec.  

(in addition, protocol specs should not expect hosts to be named in a
particular way.  however, protocol specs may require additional DNS
records to be created in order for the protocol to operate properly, and
such specifications may define meanings of those DNS names - provided
those DNS records are only intended to be used for that protocol and are
ancillary to the DNS names used to name hosts)

the third point is misleading (as applied to SRV) and needs to be
reworded.  again, follow the protocol spec.

Keith

---

From: Greg Skinner <[email-masked]>
Date: Wed, 2 Mar 2005 23:04:10 +0000

On Wed, Mar 02, 2005 at 02:49:17PM +0000, Paul Vixie wrote:
> > as an Informational RFC.  [...]

It has been my unfortunate experience that such documents are
necessary.  When such a document is published by a reputable source,
it saves others the trouble of having to explain repeatedly why
certain things do not work the way they might seem to, and why
assumptions must be questioned before they are acted upon.  For
example, I don't know how many times I gave essentially the same
lecture to people who wanted so very much to believe that domains
registered in .country were actually IN that country.

--gregbo

---

From: Keith Moore <[email-masked]>
Date: Wed, 2 Mar 2005 18:55:18 -0500

>  For

ah, a very good example.  it's like saying that a car with a license
plate from <state or province X> is IN that state or province.

---

From: Florian Weimer <[email-masked]>
Date: Sat, 05 Mar 2005 13:39:27 +0100

> "automata should not make any assumptions about the meaning of a domain

I think this summary is misleading, given that the document is silent
on a very important issue: standards which attach special semantics to
parts of the DNS tree.  By "special semantics" I mean special stub
resolver or resolver which is triggered by the appearance of some
magic labels or domain names, indepedent of actual zone data.  (An
extreme example: "Resolvers MUST return the address 192.0.2.1 for IN A
queries of the name www.example.com.")

This is extremely annoying for those who use Internet technology on
private networks.  Publishing such a document and not addressing this
class of mistakes could mean that the IAB even endorses such poor
standards.

---

From: Keith Moore <[email-masked]>
Date: Sat, 5 Mar 2005 21:28:39 -0500

> class of mistakes could mean that the IAB even endorses such poor

I see this document as addressing applications (or more generally, 
automata) that assign special meaning to DNS names where those meanings 
are not specified by the standards.  It's intended for implementors.

To the extent that standards should not assign special meanings to DNS 
names (or subtrees) I suspect that belongs in a different document.

Keith

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 06 Mar 2005 04:24:54 -0600

--On 5. mars 2005 13:39 +0100 Florian Weimer <[email-masked]> wrote:

> By "special semantics" I mean special stub

query: are you talking about something in a real standards document, 
something encountered in products, or something you imagine might happen?

References appreciated!

---

From: Florian Weimer <[email-masked]>
Date: Sun, 06 Mar 2005 11:42:52 +0100

> query: are you talking about something in a real standards document, 

It's draft-cheshire-dnsext-multicastdns (which has expired from the
IETF archives apparently).

> something encountered in products,

Apple and Novell are currently shipping implementations, causing major
trouble for those trying to use those products on private networks
with their own name/address allocation.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 06 Mar 2005 05:08:22 -0600

??
I checked my private copies of draft-cheshire-dnsext-multicastdns-00 to 
-04, and could not find either the number "192" nor the string "return" in 
such a context.

Wrong draft name?
(mandatory reminder: the IETF does not control the content of 
internet-drafts..... ANY bad idea can be published as an I-D, and many are)

                  Harald

---

From: Florian Weimer <[email-masked]>
Date: Sun, 06 Mar 2005 12:51:13 +0100

> -04, and could not find either the number "192" nor the string "return" in 

This was a joke.  8-)

In section 3, the draft hijacks "local.".  Not "_local." or
"local.arpa.", but "local.".

---

From: Paul Vixie <[email-masked]>
Date: Sun, 06 Mar 2005 16:01:00 +0000

> "local.arpa.", but "local.".

"hijacks" is the wrong word.  stuart asked long and hard for a forward-name
that was nonuniversal in the way that rfc1918 addresses are, and finally he
did what a lot of people do when faced with entrenched ietf religion -- he
shipped his product.  so where you say "hijacked" i say "liberated".

---

From: Carl Malamud <[email-masked]>
Date: Sun, 6 Mar 2005 09:46:33 -0800 (PST)

> shipped his product.  so where you say "hijacked" i say "liberated".

I wouldn't even use "liberated" ... I'd simply say "implemented."  .local is
a good example of something that went very wrong in the IETF.  The debate 
seemed to hinge on religious principles like universality and ignored pretty
basic things like "do you have code that works?" and "would it really hurt
other things if we did this?"

This is all theoretical anyway: there is a huge installed base of people who 
use .local and the development of rendezvous-aware applications like SubEthaEdit 
are some of the more exciting apps I've run across lately.   The fact that
the mechanisms used aren't documented in the RFC series is our loss ... 

Carl