Subject: Re: wildcards vs. RR types, was Faux wildcards

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 13:04:20 -0600

In <[email-masked]> Paul Vixie <[email-masked]> writes:

>> >> There's no need for "new" wildcards.
>
> i disagree.  we need rrtype-specific wildcards, and nonterminal wildcards.

I agree with Paul here.

> right now, a nonterminal "*" is meaningless to the wildcard algorythm.  it
> will have to remain meaningless in case someone is using this encoding and
> depending on it to be meaningless or "just an asterisk label, not special".
>
> to add nonterminal wildcards or rrtype-specific wildcards, we will have to
> define a new encoding that is currently not just meaningless but invalid.

Ok, I confess I don't understand how wildcards and DNSSEC works, but
current wildcards are server side only.  So, we could just have an
option enable expanded wildcards that defaults to "off".  So, if
someone has "foo.*.bar.example.com. IN A 1.2.3.4", that would remain
as it is.  The meaning, however, could change for those that want to
change it.  The option would need to be per-zone and there would need
to be some way of communicating this option to secondar NSs.  One
really ugly solution to this would be to create a "EWLD" RR type to
denote that this zone wishes to use extended wildcards.  Like the SOA
record, the "EWLD" RR would need to be at the zone origin.

-wayne

--
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: Alex Bligh <[email-masked]>
Date: Wed, 19 Jan 2005 19:25:26 +0000

--On 19 January 2005 13:04 -0600 wayne <[email-masked]> wrote:

> change it.

Genuine question: what is the perceived advantage of "new type of wildcard"
over preprocessing?

I know one answer: if the "new wildcard" matches non-existent LABELS,
and the preprocessing cannot decompose the directive into a selection
of traditional RR's and wildcards, then preprocessing isn't going to
work and you are stuck with synthesis (and, with DNSSEC, online signing).

But is there a current known case where this is problematic?

foo.&.bar.example.com  (for "&" = new wildcard)

such as I believe is wanted by the SPF folks could be decomposed
by preprocessing into foo.<label>.bar.example.com records for all
instances of <label> within bar.example.com. (note config subtlety
when "within" crosses a zone cut). Whilst it can generate a
*.bar.example.com RR for "the rest of the zone" as per Ed's
draft, it's not going to answer to foo.baz.bar.example.com where
baz does not exist. But is this a problem? IE I thought the tree
iteration was for where subdomains do not have SPF records, not for
where subdomains do not exist.

Alex

---

From: wayne <[email-masked]>
Date: Wed, 19 Jan 2005 14:32:03 -0600

> Genuine question: what is the perceived advantage of "new type of wildcard"

Good question, and the answer I think is that there isn't much
different between this new kind of wildcard and preprocessing.  Call
it a new preprocessing directive, if you want and start the directive
with a $.

No matter what you call it, I think it would be quite useful to
standardize it's functionality.

One advantage of generating these on the fly ("wildcard") is that
there would be less space taken up in memory, on disk and during zone
transfers compared with preprocessing.

> But is there a current known case where this is problematic?

Not that I can think of.  

> where subdomains do not exist.

The zone cut stuff in the spf-classic draft is there for both when the
domain exists, and when it doesn't.  Paypal probably wants to be able
to say that "securty.paypal.com" should be rejected as being from
paypal, even if "security.paypal.com" exists.  This is especially a
problem when dealing with the domain used by the SMTP HELO/EHLO
commands since many people generate invalid domain names.  Email
receivers need to be able to distinguish between a "normal"
misconfiguration, and something that the domain owner says should
never happen.

-wayne

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 19 Jan 2005 13:33:33 -0800 (PST)

> it a new preprocessing directive, if you want and start the directive

Please dont call it that. "$" has special meaning already, for example
"$ORIGIN". As for the rest - yes its kind of like pre-processing and you 
could possibly simulate wildcard with special script before loading zone.

> standardize it's functionality.
I agree.
 
> transfers compared with preprocessing.
Agreed.
 
> > where subdomains do not exist.

That is possible because I've presented it and I'm slightly more in favor 
of having wildcard with new functionality just for when host exists but
has no RR of that type, so that would not overlap with regular '*', that
seems less prone to problems with existing dns specs and to confusion
with existing '*' to me. It also makes it easier when finding it in 
zonecut based on NODATA answer.

> domain exists, and when it doesn't. 
And there is nothing that stops somebody who wants this from entering
both new wildcard and '*' record.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 19 Jan 2005 13:48:03 -0800 (PST)

> > i disagree.  we need rrtype-specific wildcards, and nonterminal wildcards.
Same (and I'd like to emphasise again that it needs to be new wildcard 
type and not expansion of meaning of '*')
 
> Ok, I confess I don't understand how wildcards and DNSSEC works,

Entire zone is signed together and thus needs to be downloaded and
client needs to be able to interpret wildcards there.

> but current wildcards are server side only.  So, we could just have an
> as it is. 

First of all above is FQDN and not interprted/expanded as wildcard.
What I proposed for new wildcards to support prefixes is that be
interprted only at the end of host, i.e. 'sub.%'. If somebody needs
'sub.%.host' then they can do it by moving host into its own
zone and making appropriate NS deligation.

> The meaning, however, could change for those that want to

I don't see such a solution as being very good one.

--
William Leibzon
Elan Networks
[email-masked]

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Jan 2005 14:22:16 +0000

> transfers compared with preprocessing.

This clashes with DNSSEC again (since a requirement is that the signing 
key should not be needed on the server).

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff