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:mike(_at_)mtcc(_dot_)com]
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" <pbaker(_at_)verisign(_dot_)com>
To: "IETF-DKIM" <ietf-dkim(_at_)mipassoc(_dot_)org>
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html