Quite apart from the DNSSEC example that Patrik sent, underscore
labels also cause problems and confusion when aliases are involved.
The alias stuff is a corner case, of course, but it's still a basic
problem with the approach of specifying policy for a target name at a
different name than the target itself. This trade-off might be a
legitimate one (I certainly think it's preferable to the strategy SPF
adopted, of stepping all over the TXT RRTYPE at a given name), but it
won't do to dismiss the problem with a point-and-laugh argument.
Use of underscore names does impose some limitations. Occasionally
those limitations are noteworthy for real-world operations, but
experience across a range of applications so far has not created any
show-stoppers.
One of the more serious problems about using the underscore construct is
that arguments against it sometimes are based on an insistence for
pure-and-complete original DNS capabilities, rather than attending to
the real-world utility. It would be nice to have the construct impose
no additional constraints, but 'nice' isn't the same as 'necessary',
when evaluating pragmatic trade-offs.
In other words, the specific technical limitations being noted are
unfortunate but (so far) not serious.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net