Subject: Re: more wild cards

From: Robert Elz <[email-masked]>
Date: Thu, 02 Sep 2004 21:29:10 +0700

Date:        Wed, 1 Sep 2004 21:48:42 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020401bd5c29d82510@[192.168.1.100]>

  | I've been looking at the text as it stands and the minutes of the 
  | meeting in Minneapolis.  Besides the name question -
  | 
  | 1) * SOA.  The text goes to great lengths to say that this is doable 
  | in one sense, but in another sense it's stupid.  I.e., Step 2 of the 
  | algorithm in RFC 1034 (sect 4.3.2) says "pick the zone".  If you can 
  | generate zones on the fly, you do it here.
  | 
  | The problem is, you really can't.
  | 
  | Let's say you have example.com and *.example.com on the server.  I 
  | ask for www.cnn.example.com.  In step 2, you can't just generate 
  | cnn.example.com - because you don't know if there's an NS RR set for 
  | cnn.exmample.com in example.com.  I.e., you'd have to do step 2, then 
  | step 3.  If in step 3 you'd decide to send a referral, you would then 
  | have to go back to step 2 and generate.
  | 
  | Now, I realize that the algorithm is a suggestion, that the 
  | sequential nature of step 2 and step 3 isn't strict - but I don't 
  | think the intent was to do step 2 - 3 - 2 (again) - 3 (again).

I follow your reasoning, but I don't think I agree with this result.

Once again you're confusing the zone name tree, with the lookup algorithm.

There is nothing at all wrong with '*' as a domain name, and queries for
names with '*' as one of the labels work (or should work) just fine.
Given this, there's also no reason why '*' cannot be delegated to a
different (or the same) server(s), in which case it needs an SOA record,
just like any other delegated domain.

Then there's the separate question, that of the lookup algorithm, and
whether or not this particular '*' ever plays any role in lookups as a
wildcard.

Here we need to investigate what happens when we do a lookup, if we
have '*' as a delegated sub-domain (which it must be to have an SOA
record).

This one is pretty simple, 4.3.3,. which explains wildcards, says
quite clearly

    Wildcard RRs do not apply:
	- When the query is in another zone.

That is, if we're searching example.com for x.example.com, and there is
no x.example.com we cannot go through a delegation point to find a wildcard
there, so the delegated *.example.com domain is simply a (perfectly valid)
domain, and has nothing whatever to do with wildcards.

If there's a SOA for *.example.com, then '*' must be delegated, hence it
cannot possibly be relevant to the lookup algorithm as a wildcard.

  | I'm suggesting that we declare a * SOA to be an load/update error.

No, you shouldn't do that.   There's nothing invalid or illegal about it.

This stuff all gets confused whenever anyone starts talking about dynamic
zone creation.    Certainly a server could implement a method of
dynamically creating zones on the fly (when a query for one is made, or
whenever else it wanted to), but there is absolutely nothing in 1034/1035
(or anywhere else) that provides any support for such a mechanism.
Certainly wildcards cannot make it work.

  | 2) * NS.  The text talks around this too, with the discussion being 
  | rather vague.  But at the end of the meeting I recall someone say:
  | 
  |    "You have to be authoritative for the data to synthesize records, and if you
  |     see * NS, you are not in the authoritative zone."
  | 
  | I forget who said it, it isn't in the minutes, but I think that's a 
  | sharp observation.  (I didn't see it, and I have been staring at wild 
  | cards for some time now.)

All this is true.   You can't go through delegation points with wildcards.
But a '* NS' record is still perfectly valid, that's the only way that we
can delegate the '*' domain, which is a perfectly valid name.

Once again, separate out the DNS tree, from everything else, and examine
the algorithms as specified in 1034 carefully, you'll see that there's
absolutely nothing preventing a query containing '*' as a name, and no
reason at all that name can't literally match a '*' in a zone.  For this
purpose the '*' is identical to any other label.

So

  | I'm suggesting that * NS be a load/update error.

once again, no, you cannot do that.

But just as in the case of the SOA record, if you examine the algorithm as
it is specified in 1034, you'll see that unless we're doing a NS lookup,
a '* NS' name can never be found.   There's absolutely nothing in the
algorithm that supports treating a '*' there as a wildcard (well, you
could treat it as a wildcard when doing an A (etc) lookup, but the NS record,
which is all that can exist - anything else goes in the auth data, isn't
an A record, so no data would ever be found - the NS records for '*' can
never appear as a delegation point for any query name other than '*', you
don't even have to read the algorithm all that clearly to see that.
There is no wildcard lookup part in the referral algorithm.

If we are doing an NS lookup, for x,example.com and an '* NS' record exists,
then that record matches as a wildcard, and the NS records are (should be)
returned.   That's no different than a lookup for an A record when '* A'
exists (and the actual query name does not).

Note that this doesn't have any effect upon normal name lookups, which
don't (or shouldn't) be doing queries with qtype=NS - those queries are
reserved for diagnostics.  NS records are an internal DNS artifact, and
have no business being used by anyone else.

Were there to be a resolver which (incorrectly) iteratively descended the
DNS tree by asking for NS records all the way down the name, one
label at a time (wouldn't work in many cases, but ...) then what that
broken resolver would discover would just be a lame delegation.   It would
seem that x.example.com had been delegated to the servers listed in the
'* NS' record, but there would in fact almost certainly be no such zone
at those servers.   (I suppose the delegated servers might happen to have it
- but most likely only for delegations that used to exist in the past but
haven't been cleaned up yet).   No normal lookup would ever locate it.

There is no need to make anything here illegal, or cause zone load failures.
All that is necessary is to explain how the various possible records apply
to the lookup algorithm, which is the only context in which the word
"wildcard" makes any sense in the DNS algorithms.

  | 3) * CNAME.  From memory, we wanted to alter the algorithm to make 
  | this "chaseable" in the answer generation.  I'm going to recover the 
  | text on this and put it in.

As I recall the latest draft (and in that I include both the latest posted
draft, and the half complete next version I returned to you), the text that
changed the spec for this purpose was still there.    This one is clearly a
change to the algorithm, but one that is in accordance with the principle
of least surprise, so it is not an unreasonable change.

  | There's a blurb about fixing DNAME, I'll do that.

I thought that the "fixing DNAME" was going to be punted into a
revision of the DNAME specification, if/when one ever appears.
That, or the "DNAME is just a CNAME generator" text which is already
there was supposed to be going to be enough for DNAME, wasn't it?

kre

--
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: Thu, 2 Sep 2004 11:08:25 -0400

>Once again you're confusing the zone name tree, with the lookup algorithm.

No - I'm bouncing one idea off the other.

>No, you shouldn't do that.   There's nothing invalid or illegal about it.

We restrict names that have CNAME to be exclusively that ('cept for 
DNSSEC records) and then just one CNAME RR.   We restrict some name 
to have just 1 SOA RR.

There's nothing in the current specifications that prevent "* NS" 
now.  The WG seems to be moving towards formalizing the prevention.

As the former author of this document (pre-WG status), I refrained 
from changing anything other than the definition of "existence."  As 
editor, I'm reflecting what the WG wants - putting forth 
"suggestions" as to what I think the group is saying.  I'm taking 
Robert's "you" to mean the WG, not myself.

Looking at the discussion - I see a swell of support for formally 
banning the holding of NS and SOA at the * label.  As much as I can 
rationalize, leaving them legal does no harm in the sense that the 
protocol isn't harmed.  But, by leaving them legal we open up the 
documents to widely speculative interpretations (such as what 
happened in MARID regarding internal wild cards) and we create gray 
areas and corner cases.  But, on the third hand, by banning things - 
we create more rules that need to be enforced in software by "fully 
compliant" implementations.

Finally - every restriction placed lowers the degrees of freedom we have.

We need to balance between an amorphous free-flowing protocol and a 
tightly-defined protocol.  It's easier to extend an amorphous entity, 
but it's easier to know you've extend correctly a tightly-defined 
entity.

>Certainly wildcards cannot make it work.

Exactly what I've discovered in my research.  And, because of your 
last line, I think the WG wants to see the ban on * SOA and *NS in 
place.  To make it clear to newcomers to "don't go there."

>purpose the '*' is identical to any other label.

Nothing preventing, yes, but no benefit either.

>once again, no, you cannot do that.

Look at what we did for the DS RR set.   We changed the data lookup 
algorithm to make the answer come from the parent.

Here, we can say "the answer to a * NS query is noerror/nodata."  We 
can most easily enforce this by refusing to allow "*NS" into the 
server.  That's better than putting in other road blocks.

Let's say we discover that there's a use for "* NS".  New server 
implementations can come out then, allowing it - without having to 
wait for resolvers to catch up.  That's why barring something at load 
makes sense (to me) in this case.

I really think that when it comes to securing critical infrastructure 
like DNS, we want to clamp down on it's looseness with out making it 
brittle.  That's one rationale for the clarifications.  (The original 
motivation was to stop the need for NXT "optimization" based on 
incomplete knowledge of the DNS.  We almost did unnecessary surgery 
to solve a problem that didn't really exist.)

I do share the concern that laying down "rules" is dangerous for 
future growth.  And I am well aware that refraining from barring 
these records is would only prevent stupid behavior - like preventing 
folks from swimming with dangerous tides in the ocean.  But, the case 
is being made that we want the DNS to be much more clear, 
understandable to folks that coming to the table later in the 
development of the Internet.

>"wildcard" makes any sense in the DNS algorithms.

When I talked to MARID in May, at their interim meeting, they did not 
want an engineering discussion of DNS, they wanted "can/can't".  They 
did not wish to engage in a discussion of the internals of DNS and 
name space search theory.  After all, they have other fish to fry, 
very understandable.  In either case, I found it fruitless to try to 
explain why internal wild cards did not do what they thought they did 
- some insisted that the name is legal, therefore useful.

>there was supposed to be going to be enough for DNAME, wasn't it?

I hadn't gotten that far as yet...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

---

From: Robert Elz <[email-masked]>
Date: Fri, 03 Sep 2004 03:17:59 +0700

Date:        Thu, 2 Sep 2004 11:08:25 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020407bd5ce15f1169@[192.168.1.100]>

  | We restrict names that have CNAME to be exclusively that ('cept for 
  | DNSSEC records) and then just one CNAME RR.   We restrict some name 
  | to have just 1 SOA RR.

Sorry, how is this in any way relevant.   There are lots of various
restrictions in the DNS as it was originally defined, that's fine.
There never were any restrictions on the values of the octets in any
name labels however - none at all for any uses at all - and there's
no reason at all to start adding any.

  | There's nothing in the current specifications that prevent "* NS" 
  | now.

No, of course there isn't, and nor is there any reason for there to be.

  | The WG seems to be moving towards formalizing the prevention.

No, the WG is (seems to be) confused.   What the WG wants to prevent
is a '* NS' meaning "all domain names, other than those explicitly in
the zone, are delegated to ..."

But there's no need to do that, that usage of '* NS' is already absent.

That is, while there's no text in 1034 that explicitly says this doesn't
work in quite those explicit terms, there is absolutely nothing in the
lookup algorithm which could conceivably allow it to work.

The only way a '* NS' RR will ever be used is when someone is either
	a) doing an explicit lookup for a qname that includes a '*'
	   label at the appropriate point to match (in which case there
	   is no wildcard at all, just yet another 1 octet label, the '*'
	   is no different at all to an 'x' or a ':' (or for that matter,
	   even a '.').
	b) doing a query of type NS for a name that isn't in the zone.
	   Then the '*' will match as a wildcard.   This is harmless.

  | Looking at the discussion - I see a swell of support for formally 
  | banning the holding of NS and SOA at the * label.

I don't.   What I saw was a swell of support for not making dynamic
zone creation work by the addition of some wildcard magic.    That's
something different - to do it would actually require changes to the
lookup algorithms (something like is being proposed for CNAME, but of
a more radical nature).

I know that there are people who believe that a '* NS' record somehow
might be a wildcard delegation - but they're simply mistaken.  There is
no such thing in the DNS as it exists, and we don't need to change anything
to prevent that interpretation.

Making '* NS' illegal would simply be making one special case name that
can own any other record type, but cannot be delegated, unlike every
other name that ever might exist.

  | As much as I can 
  | rationalize, leaving them legal does no harm in the sense that the 
  | protocol isn't harmed.

But making them illegal makes a silly special case, for which
there is no justification.

  | But, by leaving them legal we open up the 
  | documents to widely speculative interpretations (such as what 
  | happened in MARID regarding internal wild cards)

Yes, we need to make it clear how the things work.   That's why we need
this clarifications doc.   We don't need to change anything to explain it.

  | and we create gray areas and corner cases.

No, there are no grey areas, and no corner cases here, everything is simple.

It is just confusing as people keep treating the '*' in a DNS zone
(or domain name) as if it were a '*' (or perhaps .*) in a regular
expression (or perhaps closer, a '*' in a glob pattern).   We just
need to make it clear that it is nothing like any of that.   There
is no pattern matching going on here at all.

  | Exactly what I've discovered in my research.  And, because of your 
  | last line, I think the WG wants to see the ban on * SOA and *NS in 
  | place.  To make it clear to newcomers to "don't go there."

But that's the wrong method.   This is just as crazy as the earlier
attempts to restrict domain names to the old hosts.txt syntax.   We
don't have to do anything like that.

We just need to explain how it works - clearly - and with examples.

  | Look at what we did for the DS RR set.   We changed the data lookup 
  | algorithm to make the answer come from the parent.

Yes, that's OK, that kind of thing is possible - changes can be made
when there's a very good reason, and when you can be confident that
nothing is going to break because of the change - which might not be
as difficult when you're doing something completely new.

  | Here, we can say "the answer to a * NS query is noerror/nodata."  We 
  | can most easily enforce this by refusing to allow "*NS" into the 
  | server.  That's better than putting in other road blocks.

But we don't need to do a thing.   That's what I am trying to make clear.
The spec as it is already provides all the right answers in this area.

The only problem is that almost no-one reads the spec, rather they just
jump to conclusions.   That isn't a good reason for making changes.

  | Let's say we discover that there's a use for "* NS".

There already is.   It is used to delegate the '*' sub-domain.
What else could it possibly mean?

  | I really think that when it comes to securing critical infrastructure 
  | like DNS, we want to clamp down on it's looseness with out making it 
  | brittle.

There is nothing loose here, it is already precisely defined.   As we
agreed earlier, the only problem is how people misinterpret it, not
how things are specified.   When that's the problem, the answer is
to correct the interpretation, not to change the spec.

  | I do share the concern that laying down "rules" is dangerous for 
  | future growth.

Here I think you're (and here I really mean the singular "you" - ye??) still
imagining that there can somehow be some way of wildcard auto zone
generation/delegation, not now perhaps, but sometime in the future.

There cannot be - or not without a major redesign of the DNS lookup
algorithms (if that were ever to be attempted, it might possibly not
even be '*' that's used as the magic token for this purpose).

  | But, the case is being made that we want the DNS to be much more clear, 
  | understandable to folks that coming to the table later in the 
  | development of the Internet.

Yes, absolutely, and this part I agree with.   But the way to make things
clear isn't to introduce more special case rules.   It is to simply
explain things better, so they can be understood properly.

  | When I talked to MARID in May, at their interim meeting, they did not 
  | want an engineering discussion of DNS, they wanted "can/can't".

Sure, and the answer is "can't".   If they don't want the explanation,
that's OK, provided they're prepared to accept the answer.   If they're
not prepared to simply accept a yes/no answer because it isn't the
answer they hoped for, then they have to start to understand the
mechanism.   If they refuse that, they're idiots, and we just ignore
them, what they're doing won't work, can't work, and why should we care?

It is kind of like if I ask my mechanic "can my car do 200 kph in
reverse?"   (S)he says "no".   If I'm prepared to simply accept
that answer, fine.   On the other hand, if I start to argue that
the car does 200 kph in the forward direction, so the engine can
clearly manage that speed, so it must also be able to do 200 kph
in reverse, and I refuse to have anything about gear ratios or
whatever explained to me, then what should be done?   Limit the
max forward speed to what can be obtained in reverse by fiat?
Because that's exactly what is being proposed here for the DNS.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 03 Sep 2004 21:56:23 -0400

I think one major bit of "looseness" that needs to be addressed here is 
that RFC 1034's Section 4.3.3 restricts the term "wildcard" to names 
_beginning_ with an asterisk label, whereas the lookup algorithm of 
Section 4.3.2 talks about "matching down, label by label", when to look 
for an asterisk label, and what to do if one is found, without any 
limitations on whether the asterisk label is the first one in an owner 
name or not. So the whole class of owner names containing _non-terminal_ 
asterisk labels is in a kind of twilight zone, able, presumably, to 
affect the lookup algorithm *functionally* in a wildcard-like way, but 
yet not "wildcards" under the *structural* definition of Section 4.3.3. 
In particular, this leaves completely open whether Section 4.3.3's 
prohibition (assuming one reads its "should not contain" in more modern 
terms as "MUST NOT contain") of "wildcards" with multiple asterisk 
labels in their name means that asterisk labels contained in *all* 
multiple-asterisk-label-containing owner names, including names where 
the first label is something other than a lone asterisk, are thereby 
excluded from the "special" behavior that asterisk labels have within 
the lookup algorithm.

If the intent was for only "wildcards" to have the special effect on the 
lookup algorithm, it would have been helpful for the algorithm 
description to have at least used the word. Were these sections written 
at different times, or cribbed from different sources? They seem rather 
disconnected from each other, despite their textual adjacency in the RFC...

- Kevin

---

From: Robert Elz <[email-masked]>
Date: Mon, 06 Sep 2004 03:22:45 +0700

Date:        Fri, 03 Sep 2004 21:56:23 -0400
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think one major bit of "looseness" that needs to be addressed here is 
  | that RFC 1034's Section 4.3.3 restricts the term "wildcard" to names 
  | _beginning_ with an asterisk label, whereas the lookup algorithm of 
  | Section 4.3.2 talks about "matching down, label by label", when to look 
  | for an asterisk label, and what to do if one is found, without any 
  | limitations on whether the asterisk label is the first one in an owner 
  | name or not.

Actually, this isn't as different as it appears to be.   Remember that if the
name a.b.c.d exists, then so do the names b.c.d.e c.d.e d.e and e.

If any of a b c d or e is '*' then there is a name that begins with '*'.

However, 4.3.3 talks of RR's owned by '*' - which is what is important
for wildcards, and why names like a.*[.anything] in a zone are useless
(ignoring the case where someone is doing a lookup for a qname containing
a '*' label where those a.* names work just like any other name).

If a.* is present in the zone then the '*' label (by virtue of this RR
anyway) has no RR's attached to it - it is what we have come to call an
empty non-terminal.   The lookup algorithm finds the '*', matches its RR's
(of which there are none) against the QTYPE, must fail to find anything,
terminates the search, and returns an empty answer.   For all practical
purposes, that's exactly the same as returning a "no such name" error,
whatever we wanted to do that caused the name lookup to be done is going
to fail, as the data we wanted isn't there.

If there's also a '* XX' RR (for any type XX) that one of course will
exist, and do its wildcard thing, totally independently of the a.* record
(the latter remaining useless).

Note here it doesn't matter in the slightest what 'a' is, which is one good
reason that names with multiple '*'s shouldn't exist - any name with anything
to the left of the '*' is, for practical purposes, useless.

But to re-iterate, all this assumed no queries involving '*' labels in
the QNAME - as soon as we allow for those (and 1034 clearly does) then
we have to also allow for a query of foo.*.example.com (which could be
implemented using a foo.* label in the example.com zone) - and we also
need to allow for "foo" to match using a wildcard (which might be *.*
in the example.com zone).   What's more, we also should allow the '*'
sub-domain to be delegated, leading to '* NS' records in example.com
and '*.example.com. SOA' in the delegated zone file.

kre

ps: I know I said I was going to remain silent - but it has been a couple
of days now, and while we've had those couple of comments that I have now
just replied to, we still haven't had any opinions on what (if anything)
anyone really wants to change about '*' labels and where they're permitted.
My opinion remains that no changes are needed - just *much* better 
explanations (or at least, ones that don't require painstaking analysis of
the details of the algorithm - what's there now is actually reasonably precise,
but it takes very careful reading to extract it).

Namedroppers isn't usually known for people being reticent about expressing 
opinions, what has happened to everyone?  (Yes, I know it is a holiday 
weekend in the US, but the whole net isn't there...)

---

From: Ben Laurie <[email-masked]>
Date: Mon, 06 Sep 2004 14:42:04 +0100

> but it takes very careful reading to extract it).

I'm not sure I understand it clearly enough to be sure whether it needs 
changes - perhaps that would be better done once it has been explained?

What I want to know is: what does DNSSEC have to demonstrate to be sure 
it has proved there's no wildcard match? Given the apparent lack of 
clarity, can we be sure we know it does that currently?

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Sep 2004 14:11:54 -0400

At 14:42 +0100 9/6/04, Ben Laurie wrote:
>What I want to know is: what does DNSSEC have to demonstrate to be sure it has
>proved there's no wildcard match? Given the apparent lack of 
>clarity, can we be

To be clear, this question is getting ahead of the draft, OTOH it is 
the question that spurred the writing of the draft.

If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to 
provide a means for the recipient to validate the received message.

I need to tie the query to the lack of data.  If I were able to sign 
a tailored message - including the original query plus the empty data 
return (or name error) - then all that is needed is to do that.  The 
recipient would see the signed denial, get the key to validate it, 
and we are more or less done.

Signing a tailored response requires on-line signing.  (I assume we 
all have a good idea of the issues that entails.)

The NSEC approach uses precomputed statements (I assume we all know 
that).  Combining the NSEC statements with 4.3.2, we need to supply 
one NSEC statement per "failure" to match in 4.3.2.  In the case of a 
name error, one error is the failure to find an exact match, a second 
error is the failure to find the '*'.

That's what's needed...you'll note that there's the first level 
requirement - being able to answer with a negative signed answer - 
and then the second level requirement which is dependent on the 
design branch.  (I.e., an NSEC needed for the name and one for the 
wild card - if we do NSEC.)

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 08 Sep 2004 00:28:49 -0400

>to fail, as the data we wanted isn't there.
I was considering the difference between an NXDOMAIN and a NODATA 
response to be a significant one. Admittedly, there isn't much 
difference from the perspective of a garden-variety app calling 
gethostbyname(), or whatever, but I was under the (possibly mistaken) 
impression that this difference mattered from a DNSSEC perspective.

At the very least, isn't part of the justification for having a concept 
of "empty non-terminal"s at all (a concept that I think belongs to an 
old-fashioned "tree" paradigm rather than the more modern 
index-into-a-database paradigm, and therefore rather difficult to convey 
to novices who often aren't so steeped in hierarchical design models) 
the alleged ability of a caching resolver to "prune" the namespace, so 
that queries for names underneath a "branch" that is known to not exist 
at all (i.e. an empty non-terminal) can be automatically answered in the 
negative without having to incur a subsidiary query to the authoritative 
servers for the zone? If we're going to consider NXDOMAIN and NODATA to 
be functionally equivalent, then I say let's go all the way and just 
abolish the notion of an "empty non-terminal" altogether. K.I.S.S. If, 
on the other hand, NXDOMAIN and NODATA are not, "[f]or all practical 
purposes [...] exactly the same", then the spec should either a) refine 
the lookup algorithm to *only* give special meaning to asterisk labels 
that are part of "wildcard"s, or b) broaden the definition of "wildcard" 
to include any name with an asterisk label in it. Hopefully the new 
draft can reconcile the tension that exists between _de_jure_ 
"wildcards" and _de_facto_ "names containing asterisk labels that might 
cause special behavior within the lookup algorithm".

In addition to the difference between an NXDOMAIN and a NODATA response, 
there is still the legalistic question of whether Section 4.3.3's 
prohibition on multiple asterisk labels in a "wildcard" owner name 
functionally "turns off" the special behavior that would otherwise occur 
with asterisk labels, in the case where none of the 
multiple-asterisk-labels happens to be the first label of the name, and 
therefore the name itself does not technically qualify as a "wildcard" 
under 4.3.3's definition...

- Kevin

---

From: Ben Laurie <[email-masked]>
Date: Wed, 08 Sep 2004 14:02:37 +0100

Edward Lewis wrote:

>> proved there's no wildcard match? Given the apparent lack of clarity, 
>> can we be
>> sure we know it does that currently?
> 
> 
> To be clear, this question is getting ahead of the draft, OTOH it is the 
> question that spurred the writing of the draft.
> 
> I need to tie the query to the lack of data.  If I were able to sign a 
> tailored message - including the original query plus the empty data 
> recipient would see the signed denial, get the key to validate it, and 
> we are more or less done.
> 
> Signing a tailored response requires on-line signing.  (I assume we all 
> have a good idea of the issues that entails.)
> 
> that).  Combining the NSEC statements with 4.3.2, we need to supply one 
> NSEC statement per "failure" to match in 4.3.2.  In the case of a name 
> error, one error is the failure to find an exact match, a second error 
> is the failure to find the '*'.

That is if there is a "the" '*'. If there are multiple possibilities 
(e.g. a '*' in the middle somewhere) then you need to provide further 
proofs.

> requirement - being able to answer with a negative signed answer - and 
> then the second level requirement which is dependent on the design 
> branch.  (I.e., an NSEC needed for the name and one for the wild card - 
> if we do NSEC.)

Indeed.

Cheers,

Ben.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Sep 2004 23:54:58 +1000

> (e.g. a '*' in the middle somewhere) then you need to provide further 

	No.  You need to prove the QNAME does not exist.  You need
	to prove the (singular) wildcard does not exist.  You need
	to prove that the wildcard without the first label exists.

	This comes directly from RFC 1034.  If you look at RFC 1034
	you will see that for any given zone and QNAME there is one
	and only one possible wildcard match.

	With NSEC you can always do this with a maximum of two records
	and if you are lucky with one.  The NSEC record that proves that
	the QNAME does not exist also identifies which wildcard needs
	to be checked and provides the proof of existance of the wildcard
	without the first label.

	Mark
 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Sep 2004 09:59:36 -0400

At 14:02 +0100 9/8/04, Ben Laurie wrote:
>>>  What I want to know is: what does DNSSEC have to demonstrate to be sure it
>>>  has proved there's no wildcard match? Given the apparent lack of clarity,
>>>  can we be sure we know it does that currently?
>>
>>  If there is no RRSET matching (QNAME, QCLASS, QTYPE), DNSSEC has to provide
>>  a means for the recipient to validate the received message.
>>  tailored message - including the original query plus the empty data return
>>  (or name error) - then all that is needed is to do that.  The recipient
>>  would see the signed denial, get the key to validate it, and we are more
>>  or less done.
>>
>>  The NSEC approach uses precomputed statements (I assume we all know that).
>>  Combining the NSEC statements with 4.3.2, we need to supply one NSEC
>>  statement per "failure" to match in 4.3.2.  In the case of a name error,
>>  one error is the failure to find an exact match, a second error is the
>>  failure to find the '*'.
>
>That is if there is a "the" '*'. If there are multiple possibilities (e.g. a
>'*' in the middle somewhere) then you need to provide further proofs.

There are no multiple possibilities.  That's the point of the closest 
encloser - there is one and only one node present in the DNS data 
tree that is closest to the sought name.

The *only* wild card that is eligible to match the sought name is 
then "*.<closest encloser>."  This is regardless of the contents 
(label sequence) of the "closest encloser".

Suspending disbelief for the moment, let's say 1034 didn't restrict 
internal '*'s.  If there was the name "*. one.*.two.example.com" and 
I was matching "zebra.donkey.one.*.two.example.com"...  the closest 
encloser would be one.*.two.example.com (assuming no donkey or 
zebra.donkey).  In that case, "zebra.donkey" matches the first 
(leftmost) "*" in the wild card.

(This is all cool, 'cept for the blurb in 1034.  It really is...;))

---

From: Ben Laurie <[email-masked]>
Date: Wed, 08 Sep 2004 15:32:27 +0100

Edward Lewis wrote:
>>> the
>>> provide
>>> return
>>> that).
>> (e.g. a
> encloser - there is one and only one node present in the DNS data tree 
> that is closest to the sought name.
> 
> The *only* wild card that is eligible to match the sought name is then 
> "*.<closest encloser>."  This is regardless of the contents (label 
> sequence) of the "closest encloser".
> 
> internal '*'s.  If there was the name "*. one.*.two.example.com" and I 
> was matching "zebra.donkey.one.*.two.example.com"...  the closest 

Well, this is certainly my understanding, too, but I thought the 
discussion was heading towards it possibly not being true!

Cheers,

Ben.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Sep 2004 12:18:50 -0400

At 15:32 +0100 9/8/04, Ben Laurie wrote:
>>  Suspending disbelief for the moment, let's say 1034 didn't restrict internal
>>'*'s.  If there was the name "*. one.*.two.example.com" and I was matching
>>"zebra.donkey.one.*.two.example.com"...  the closest encloser would be
>>one.*.two.example.com (assuming no donkey or zebra.donkey).  In that case,
>>"zebra.donkey" matches the first (leftmost) "*" in the wild card.
>
>Well, this is certainly my understanding, too, but I thought the discussion
>was heading towards it possibly not being true!

Just to make sure I understand - given the zig-zag nature of *my* 
comment, I'm not clear on which "heading" you are talking about. ;)

Are you favoring allowing internal "*"s in all cases, as is proposed 
in the "thesaurus attack" message?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Sep 2004 08:39:49 +0700

Date:        Wed, 08 Sep 2004 00:28:49 -0400
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  | I was considering the difference between an NXDOMAIN and a NODATA 
  | response to be a significant one.

I agree, it is.

  | Admittedly, there isn't much 
  | difference from the perspective of a garden-variety app calling 
  | gethostbyname(),

which is what I meant by "no functional difference" which isn't the
same thing as "no difference".

  | or whatever, but I was under the (possibly mistaken) 
  | impression that this difference mattered from a DNSSEC perspective.

Yes, internally, in the DNS, they're totally different things.

  | At the very least, isn't part of the justification for having a concept 
  | of "empty non-terminal"s at all (a concept that I think belongs to an 
  | old-fashioned "tree" paradigm rather than the more modern 
  | index-into-a-database paradigm, and therefore rather difficult to convey 
  | to novices who often aren't so steeped in hierarchical design models)

Old fashioned or not, the DNS is a tree design.   Attempting to interpret
or explain it any other way can only lead to problems.
 
  | the alleged ability of a caching resolver to "prune" the namespace, so 
  | that queries for names underneath a "branch" that is known to not exist 
  | at all (i.e. an empty non-terminal) can be automatically answered in the 
  | negative without having to incur a subsidiary query to the authoritative 
  | servers for the zone?

[Aside: I assume the parenthitical remark was "not an empty non-terminal" ??]

But from where does this supposed intent to allow resolvers (caches) to make
that kind of conclusion arise?   I certainly favour no such approach.
A negative answer is a negative answer to a particular query, and nothing
should be attempting to draw conclusions about other queries.

  | If we're going to consider NXDOMAIN and NODATA to 
  | be functionally equivalent,

Only functionally equivalent ("the data you wanted doesn't exist")
not equivalent.

  | then I say let's go all the way and just 
  | abolish the notion of an "empty non-terminal" altogether. K.I.S.S.

What is simple in this area isn't always obvious.   In particular,
attempting to explain just why some names that don't exist can have
descendants, but others can't would be an interesting experience.
(as in, you can have x.y.example.com without y.example.com, but you
can't have x.example.com without example.com existing).

It is better (and simpler) to simply require that a name exists if
any sub-domains of it are to exist.

  | If, on the other hand, NXDOMAIN and NODATA are not, "[f]or all practical 
  | purposes [...] exactly the same", then the spec should either a) refine 
  | the lookup algorithm to *only* give special meaning to asterisk labels 
  | that are part of "wildcard"s,

That should certainly happen - in fact, that's what the spec currently
says, all you need to do is read 1034 (4.3.2, and 4.3.3) as it really
is quite clear about how the things work, and where special meaning gets
attributed to '*'.

  | or b) broaden the definition of "wildcard" 
  | to include any name with an asterisk label in it.

This isn't an alternative, it is true as well, any name with a '*'
label is a wildcard (at one point).    However, this probably doesn't
have the impact you're expecting, as wildcards are not name pattern matching
characters, they're RR generators (1034 says so) - that is, if at some
point a name doesn't exist, but a wildcard sibling does, then the RR's
at the wildcard are used to generate RR's (of the appropriate type, if
they exist) for the QNAME.    That's it.

  | Hopefully the new 
  | draft can reconcile the tension that exists between _de_jure_ 
  | "wildcards" and _de_facto_ "names containing asterisk labels that might 
  | cause special behavior within the lookup algorithm".

One hopes so, especially given that there really shouldn't be any
discussion amongst us here at all about the wat this all works.   Everyone
here should be thoroughly familiar with the text in 1034 - or at the
very least, willing to go read it and understand it.

The point of this draft should be to make all of this clear to people
who can't be bothered to actually read 1034 carefully enough to
understand it.

  | In addition to the difference between an NXDOMAIN and a NODATA response, 
  | there is still the legalistic question of whether Section 4.3.3's 
  | prohibition on multiple asterisk labels in a "wildcard" owner name 
  | functionally "turns off" the special behavior that would otherwise occur 
  | with asterisk labels, in the case where none of the 
  | multiple-asterisk-labels happens to be the first label of the name, and 
  | therefore the name itself does not technically qualify as a "wildcard" 
  | under 4.3.3's definition...

That's not a meaningful question at all.   Any label in the DNS is the
first label of some name (exactly one name).   It is impossible to have
a label that isn't.

kre

---

From: Ben Laurie <[email-masked]>
Date: Thu, 09 Sep 2004 17:38:38 +0100

Edward Lewis wrote:

>>> internal
>> discussion
> Are you favoring allowing internal "*"s in all cases, as is proposed in 
> the "thesaurus attack" message?

In terms of purity, I think internal "*"s should be allowed, but I do 
think its a completely pointless pastime in practice. It will cause 
confusion for little benefit, though I am 100% in favour of that small 
benefit (reduced code complexity).

So, I guess, yes, allow them, but the first sentence of wildcard-clarify 
should be "Yes, you can have a * in the middle of a name, BUT IT ISN'T A 
WILDCARD".

Cheers,

Ben.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 10 Sep 2004 09:46:42 +0200

On Thu, 09 Sep 2004 17:38:38 +0100

>  should be "Yes, you can have a * in the middle of a name, BUT IT ISN'T A 

Somewhere in this thread Kevin used the terms "wildcard" and
"asterix-label". I think that using these two terms brings a lot of
clarification.

The way I read the thread is that we may get consensus on:

Allowing for an asterix-label anywhere in a domain name, while only
asterix-labels at the most significant position (or the left hand
side) of a domain name are interpreted as wildcards by the search
algorithm, is an interpretation of the scripture that is in line with
its spirit of 1034.

Am I way out of line with that statement?

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Sep 2004 10:26:10 -0400

>"asterix-label". I think that using these two terms brings a lot of

Maybe the phrase for a "wildcard" ought to be a "synthesis source."

>Am I way out of line with that statement?

I need some clarification (no pun intended):

Let's say I have this in my zone:

example.com.    SOA    ...
                 NS     localhost.
*               TXT    1
bar.*           TXT    2
*.bar.*         TXT    3

If the query is for "foo.bar.star.example.com, TXT" is the answer "1"?
If the query is for "foo.bar.*.example.com, TXT" is the answer "3"?
If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN?

I think the answer for all three is "yes" (no trick questions intended;)).

I.e., can both *.example.com and *.bar.*.example.com be wildcards 
(synthesis sources)?

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 10 Sep 2004 11:13:17 -0400

> -----Original Message-----
> From: [email-masked]

> Maybe the phrase for a "wildcard" ought to be a "synthesis source."

Clunky but descriptive.  I would recommend it for this thread.

> I.e., can both *.example.com and *.bar.*.example.com be wildcards

I would think "Yes" for the 3 questions, and the last question.  My read on
1034 and the wildcard discussion is that only the leftmost '*' indicates a
synthesis source.  Any '*' as a label in a multi-label string is just that:
a label.

In the name "*.bar.*.example.com" -

*.bar.*.example.com
^     ^
|     Just a character.
synthesis source.

Hope that comes out in the formatting...

Scott

---

From: Ben Laurie <[email-masked]>
Date: Fri, 10 Sep 2004 19:16:04 +0100

> I think the answer for all three is "yes" (no trick questions intended;)).

I agree.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

---

From: Alex Bligh <[email-masked]>
Date: Fri, 10 Sep 2004 20:04:31 +0100

> [A] If the query is for "foo.bar.star.example.com, TXT" is the answer "1"?
> [B] If the query is for "foo.bar.*.example.com, TXT" is the answer "3"?
> [C] If the query is for "foo.*.example.com, TXT" is the answer NXDOMAIN?

And just for further clarity:

[D] if the query is for "bar.star.example.com, TXT", the answer, like [A]
is "1" (not "2")

[E] if the query is for "bar.*.example.com, TXT", the answer is "2"

Am I right?

(I think [A] & [D] are are the MARID questions though I'm not following
MARID).

Alex

---

From: Edward Lewis <[email-masked]>
Date: Fri, 10 Sep 2004 15:11:37 -0400

>[E] if the query is for "bar.*.example.com, TXT", the answer is "2"

Yeah.  E is a direct hit.

>(I think [A] & [D] are are the MARID questions though I'm not following

If I recall correctly, the desire there was to have:

        *.example.com   MX     ...
_marid.*.example.com   MARID  ...

And hope that the _marid record would match all the hits for the MX 
record. The thought came about from an understanding of the SRV 
record's prefixing convention (that the SRV record for ssh would be 
at _ssh._tcp.<hostname>).

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 10 Sep 2004 15:19:46 -0400

> [mailto:[email-masked]]On Behalf Of Alex Bligh

> [D] if the query is for "bar.star.example.com, TXT", the answer, like [A]

Hmmm, not sure.  The way I read RFC1034 algo, "star.example.com" is the
closest encloser to the query, so NXDOMAIN would be returned.  This would
hamper one of the ideas the MARID WG had.

> [E] if the query is for "bar.*.example.com, TXT", the answer is "2"

I think that is the answer as well.

Scott

---

From: "Scott Rose" <[email-masked]>
Date: Fri, 10 Sep 2004 15:24:35 -0400

Whoops, my bad:

The closest encloser for [D] would be "example.com".  not
"star.example.com".  At least that's my impression from the wildcard clarify
draft.

Scott

> Sent: Friday, September 10, 2004 3:05 PM
> To: Ben Laurie; Edward Lewis
> Cc: Olaf M. Kolkman; [email-masked]; Alex Bligh
> Subject: Re: more wild cards
>
>