From: Douglas Otis [mailto:dotis(_at_)mail-abuse(_dot_)org]
Of course, a script or complaint DNS server generates the
added wildcard records, but this may create issues related to
revealing nodes within a domain.
There is no additional disclosure since even with NSEC3 there is always a means
of determining that there is a node entry. A query for record type ANY would
return it.
Assuming this disclosure is
not a problem, automating this prefix-wildcard RR record
would ideally always return the desired policy RR on the
first transaction "as if"
_policy.<subdomain.domain> contained the policy RRset.
Specialized handling for the prefix-wildcard RR in this case
would conflict with PTR definitions, however. As this scheme
expects new and protocol specific RR types, defining an RR to
support the prefix-wildcard seems appropriate as well.
There is no conflict.
If people want to set up schemes to anticipate requests for additional RRs the
regularity of the mechanism described is certainly an opportunity but the
argument you make here is essentially 'I never eat Pizza because the beer makes
me drowsy, well you gotta have beer to eat Pizza'.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html