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.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf