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

["Hardie, Ted" <[e-mail]>]

________________________________________
From: Tony Finch [[e-mail]] On Behalf Of Tony Finch [[e-mail]]
Sent: Friday, November 14, 2008 4:11 AM
To: Hardie, Ted
Cc: Andrew Sullivan; [e-mail]
Subject: Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages

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 its reputation in a specific
> context (what reputation etc. being context specific).  One of these
> things is not like the other.  Using the same record type for both
> creates a need to generate some other context that enables you to figure
> out what was really meant.

I understand the argument that DNSBLs break the DNS data model. What I
don't see is any evidence that this causes interoperability problems.

Tony.
--
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE: WEST OR SOUTHWEST 5 OR 6 INCREASING 6 TO
GALE 8, OCCASIONALLY SEVERE GALE 9 IN VIKING. ROUGH, BECOMING VERY ROUGH OR
HIGH. RAIN THEN SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR AT FIRST.


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.  Standard libraries called in this circumstance won't work, and you'll
need some mechanism to disambiguate the context so you know when to call the
special library for a-record-in-dsnbl versus the code in a-record-in-standard-dns.
At the moment, this is by application, but it may not always stay that way.

Since new RRs are substantially easier to get and use than they used to be, Andrew 
and Olafur have suggested that this work transition to using one, so that the current
re-use can be phased out.  I support that, and I would be very concerned about
the IETF standardizing something that breaks the DNS model. We've started down
that path on a couple of occasions, and it hasn't been all that pretty.   Having the
DNS remain a single namespace with as few context dependencies as we can is
pretty important, in my opinion, and the costs to moving back into the standard
way of doing things (over time, as they pointed out) does not appear to be onerous,
especially if tied to some other transition.


regards,

Ted Hardie

_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf