Subject: RE: The URL to my paper describing the DKIM policy options

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 25 Jul 2006 09:55:21 -0700

CC'd to namedroppers for wider discussion.

There are two wildcard problems

1) Wildcards do not match a node if there is any data at the node
	*.example.com TXT "hello" will not match if there is any record at a.example.com

2) It is not possible to define a midpoint wildcard 
	_prefix.*.example.com cannot be defined

The proposal is to use automatically generated records to address the first problem and the PTR hack to address the second.

So for example we might add a new 'superwildcard' record to the configuration language of BIND or your favorite DNS server that recognises the ** wildcard entry which matches with the naïvely expected semantic of 'match any node that does not already have an entry defined for this particular record'.

So our configuration file is:

**.example.com      PTR  _default.example.com
a.example.com       A    10.0.0.1
_dkim.example.com   TXT  "dkim record"

This is then processed by a preprocessor to produce the actual DNS zone:

**.example.com      PTR  _default.example.com
a.example.com       A    10.0.0.1
a.example.com       PTR  _default.example.com
_dkim.example.com   TXT  "dkim record"

Note that DNSSEC already creates the need to separate the configuration file from the zone file. If we were using DNSSEC we would also be inserting the various key and signature records etc.

The handling of ** can be defined to create 'cut outs' for cases where you would expect them to occur. So if we have a delegation to another DNS server we would naturally expect that the superwildcard would not apply to anything in the delegated zone.

Note that we need superwildcards whether or not we introduce a new RR and that this will require code to support the administrators. The reason this is acceptable is that 1) it is still possible to do the job by hand 2) the tool can be bolted in to practically every existing configuration without disrupting the installed servers.

Consider however what happens when we have a large number of policy records and each one has its own record and there is no PTR hack:

**.example.com      DKIM  "dkim record"
**.example.com      DKPOP "dkop record"
**.example.com      DKSSL "dkssl record"
**.example.com      DSMTP "dsmtp record"
a.example.com       A    10.0.0.1
b.example.com       A    10.0.0.1
...
z.example.com       A    10.0.0.1

After processing we will have 4*(26+1) synthetic nodes created and if they are signed each will have a signature record as well.

This is not good if the policy records are all saying the same thing 'this host does not provide this service'.

Using the PTR approach this becomes:

**.example.com      PTR  _default.example.com
a.example.com       A    10.0.0.1
b.example.com       A    10.0.0.1
...
z.example.com       A    10.0.0.1

_default.example.com      DKIM  "dkim record"
_default.example.com      DKPOP "dkop record"
_default.example.com      DKSSL "dkssl record"
_default.example.com      DSMTP "dsmtp record"

Now we only create 26+1 new synthetic records.

We can also use the PTR records to perform class based system administration:

**.example.com      PTR  _default.example.com
a.example.com       A    10.0.0.1
a.example.com       PTR  _server.example.com
b.example.com       A    10.0.0.1
b.example.com       PTR  _server.example.com
c.example.com       A    10.0.0.1
...
z.example.com       A    10.0.0.1

_default.example.com     DKIM  "dkim record"
_default.example.com     DKPOP "dkop record"
_default.example.com     DKSSL "dkssl record"
_default.example.com     DSMTP "dsmtp record"
_server.example.com      DKIM  "dkim record"
_server.example.com      DKPOP "dkop record"
_server.example.com      DKSSL "dkssl record"
_server.example.com      DSMTP "dsmtp record"

In this case we have two separate management groups, machines a and b are in the server group and we can set the parameters for both machines at the same time. Everything else is in the default group.

Note that there is still value to using the PTR hack even if you are going to define a specific policy record.

If someone can demonstrate (as opposed to give opinions as to the state of their intestines) that something ugly happens if PTR is used we could use a different record or even create a new one.

For the sake of example I have shown the scheme with policy specific RRs. The redirection to a prefix value is not essential to the demonstration except insofar as it is better that this process does not result in spurious nodes being created. I could have used a PTR to an unprefixed label:

a.example.com      DKIM  "dkim record"
b.example.com       PTR  a.example.com

As is clear from the example however there is now no 'wildcard penalty' for using a prefix record. Although eliminating the wildcard penalty was my original reason for developing this scheme it is not the only benefit. I think that we need this type of functionality regardless of whether we create new RRs or not as otherwise the number of synthesized policy nodes will quickly explode. Every Web service will require a policy specification, the platform requires it. A domain might easily have 100 or more Web services defined. 

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 11:52 AM
> To: Patrick Peterson
> Cc: Hallam-Baker, Phillip; IETF-DKIM
> Subject: Re: [ietf-dkim] The URL to my paper describing the 
> DKIM policy options
> 
> Patrick Peterson wrote:
> 
> >>----- Original Message -----
> >>From: "Hallam-Baker, Phillip" <[email-masked]>
> >>To: "IETF-DKIM" <[email-masked]>
> >>Sent: Wednesday, July 12, 2006 2:05 PM
> >>Subject: [ietf-dkim] The URL to my paper describing the DKIM policy 
> >>options
> >>
> >>
> >>I submitted the draft in both pdf and txt. Only the txt is 
> shown, the 
> >>more readable pdf is attached.
> >>
> >>http://www.ietf.org/internet-drafts/draft-hallambaker-pcon-00.txt
> >>    
> >>
> >
> >I think this is a great idea and am surprised it didn't 
> generate more 
> >traffic on the list. It's not easy to cram needed new functionality 
> >into a backward-compatible solution.
> >  
> >
> So I'm trying to understand the basic algorithm:
> 
>      To discover the policy for DKIM at alice.example.com: 
>         
>             1) policy = lookup (TXT, "_dkim.alice.example.com") 
>                  IF policy <> NULL THEN RETURN policy 
>              
>             2) pointer = lookup (PTR, "alice.example.com") 
>                  IF pointer == NULL THEN RETURN NULL 
>              
>             3) policy = lookup (TXT, "_dkim." + pointer) 
>                  return policy 
> 
> So I set up mtcc.com's bind config to:
> 
> $ORIGIN mtcc.com.
> 
> *        IN     PTR    mtcc.com.
> 
> Where mtcc.com is the top level and contains the policy 
> record. When I choose a label that doesn't have any other 
> labels (say, frogger.mtcc.com) it doesn't return anything as 
> TXT so I go to step 2, it points back to mtcc.com and 3 succeeds.
> 
> However, when I use a label *with* a record:
>     fafner        IN    A    216.102.208.11
> 
> the host -t PTR fafner.mtcc.com returns a reply with an 
> answer count of zero.
> Which is just the same thing that happens with TXT.
> 
> So I guess I must be missing something because wildcarded PTR 
> records seem to be handled the same as any other wildcard 
> which is to say, not the behavior you'd hope for.
> 
> Phill?
> 
>        Mike
> 
>