Subject: RE: a suggestion for super-wildcards

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 31 Jul 2006 15:57:36 -0700 (PDT)

On Mon, 31 Jul 2006, Hallam-Baker, Phillip wrote:

>> 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.
>
> What I want to see is the former.
>
> **.example.com would match responses where there is no record of a given type at a node. If there is a record of the given type at the node it always take precedence, if there is a closer wildcard match it also takes precedence.
>
> I don't see this being different in principle to existing wildcards.

Could you explain what will happen when the zone file has to be exported
to another server. Specifically these 2 cases:
  1. AXFR (or IXFR if you like)
  2. DNSSEC retrieval of signed domain zone

-- 
William Leibzon
Elan Networks
[email-masked]

--
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: Doug Barton <[email-masked]>
Date: Mon, 31 Jul 2006 16:19:12 -0700

Hallam-Baker, Phillip wrote:
>> From: Doug Barton [mailto:[email-masked]]
> 
>> Yeah, and they are getting worse.
> 
> Fortunately you are reading the description of the alternative.

Well that's good news. :)

>> 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.
> 
> **.example.com would match responses where there is no record of a given
> type at a node. If there is a record of the given type at the node it
> always take precedence, if there is a closer wildcard match it also takes
> precedence.

That is a much more cogent explanation, thanks. I'm still not sure I support
it, but at least now I understand it better.

> I don't see this being different in principle to existing wildcards.

The main difference I see is that crosses delegation points, which still
leads to confusion and problems of the "how did something get into the
foo.example.com zone that is not in the foo.example.com zone file?" variety,
although in the more limited form that you describe, those questions may be
in the "trainable" category.

> There is no tree walking in my scheme, every lookup takes a maximum of
> three queries.

>> 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 folk who have done the empirics on this disagree.

Can you give some references? I'd love to educate myself more on this topic.

>>> 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?

Did you intend to fill something in here?

>>> 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?
> 
> If you have the following nodes:
> 
> a.example.com   A  10.1.1.1 *.example.com   MX 1 1 email.example.com
> 
> The MX record does not match a.example.com because there is an a record
> at the node. So if you want to direct all mail delivery to
> email.example.com you have to add in explicit wildcards:
> 
> a.example.com   A  10.1.1.1 *.example.com   MX 1 1 email.example.com 
> a.example.com   MX 1 1 email.example.com
> 
> If you have fifty odd hosts this is a PITA.

Thanks, I'm glad to see that on this point at least I understood you
clearly. I solved this problem a long time ago with preprocessors, so I
stopped caring. :)

> So some DNS servers actually
> specify wildcard semantics that have a looser match.

Which DNS servers?

> I think it is clear that the DNS will be the infrastructure chosen to
> support this function.

I think it's clear that the DKIM folks would like DNS to be where the
function is supported. What I would like to understand better is what the
problems are exactly, and where the solutions to those problems are best
found. I still have a gut feeling that you're looking to place some
solutions in the DNS space that are best found in the DKIM space, but I'm
willing to listen to reasons that I'm wrong.

I've now reached my personal quota of two messages per day on this topic, so
I'll let some others respond, and think about this some more. Thanks for
your efforts in helping to clarify things.

Doug

-- 

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