Subject: RE: a suggestion for super-wildcards

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 28 Jul 2006 09:44:23 -0700

There are two parts to my proposal:

1) Define a 'wilder card' ** that matches a node if the result would otherwise be NO-DATA and which acts on subdomains as well

2) The pointer mechanism.

From a protocol point of view I think that we should do the first in any case since it will ease the transition from non-compliant wildcards to compliant wildcards when DNSSEC is in use. In particular many existing DNS implementations already implement the ** semantics since this is what administrators need to define MX records.

Wildcards only ever appear on the wire in two cases - DNSSEC and Zone transfers. It would certainly be nice if zone transfers were interoperable but empirically this has not been considered a major requirement. 

DNSSEC is a more complex issue, if we were starting the design of DNSSEC I would say we need both forms of wildcard. At this point I think that it is clear that we need a macro processor. The expansion of the wild cards must take place before the zone is signed.

The main reason for defining the ** 'wildercard' in a document is that there is a third important use which probably dominates the zone transfer issue, people swap configuration information through email. One of the nice things about DNS is that you can give someone a snippet of a zone file and they can probably use it regardless of what platform they use.

The pointer mechanism does not need to be specified in the DNS protocol unless we decide to revise the SRV specification. This mechanism is only used the protocols that use the DNS for policy discovery. Regardless of whether you think DNS policy distribution is a good or a bad thing, I think it is clear that the discovery mechanism for finding out where to find the policy has to be supported by the signalling infrastructure that supports the name space in use. On the Internet that is the DNS, not LDAP, not NIS, not X.500.

--
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: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 31 Jul 2006 12:13:03 +0200

On Fri, Jul 28, 2006 at 09:44:23AM -0700,
 Hallam-Baker, Phillip <[email-masked]> wrote 
 a message of 29 lines which said:

> One of the nice things about DNS is that you can give someone a
> snippet of a zone file and they can probably use it regardless of
> what platform they use.

First, this is far from true. If people use djbware or PowerDNS (or,
probably, MS-Windows pointandclickware), it does not work.

Second, I'm not sure it is nice. Most of the RFCs do not specify file
formats ("it would be nice if RFC 4271 specified a syntax for bogon
filters"). 

IMHE (In My Humble Experience), the fact that there is a reference
file format is useful, not for copy-and-paste of zone files but when
discussing DNS data with people: most DNS experts can read that
format.

---

From: bert hubert <[email-masked]>
Date: Mon, 31 Jul 2006 13:22:15 +0200

> probably, MS-Windows pointandclickware), it does not work.

Both PowerDNS and Microsoft DNS read zone files just fine, but can also read
other formats.

It must however be said that in my experience, the DNS zone format is one of
the worst formats to parse.

/** this parser handles 10 cases (sigh)
    1) qname TTL CLASS QTYPE *
    2) qname CLASS TTL QTYPE *
    3) qname CLASS QTYPE *
    4) qname TTL QTYPE *
    5) qname QTYPE *

    And then everything again with a space first character, which implies
    'same as last name'
*/

This combined with the "(" line extension, @, the various $include,
$generate, $ttl commands and so forth make it a horrible format.

We've worked very hard to make PowerDNS parse each file BIND can parse, and
BIND is in fact the only standard available. Lots of things are ambiguous
about the zone format otherwise.

And still we have irregularities, for example, what happens when you
$include a file in another directory, and somebody $includes something
again, which is the 'current working directory' to resolve relative paths?
etc.

But yes, most people here can read the simple cases just fine.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Doug Barton <[email-masked]>
Date: Mon, 31 Jul 2006 15:13:31 -0700

I'm going to combine your two responses and snip, FYI.

Hallam-Baker, Phillip wrote:
>> From: Doug Barton [mailto:[email-masked]]
> 
>> On the one hand, because I have in the past wanted something similar to
>> what you're proposing, the theoretical concept of these super wildcards
>> is appealing. However, from a protocol standpoint the idea gives me a
>> serious case of the screaming heebeejeebees.
> 
> Screaming?

Yeah, and they are getting worse.

>> So, I have a question ...
>> 
>> Hallam-Baker, Phillip wrote:
> 
>>> So the problem with policy is how to declare an email
>> signing policy
>>> for **.example.com that takes effect if there is no more specific 
>>> policy. The objective being to specify policies such as:
>>> 
>>> example.com     DKIM  "ALL mail is signed" **.example.com  DKIM  "No
>>> mail is originated"
>> Ok, your problem statement makes total sense to me, but I think you're
>> missing a third option. I'm assuming that the DKIM protocol has a way
>> to handle total absence of a policy for a domain. So, what if you added
>> a heuristic to the DKIM protocol that says, "If I do not find a policy
>> at this node, I will go down the tree until I either find a policy, or
>> hit the TLD."
> 
> It's the heuristic that gives me the heebeejeebees of the screaming
variety. Either you walk the tree and allow attackers to stick you with 60
lookups or you add in some constraints and you change the semantics of the
DNS delegation as Olafur pointed out in the meeting.

I wasn't sure I really understood what you were asking for here when I first
read this. Now that you've clarified it further, I am sure I don't like it.
There is an enormous difference between a super-wildcard that synthesizes a
response for something that doesn't exist, and one that _overrides_ the
records in a child domain. (BTW, I have a hard time following your use of
"upper" and "lower," you might want to stick with the DNS terms of art
"parent" and "child.") I could muster up support for a good implementation
of the former, but I cannot imagine a scenario where I would support the
latter. Changing "the semantics of the DNS delegation" as you describe is
too revolutionary a change in my mind. Not only because it breaks with the
entire tradition of the deployed DNS (and therefore loses on POLA grounds
alone), but also because I can see this type of record leading to nightmare
debugging problems with anything other than very simple delegations.

This is the kind of problem that needs to be solved at layer 8, where the
parent zone administrator makes the requirement of proper DKIM records a
condition of receiving the delegation, and if that policy is breached, they
pull the delegation. I am sure that other solutions are possible that do not
entail radically changing "the semantics of the DNS delegation." Although it
has its own drawbacks, e-mail headers could be used to specify where to find
the DKIM policy, for example.

Also, Mark gave you a really good answer on this point, which TMK you did
not respond to. I would really like to see an explanation of why what Mark
suggested doesn't help, or isn't suitable.

> If you walk the tree you allow upper level domains to control the email
sending policy of lower domains even if that lower domain thinks that it has
full control because it has a delegation. Debugging problems could well get
ugly, even more so if you are running split DNS.

I'm not sure what set of problems you're concerned with here, but my concern
is for the debugging nightmare that these super-wildcards you propose would
cause for DNS in general, not specifically related to the DKIM case.

>> In regards to your problem of spammers that try sending mail from
>> 1.2.3.4..99.spammer-domain.tld, if the spammers have control over that
>> domain and can add a node at that point, it will eat up resources to
>> walk that tree, no doubt. OTOH, if they are playing silly buggers with
>> a domain they don't have control over, I assume DKIM is smart enough to
>> say that if there are NO records at all for a node, that it isn't 
>> legitimate?
> 
> A lot of mail originates from addresses that are not externally visible
due to split DNS and the use of DNS wildcard MX records.

If I understand what you're saying here correctly, I would suggest that this
is an error in any case. If you're sending me mail with the expectation that
I should be able to reply to it, then I need an address to reply to that is
visible in my view of the DNS. If your From: address isn't visible to me in
DNS, the message is probably spam anyways.

> The problem with the heuristic is that it results in yet another set of
semantics to deal with and possibly end up with conflicts.

If I understand you correctly, the conflicts you are concerned about result
from your premise that child domains should not be able to set a DKIM policy
that is different from that of their parent(s). I would suggest that this is
a problem that should be resolved within DKIM (and at layer 8, as above),
without trying to hijack the DNS to solve it for you.

Hallam-Baker, Phillip wrote:
> 1) Define a 'wilder card' ** that matches a node if the result would 
> otherwise be NO-DATA and which acts on subdomains as well

As I said above, I do not support the latter in the way that you are
proposing it.

> From a protocol point of view I think that we should do the first in any 
> case since it will ease the transition from non-compliant wildcards to 
> compliant wildcards when DNSSEC is in use.

Can you please flesh this out a bit, preferably with examples?

> In particular many existing 
> DNS implementations already implement the ** semantics since this is what
>  administrators need to define MX records.

Once again, can you give examples, preferably with reference to documentation?

> Wildcards only ever appear on the wire in two cases - DNSSEC and Zone 
> transfers. It would certainly be nice if zone transfers were 
> interoperable but empirically this has not been considered a major 
> requirement.

On this I must (sadly) agree with you. I think that this ship has probably
sailed without us.

> The main reason for defining the ** 'wildercard' in a document is that 
> there is a third important use which probably dominates the zone transfer
>  issue, people swap configuration information through email. One of the 
> nice things about DNS is that you can give someone a snippet of a zone 
> file and they can probably use it regardless of what platform they use.

As others have said, this argument seems specious to me.

> Regardless of whether you think DNS policy distribution is a good or a
> bad thing, I think it is clear that the discovery mechanism for finding
> out where to find the policy has to be supported by the signalling
> infrastructure that supports the name space in use. On the Internet that
> is the DNS, not LDAP, not NIS, not X.500.

So, we have to support it whether we think it's a good idea or not? (And no,
you don't get any points for trying to make a meta-distinction between
policy discovery and policy discovery discovery.)

In short, I've tried to understand what you are proposing and why, and I do
not think that the benefits of your proposal outweigh the costs.

FWIW,

Doug

-- 

	If you're never wrong, you're not trying hard enough

---

From: David Blacka <[email-masked]>
Date: Mon, 31 Jul 2006 18:48:49 -0400

> not think that the benefits of your proposal outweigh the costs.

The way I read Phill's proposal was that he was merely defining:

 1) a new zone preprocessor rule (perhaps confusingly called **.example)
 2) a new use for PTR in the forward space.

Am I wrong?  If I'm not wrong, I am at a loss to understand what is so
controversial about either part of the proposal.

-- 
David Blacka                      <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: Doug Barton <[email-masked]>
Date: Mon, 31 Jul 2006 16:05:55 -0700

>  1) a new zone preprocessor rule (perhaps confusingly called **.example)

His thesis in the message sent minutes before yours is that I misunderstand
his proposal, so I'll respond to his message.

> controversial about either part of the proposal.

I purposely didn't comment on the PTR proposal, but I'm against overloading
existing RRs on principle. If a new thing needs a new RR, it should get one.

Doug

--