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

["Hallam-Baker, Phillip" <[e-mail]>]

Since I have been critical of the insistence on a new RR in other contexts, I will give the reasons why I am unconvinced in this particular case and indeed would argue that a specific RR would be more effective.
 
First, let us consider the reasons why you might want to re-use an RR rather than define a new one:
 
1) Avoid running out of RRs.
 
2) Incompatibility with existing DNS infrastructure
2a) DNS publishing server
2b) DNS caching/lookup server
2c) DNS client
(Yes, I find the standard nomenclaure confusing and ambiguous)
 
 
I do not see that the first objection applies in this case. This is a very specific application, it is providing a description of a part of the Internet address space which is a primary function of the DNS.
 
Where I do see creation of new RRs to be a concern is in cases where there is a combinatorial issue, for example a scheme that would require a new RR to be created for each Internet application protocol. That gets us into the same problem as port exhaustion and is unacceptable.
 
 
The second issue is somewhat different to the analysis for DKIM or other enterprise deployments. A DNSBL is almost always deployed by a specialist on dedicated infrastructure. I do not see any reason to object to a scheme that would require such a specialist to upgrade their DNS publishing server.
 
The same is also true at the client end. Email infrastructure that uses a DNSBL should not be using the local DNS resolver to cache data. If the data is worth caching cache it in the email server. If you have enough email servers to make another arrangement worthwhile you have enough to know exactly what you are doing.
 
 
Against this there is the fact that the original Vixie DNSBL spec is terrible. Reuse of the A record makes the somewhat bizarre assumption that all the info that you might want to put into a blacklist can be encoded into a 32 bit binary field.
 
At least use a TXT record if you are going to go that route. Take the opportunity to get a little more descriptive info in there. For example, is the basis for the info objective or subjective when was the information last updated?
 
 
One problem with DNSBLs is that some folk start a service because they think it might be fun and then get bored with maintenance but the server stays up in perpetuity. Its like one of those abandonded lobster pots that just acts as a permanent death trap for sea creatures.
 
I know that there are less people starting email blacklists today, but just wait till the next set of blacklists are required. We will have the same process of boom - bust and gradual decay. Having some better info on what the age of the complaint is would be a big improvement. At least that way the DNSBLs that are designed in good faith will automatically disable themselves over time.
 
 
 

________________________________

From: [e-mail] on behalf of Ted Hardie
Sent: Thu 11/13/2008 3:08 PM
To: Tony Finch
Cc: [e-mail]
Subject: Context specific semantics was Re: uncooperative DNSBLs, wasseveral messages



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
>> interoperability.
>
>Is there any evidence for that?
>
>Tony.
>--
>f.anthony.n.finch  <[e-mail]>  http://dotat.at/
>VIKING NORTH UTSIRE SOUTH UTSIRE: SOUTHERLY OR SOUTHWESTERLY 5 TO 7,
>OCCASIONALLY GALE 8 IN NORTH UTSIRE AT FIRST, AND PERHAPS GALE 8 IN VIKING
>LATER. ROUGH OR VERY ROUGH. RAIN. MODERATE OR GOOD, OCCASIONALLY POOR.

The draft currently says:

   DNSxLs also MAY contain an A record at the apex of the DNSxL zone
   that points to a web server, so that anyone wishing to learn about
   the bad.example.net DNSBL can check http://bad.example.net <http://bad.example.net/> .


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.

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.  Using a different RR type puts you back into
the standard way of doing things.

                        regards,
                                Ted Hardie







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

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