On Thu, 13 Nov 2008, Ted Hardie wrote:
That's an example in which an A record in this zone has the standard DNS
meaning and the expectation is that you can use it construct a URI.
The other A records have a specific meaning in which the data returned
indicates that indicates something about
The whole approach here is An A record in this zone has a meaning
different from the meaning in other zones. That creates a DNS
context for the RRTYPE based on the zone of the query, which is not
what the DNS currently uses for disambiguating the types of
requests/responses.
Didn't that plan go
From: Tony Finch [EMAIL PROTECTED] On Behalf Of Tony Finch [EMAIL PROTECTED]
Sent: Friday, November 14, 2008 4:11 AM
To: Hardie, Ted
Cc: Andrew Sullivan; ietf@ietf.org
Subject: Re: Context specific semantics was Re: uncooperative DNSBLs, was
several
On Fri, 14 Nov 2008, Hardie, Ted wrote:
Since you now have two different meanings for what an A record is, you
now need two different code trees that understand what A records are,
and those code trees are not interoperable.
What do you mean by interoperable here? What would it mean for DNSBL
At 5:06 AM -0800 11/14/08, John Levine wrote:
The whole approach here is An A record in this zone has a meaning
different from the meaning in other zones. That creates a DNS
context for the RRTYPE based on the zone of the query, which is not
what the DNS currently uses for disambiguating the
At 8:17 AM -0800 11/14/08, Tony Finch wrote:
Note that I'm not arguing against a new RR type, I'm just trying to
understand the arguments against the de facto standard.
One significant advantage which I have not seen clearly articulated is
that a new RR type could combine the functions that are
context for the RRTYPE based on the zone of the query, which is not
what the DNS currently uses for disambiguating the types of
requests/responses.
Didn't that plan go out the window in 1996 with RFC 2052?
Sorry, what about SRV made RRTYPE not significant? Sorry
to be dense, but I don't
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
On Nov 14, 2008, at 1:38 PM, Ted Hardie wrote:
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
On Fri, Nov 14, 2008 at 01:38:54PM -0800, Ted Hardie wrote:
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
Seriously, it's not obvious to me that it's *impossible* to change.
Of course it's not impossible. But the question is whether the benefit
from the change is large enough that the people who'd have to write the
software will do so.
IPv4 DNSBLs have been working just dandy with A records
At 11:23 AM -0800 11/13/08, Tony Finch wrote:
On Thu, 13 Nov 2008, Ted Hardie wrote:
Thanks for the pointer. I had missed this technical comment in the
crowd, and I think it is very important indeed. By re-using RRs with
context-specific semantics, the proposal does serious harm to
12 matches
Mail list logo
