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

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: ietf-bounces(_at_)ietf(_dot_)org on behalf of Ted Hardie
Sent: Thu 11/13/2008 3:08 PM
To: Tony Finch
Cc: ietf(_at_)ietf(_dot_)org
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  <dot(_at_)dotat(_dot_)at>  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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf