Subject: RE: [ietf-dkim] 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
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Jul 2006 14:25:45 -0400

>CC'd to namedroppers for wider discussion.

I'm addressing this reply to only namedroppers.

>_dkim.example.com   TXT  "dkim record"

E.g., BIND's $GENERATE directive, on steroids.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 26 Jul 2006 09:44:21 +0200

On Tue, Jul 25, 2006 at 02:25:45PM -0400,
 Edward Lewis <[email-masked]> wrote 

> E.g., BIND's $GENERATE directive, on steroids.

I'm always puzzled by proposal to add in the DNS things that could
otherwise be implemented by any preprocessor. The only advantage is to
make the transferred zone smaller (but it forces all the secondaries
to upgrade to a version supporting the new syntax).

Unless I missed another advantage, I suggest to dismiss all these
proposals with a "Learn cpp or m4 or Perl or anything". (And I'm not
sure it was a good idea to specify the file format, anyway. IETF
should be about protocols, not about file formats.)

For the same reason, I think that DNAMEs are a bad idea.

---

From: Roy Arends <[email-masked]>
Date: Wed, 26 Jul 2006 11:36:32 +0200

> For the same reason, I think that DNAMEs are a bad idea.

There is a difference in what can and can not be preprocessed. Phill's 
(Ed's) proposal can be implemented by preprocessing and out of protocol, 
i.e. adding a record type for existing names. DNAME's can not be 
preprocessed, since qname does not match at the DNAME ownername, but 
below. 

The same goes for anything that does not match an existing name.

Okay, it can be preprocessed, but that is going to be a helluva big zone 
;-)

Roy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 26 Jul 2006 13:11:44 +0200

On Wed, Jul 26, 2006 at 11:36:32AM +0200,
 Roy Arends <[email-masked]> wrote 
 a message of 45 lines which said:

> There is a difference in what can and can not be preprocessed. 

Yes. Ordinary wildcards cannot be preprocessed.

> DNAME's can not be preprocessed, since qname does not match at the
> DNAME ownername, but below.

I did not say that DNAME could be preprocessed but that DNAME was a
bad idea because the same effect (solving the use cases in section 2
"Motivation" of RFC 2672, typically network renumbering and company
name changing) could be attained by preprocessing.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 26 Jul 2006 09:43:37 -0400

Pouring cold water on a spark you don't want is quite refreshing but 
may be giving the wrong impression.

On the one hand, it would be really cool if there was a way to expand 
the notion of record and answer synthesis in DNS.  Performing a 
mental exercise on this, eventually you realize that we could just 
throw in a full-fledged database, etc., etc.  Or perhaps LDAP and 
X.500.

The reason that isn't what is being done, why sparks of ideas to add 
things like super wildcards is that DNS offers certain advantages - 
speedy responses, a loosely coordinated management structure that 
permits wild scaling, and good-enough replication.

The cost of maintaining DNS in its original spirit, which is the key 
to retaining its advantages, is that functionality is pushed outward 
(from the "core" DNS), to things like pre-processors.  It's quite 
easy to off-load all DNS advancement to such gadgets - from the 
perspective of protocol engineers.

The net of doing this is an increase in gadgets.  There's a choice - 
in order to perform a job requiring a fixed amount of work, you can 
have lots of simple gadgets or a few complex gadgets.  We in the this 
group are gadget makers and prefer small, simple ones.  This means we 
are putting pressure on operators and applications writers to make do 
with lots of simple tools.

Perhaps that's all well and good - creating a need for a layer above 
DNS to once again make the gadgets seem as one, easier to track and 
manage.  But, on the other hand, it can be seen as just another layer 
of complexity to be offered by someone else.

The talk below is about DNAME.  But I would also lump in MX and CNAME 
as two earlier records which set bad precedents.  They were 
customizations of the DNS to appease needs at the dawn of time. 
Today we don't think of MX and CNAME as problems, but that's because 
they are like the goofy old uncle that's been around the house too 
long.  CNAME is a pain because of what it does to the algorithm in 
4.3.2 or 1034.  MX because it causes confusion of how wildcards 
operate.

(While I'm at being crotchety - if we hadn't invented the NS record, 
we wouldn't have ICANN to kick around. And the A record - oh, the 
trouble it has caused!)

Do I have a point?  Probably not, maybe it was the 45 minute drive on 
Route 28 that's prompting me to write.  (When are they going to 
finish that bridge!)  But I guess what I wanted to say is that 
although my response said to "use preprocessing" that doesn't mean to 
say that expanding answer synthesis is a bad idea.  By "pushing the 
limits" in the subject I an inferring that I have doubts that it can 
be easily done - the big problem is the zone transfer process.

I think we should not consider record synthesis a problem rooted in 
complexity nor something that is easily done by more gadgets on the 
side of the DNS operation table.  My doubts are that we are able to 
fit it into the protocol as it stands.  I'd like to see it, but we'd 
have to overhaul the zone transfer - for new followers, the AXFR 
clarify draft has been on the shelf since about summer 2002.  If we 
can't clarify it, we can't extend it.

(Oh, and I'm omitting that code to perform the synthesis is needed - 
but I figure that's the easy part - as I'm not a coder.)

Okay, maybe there was no point, but I'm no longer fuming about traffic.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 Jul 2006 14:52:40 +0000

> otherwise be implemented by any preprocessor. ...

me too.  but i do want two new kinds of wildcards, which cannot be done

> For the same reason, I think that DNAMEs are a bad idea.

DNAME cannot be accomplished by a preprocessor.

but two kinds of wildcards which would help SRV a lot and be generally
useful, are nonterminal and per-qtype.