On Jul 18, 2006, at 9:21 AM, Peter Koch wrote:
On Tue, Jul 18, 2006 at 11:12:16AM +0200, Olaf M. Kolkman wrote:
(With qtype==srv?) Other than that, yes, those RRs can't be
forbidden, they just have no defined meaning -- as don't TXT RRs in
today's forward tree. RFC 2782 seems to suggest that the SRV RR
type is only defined for "underscored" domains. That I'd consider
broken, the RR type definition needs to be owner-agnostic. A
particular application ("using SRV RRs to locate the foo service")
however may well make use of or depend on the contextual information.
The the SRV RR in conjunction with the underscore name offers a WINS
style approach for finding services while also avoiding conflicts
with "names in the wild". Dropping use of the underscore convention
would suggest that there be a RR type per service instead. Perhaps
there should have been a range of SRV RR types assigned by IANA.
The use of underscore labels with a particular RR is just
convention and the chances of folk not sticking to the convention
(and creating interop problems) becomes more problematic when the
RR type has a more general use. In other words there are still
good reasons to specify new RRs for specific use.
$ack++;
While wanting to agree, there is also an expectation in the DKIM WG
that utilization of newer RR types will be problematic (especially
with respect to MS), and a purported rationale for use of underscores
and TXT. Which alternative would you expect to cause greater
interoperability problems?
-Doug
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
