Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]