At 10:56 AM -0800 11/14/08, John L wrote:
Sorry, what about SRV made RRTYPE not significant? Sorry
to be dense, but I don't understand your point here.
A SRV record with _tcp in its name means something different from a SRV
query with _udp in its name. I suppose you could argue that's different
because _names are special, but the semantics are definitely in the name,
not just in the RR.
I don't see this as a particularly compelling parallel, partly because SRV
was upfront from the beginning that SRV's usage of names was unique:
"The SRV RR is unique in that the name one searches for is not this name;
the example near the end shows this clearly."
This proposal reuses an A record, for which semantics are well established
and which had no such indication. Further, once you have an SRV record,
the name you used to construct the query doesn't really impact the
interpretation
in the same way this proposal seems to.
I believe Andrew and Olafur quite sensibly proposed that this change
go forward with a transition to allow for increasing numbers of v6
addresses.
You can do that if you want, but since there is no realistic scenario in
which MTAs will handle v6 DNSBLs differently from v4 DNSBLs, I don't see
the point in allocating an RR that will not in practice be used.
The real damage might well occur when it leaks out of DNSBLs into the
next bright spark for web-based reputation or something similar.
I fear it is about 15 years too late to fight that battle. There are
already domain based DNSxLs, and they encode their stuff into A records.
If we are documenting practice and nothing more, then the publication
stream can move to informational and text can be added on why
a new RR, which would normally be expected here, is not being used
(essentially, inertia in the face of 15 years deployment). That may
be a valuable use of an RFC; documenting the way things really work
often is. But it shouldn't go onto the standards track, as there is a known
technical deficiency.
regards,
Ted Hardie
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf