Opened 10 years ago

Closed 10 years ago

#195 closed defect (fixed)

Comment on "Architectural Considerations on Application Features in the DNS"

Reported by: johnl@… Owned by: jon.peterson@…
Priority: major Milestone: milestone1
Component: draft-iab-dns-applications Version: 1.0
Severity: Active WG Document Keywords:


I think I understand the points this document is making, but it
strikes me as somewhat confusing to people who are not already DNS
weenies. It would be easier to follow if it were reorganized to say
up front what points it's making, using some of what's now in section
5, then follow that with the narrative supporting the points.

In some areas, it could offer clearer advice to tell how to recognize
reasonable vs. unreasonable DNS applications. For example, it's
clearly OK to have a query structure that makes multiple queries,
since that's what MX lookups do, but how many queries is reasonable?
Is the dividing line is a set of queries that's bounded at a small
number, e.g., one for the MX and one or two for each name it returns,
as opposed to something that crawls up or down the tree or otherwise
fakes a search?

Section 2.2, "NAPTR and DDDS" seems largely to be about mapping
queries into domain names. If the name space you want to look up is,
or can naturally be transformed into, a singly rooted tree, it can
work in the DNS. The transforations used for rDNS and E164 phone
numbers are examples that work. If the name space is anything else,
e.g., phone number prefixes with trunk groups, you have a problem.
Although the semantics of using NAPTR can be very complex, the DNS
queries are not, so NAPTR works in the DNS. A lot of things
superficially similar to NAPTR wouldn't, if the names weren't
carefully constrained to work in the DNS.

Section 2.3, "Arbitrary Data in the DNS", seems slightly wrong on the
interaction of prefixes, wildcards, and arbitrary data types. The
discussion about wildcards you cite from RFC 4871 was wrong, and was
changed in RFC 6376 which obsoletes 4871. It is true that a wildcard
that matches a _domainkey prefix will generally produce a bad result,
but we've had that problem ever since SRV introduced prefixed names.
Wildcards in DKIM keys below the _domainkey work fine, e.g.,
* (I've been using that hack to put a
unique selector on every message my system signs, so I can tell who's
checking what messages, a perhaps new way to leak information via the

Section 3.2 says "some characters are not legal in labels" which is
not true. There are limits on host names, but labels are 8-bit clean
other than ASCII case folding. Perhaps it would be better to say
"applications that use label characters outside the traditional ASCII
set are likely to run into problems" due to cruddy provisioning and
support software. Also in 3.2, the lack of approximate and compound
matches in DNS lookups is a much more important reason it's not a
generic database than the label rules.

In 3.2.1, the reflection attack argument against large data is
obsolete. Botnets with a million or more hosts are common, and you
can whack a network just as thoroughly with 500 byte packets as you
can with 10K packets, by renting more bots. (The price is
surprisingly, nay, horrifyingly affordable.) Section 6 refers to
this, too. The UDP fragmentation argument is still compelling.

In 3.3.1, you might want to at least allude to the problem that leads
to hacks like It would have been nice if HTTP
cookies weren't designed so the security of many web sites depends on
knowing how far up the tree is the same organization, but since they
did, people are going to do stuff to deal with it, and some of the
stuff is more awful than others.

It's a little surprising, after all the effort we've made to encourage
people to deploy DNSSEC, that 3.4 tells people not to count on DNSSEC,
but I see the point.

Other than that, it looks good. Despite the length of these comments,
I think that the document is fundamentally sound, and that some fairly
minor changes would improve it.

John Levine, johnl@…, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail.

Change History (2)

comment:1 Changed 10 years ago by bernard_aboba@…

  • Owner changed from jon.peterson@… to jon.peterson@…

comment:2 Changed 10 years ago by jon.peterson@…

  • Resolution set to fixed
  • Status changed from new to closed

We discussed over email in October 2012, fixes went into the -06 version, especially regarding the way that wildcards may cause leakages that other applications need to detect.

Note: See TracTickets for help on using tickets.