ietf-mxcomp
[Top] [All Lists]

RE: Potential Work Item: New DNS resource records

2004-03-11 12:03:14

 The choice involves some tradeoffs.  We need to make sure that we
 consider them as a set.

 New record types have a history of taking a _very_ long time before
 they gain widescale usability.  Given the urgency of spam 
control, this
 is an important concern.

The other issue to consider is risk of fracturing the spec. This is 
a competative enviornment. If the choice is between a spec I can deploy
today and a spec that will be agreed in two, three ten years, when the
IETF feels like doing something then it is a very easy one to make.

I believe the following criteria should be met:

1) Immediate deployability

2) Content of the record MUST be text based so that parsing outside the
context of DNS infrastructure is easy.

3) A policy record should not be confused with other records

4) It should be possible to request only records of type policy

5) Cache friendly.

I know that some people want a DNS syntax for the record. In my view
that would be the death of any spec. The implementation community
are not keen on XML, but they will utterly loathe a binary format.
The DNS binary syntax is not as bad as ASN.1 but it is pretty yucky.

The other big problem with a binary syntax is the lack of flexibility.
It is pretty easy to design a text based format in an extensible way.

Sure, this is not how the DNS was designed. I really don't think that 
the original design is of interest here. 


There are four basic approaches possible:

1) SPF approach, hijack the TXT record for use by SPF
        I don't like this approach because it fails criteria (3,4).

2) TXT record with prefix label, e.g. _spf, _ep
        This fills all the requirements, with the possible exception
        of (1) since some DNS configurations reject labels with
        underscores. I think in the context of an IETF proposal we
        can get these fixed.

3) New RR with text encoding
        Critical issue here is when the RR is known and fixed. If this
        takes more than 3 months for the code point to be known the idea
        is dead. 

4) New RR with DNS binary encoding
        Sure this meets the academic purity of the DNS design. It also
        means that we have to wait five years before deployment can
        happen. It is very unlikely that the email filter companies
        would use the IETF suggestion rather than a defacto SPF or
        callerID deployment.

I would like to go the _spf route. OK we can be tactful and call it 
_lmap. But we should decide on the code point NOW so that people 
who are deploying TODAY can build in code that makes allowances.

It is not too difficult to write code that checks for _lmap, _ep
(callerID prefix) and unprefixed SPF records in that order. But 
we need to tell people what to do quickly.


The unspoken issue that people have raised is one of control. If
people can just extend the DNS at will by defining new prefixes 
bad things might happen. I don't accept that argument.


                Phill