Pekka Savola wrote:
> Effectively, this allows anyone to perform a DoS on someone else's
> resources (assuming specifying something like net.example.adv would
> result in everyone going and taking a look at "adv" policy at
> example.net -- thus flooding example.net).
the document [-04] does not explicitly say that processing of those tags would
be automated. Instead my reading is that these tags, or the documents they lead
to, are for human consumption. So while there's still a DNS DoS potential
(or even worse, thinking of the current cache poisoning hype), it's probably
less pressing. Anyway these issues and how and when the names are resolved
should be explicitly discussed.
Here are some additional remarks:
o Two forms of solicitation tags are used interchangeably in the draft:
net.example:ADV and net.example.adv. While both are translated to the same
domain name, which is the correct form?
o Is the colon mandatory?
o The script suggests that a name example.com:FOO.Bar is translated into
Bar.FOO.example.com -- is that the intent?
o The draft does not mention various syntax restrictions for the tags resulting
from the use of the DNS: label length, overall tag length, unavailability
of ".." (likewise "::", ":.", ".:"). Also, neither RFC 3865 nor this
draft mention case insensitivity.
o While the presence of the "_" should not lead to problems during NAPTR
resolution, it may confuse operators (dto absence of restrictions for "-").
o The draft mentions the "registrant" where the better term would be zone
maintainer (or owner), since a registrant only appears at the highest
"registration" level. One could argue that the 3rd level domain is
"registered" at the 2nd level, but that's confusing the term. Unfortunately
this already happened in RFC 3865.
o solicitation class tags have a very restricted character set, especially
they don't support non ASCII characters. In what form would IDNs be
handled? Would "xn--" encoding also apply to the past-colon part?
o Are the solicitaion class keywords expected to be related to the sender's
domain name, the recipient's or a third party's? Do "users" of this scheme
thus have to deal with NAPTR RRs?
o The wildcard discussion
Wildcards are appropriate for this application, allowing multiple
solicitation class keywords that share a common prefix to all point
to the same URI
seems to encourage the use of wildcards to solve the provisioning issue.
A big caveat text might be appropriate then.
-Peter
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
