Subject: Re: wild cards

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Sep 2004 11:35:31 +1000

> Yes, I'm actually spending time on the draft...
> 
> I have a question relating to what's a legal name.  Yea, I've asked 
> this before, a few months ago.  But the answer I got then does not 
> agree with what's in the minutes for the last (err, most recent?) 
> meeting of the WG in Minneapolis.
> 
> Here is a message from the list (June 2):
> 
> http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00810.html
> 
> Here is what is said in the minutes (Minneapolis, Nov 2003):
> 
> http://ops.ietf.org/lists/namedroppers/namedroppers.2003/msg02219.html, 
> specifically -
> 
> >Issue (4b): Whether or not "*" can be in the middle of a name.  There
> >was no discussion in the room on this one.  The basic issue is that
> >the draft goes to great length to talk about how this is handled.
> >Later on, someone noticed that 1034 discourages this.
> >
> >
> >Although there is no sentiment to allow these names, nor is there any common
> >use, if the names are barred as in 1034, then more rules are needed to
> >specify what happens when they are (mistakenly?) seen.  If the rules aren't
> >specified then behavior is unpredicatable - perhaps in ways that don't
> >matter very much.
> >
> >An older mail list discussion leaned toward staying with 1034's definition.
> 
> In RFC 1034, this is, as far as I can tell, the definition:
> 
> # The owner name of the wildcard RRs is of
> # the form "*.<anydomain>", where <anydomain> is any domain name.
> # <anydomain> should not contain other * labels, and should be in the
> # authoritative data of the zone.
> 
> So, should I take this to mean that:
> 
>   a.*.example.com is legal and *.example.com synthesizes records
>   *.*.example.com is illegal and "is an error" (on load of zone/dynamic updat
> e)?
>   *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0)

	I suspect the intent was to only allow "*" as the left most
	label.  a.*.example.com and *.*.example.com would both be
	illegal if this was the case.

	Allowing a.*.example.com but disallowing *.*.example.com
	is stupid.  You either allow both or disallow both.

	Mark
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                            +1-703-227-9854
> ARIN Research Engineer
> 
> "I can't go to Miami.  I'm expecting calls from telemarketers." -
> Grandpa Simpson.
> 
> --
> 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/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [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: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 2 Sep 2004 10:17:13 +0200

>   a.*.example.com is legal and *.example.com synthesizes records

That is not the way I read the Scripture. If a.*.example.com would
have been legal I would have expected text like:

  [<anydomain>.]*.<anydomain> where anydomain is any domain name. 

> *.*.example.com is illegal and "is an error" (on load of
>  zone/dynamic update)?

Is exactly what I would read.

>   *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0)

But here you have my personal opinion.  I wonder how implementors have
interpreted the scripture. Are there any implementations that deal in
one of the ways Ed described? That is synthesise the * in
a.*.example.com?

- Olaf
  (namedropper)

---

From: Robert Elz <[email-masked]>
Date: Thu, 02 Sep 2004 20:48:49 +0700

Date:        Wed, 1 Sep 2004 11:56:47 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020407bd5b9bc9d506@[192.168.1.100]>

  |   a.*.example.com is legal and *.example.com synthesizes records
  |   *.*.example.com is illegal and "is an error" (on load of zone/dynamic update)?
  |   *.*.example.com is discouraged, as in "SHOULD NOT" (2119 - 1034 > 0)

First answer is that there is no such thing as an "illegal" domain name
(based upon content) - the only restrictions are on length.   1 character
domain names are clearly legal, whatever the character (octet value really)
is (including '\0' and '*').

You cannot refuse to load zones just because you don't like some of the
names that are in it (well, you can, if that's what the owner of the
domain wants - but not just because the software author prefers it that
way, or not without the software being defective).

Second part ...

Wildcards are relevant only for domain name lookup - when looking up the
name in a query, if no exact match is found, a search is done at the same
level of the tree for a '*' label - if that one is found, it matches the
entire rest of the query (no more searching happens).

That makes things like *.*.example.com and a.*.example.com meaningless
for this kind of query.

If we assume there is no x.example.com in the zone, and I make a query
for q.x.example.com any of the "wildcard" names in this message (my text
or the quoted text) match it.

That is, we're searching example.com for 'x', not found, search example.com
for the '*' wildcard - found, that then matches the "q.x" part of the query,
and we look no more.

It is most certainly not the case that the existence of (just) a.*.example.com
in a zone makes a lookup of a.x.example.com succeed, but one of 
b.x.example.com fail - if x.example.com matches the wildcard at all
(there is no x.example.com in the zone) then a query for any sub-domain of
x.example.com also matches the wildcard (the same wildcard).   There
is no way to limit that.

Third part ...

If we do a query for a.*.example.com we end up searching example.com for '*'
not as a wildcard, but as a label, in this case we find it, just as a label,
and go on to look for the sub-domain of *.example.com that we're querying
('a') in this case, in exactly the same manner that we would if the '*'
was replaced (in both the query and the zone) by 'z'.   Here, if
a.*.example.com exists in the zone, then it matches the query, and the
results are returned.   If there's no a.*.example.com in the zone file,
then we do a wildcard lookup (look for a '*' inside the *.example.com domain)
and if that one exists, it provides the answers.  If it doesn't, NXDOMAIN.

All this stuff is really amazingly simple if you consider the name space as a 
tree, and always think of it that way, and then obey the 1034 lookup algorithm.
It is only when you start to concentrate on zone file formats, and textual
representations, that things start to look more complex and messy.   So
don't do that.

Fourth part ...

No-one can really count upon any of the implementations actually
implementing all of these corner cases correctly (and certainly not
all of them).  So, for all practical purposes anything except a solitary
'*' as the leftmost label in a name loaded into a zone file is simply
going to produce random undefined results, and no-one should be doing
such a thing (but that people shouldn't do it doesn't mean that the
implementations should attempt to enforce that restriction).   The
best thing is to simply consider all this as "undefined behaviour".

kre

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Sep 2004 10:37:35 -0400

>way, or not without the software being defective).

It's true that there is no other restriction on a domain name other 
than label and total length.  And 1034 does mention that the null 
label is reserved for the root - not the null name, but the null 
label.  (So I think an encoding of "0x00 0x03 A B C" as illegal in 
the sense that the label "ABC" is trailing garbage.)

This doesn't bar us from now defining domain names as illegal - 
keeping in mind that anytime we do something for the first time we 
run the risk of problems elsewhere.

>That makes things like *.*.example.com and a.*.example.com meaningless

That's not entirely clear to me.  For the moment, let's assume 
there's no barring of *.*.example.com.

Let's say we have there records (assuming IN class all the way):

       example.com     SOA
       *.example.com   A     1.1.1.1
       *.*.example.com A     2.2.2.2
       a.*.example.com A     3.3.3.3

Query for (*.example.com A)   -> 1.1.1.1 is the return, exact match
Query for (a.example.com A)   -> 1.1.1.1 with closest encloser example.com
Query for (a.*.example.com A) -> 3.3.3.3 exact match, I think.
Query for (b.*.example.com A) -> 2.2.2.2 with closest encloser *.example.com
Query for (b.a.example.com A) -> 1.1.1.1 with closest encloser example.com

IOW - *.*.example.com creates a shadow between *.example.com and any 
subdomain of that name.

Okay, RFC1034 forbids ("discourages") *.*.example.com.  Let's strike 
it from the example.

       example.com     SOA
       *.example.com   A     1.1.1.1
       a.*.example.com A     3.3.3.3

Query for (*.example.com A)   -> no change from before
Query for (a.example.com A)   -> ditto
Query for (a.*.example.com A) -> ditto
Query for (b.*.example.com A) -> NXDOMAIN
Query for (b.a.example.com A) -> no change from before

There's a change for queries in the shadow of *.example.com - they 
become NXDOMAIN if not listed in the zone file.

So - I wouldn't say they are "meaningless."

>or the quoted text) match it.

Not really - *.*.example.com isn't "*" + $closest_encloser. 
(*.example.com is).

>for the '*' wildcard - found, that then matches the "q.x" part of the query,

Yeah.  Maybe I misunderstood the previous "in this message" comment.

>x.example.com also matches the wildcard (the same wildcard).   There

In my world, a.*.example.com wouldn't match a.x.example.com, 
*.example.com is the match.  Same for b.x.example.com - it is matched 
by *.example.com because there is no x.example.com.  If I ask for 
(x.example.com, A) I get an answer of "1.1.1.1", so there is an 
answer for the name, but it doesn't exist explicitly.

Maybe there's the conundrum.  In this instance I have an answer for a 
name that does not block wild card matching. "x.example.com" returns 
data (A) but does not stand in the way of b.x.example.com and 
*.example.com.  Without DNSSEC, this could be terribly confusing to 
the astute resolver.

My interest in this topic is more than academic (not that you are 
insinuating I'm being academic).  When I sat in on MARID in May, they 
wanted to be able to have a record like:  _marid.*.example.com.

(ref: http://www.imc.org/ietf-mxcomp/mail-archive/msg01597.html)

The options are to stand aside and let this be, create the notion of 
an illegal name, or to muffle the synthesis rules if *.<anydomain> 
has a (non-empty) subdomain itself.

>representations, that things start to look more complex and messy.   So

That's what I've been saying about wild cards for some time.  "They 
aren't confusing, they're just misunderstood."

>best thing is to simply consider all this as "undefined behaviour".

The effort is to get everyone to interoperate on this.  We want to 
stomp on corner cases that have gone haywire.  If not for just 
academic purity, but to be able to explain to groups like the MARID 
WG why "_marid.*.example.com" doesn't behave as they think it does.

---

From: Robert Elz <[email-masked]>
Date: Fri, 03 Sep 2004 02:37:50 +0700

Date:        Thu, 2 Sep 2004 10:37:35 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020406bd5cd75cb8dd@[192.168.1.100]>

  | It's true that there is no other restriction on a domain name other 
  | than label and total length.  And 1034 does mention that the null 
  | label is reserved for the root - not the null name, but the null 
  | label.  (So I think an encoding of "0x00 0x03 A B C" as illegal in 
  | the sense that the label "ABC" is trailing garbage.)

No, that's not illegal at all, it just doesn't mean what you you're
implying it might mean.   The 0 length byte (null label) terminates
the label.  The bytes that follow it simply aren't part of that label,
they're the next data from the packet (if the domain was in the name 
field, the "0x3 A" would be the type octets, and the "B C" the class).
 
Those are "unusual" type & class values, but not illegal in any way.

If this occurred as the start of the RDATA in an SOA, the 0x3 A B C
would just be the SOA.rname (or start thereof).

In other places they might generate a format error for the packet, but
that's still not an illegal domain name.

  | This doesn't bar us from now defining domain names as illegal - 
  | keeping in mind that anytime we do something for the first time we 
  | run the risk of problems elsewhere.

Of course not, we can go around redefining the world however we see fit.
We could declare the label "www" illegal if we wanted to.   Of course,
when we start moving things that have previously been perfectly valid
into being illegal, we have to allow for the possibility that people
have been using them, quite legitimately, for almost any reason at all
(either on the internet, or elsewhere).

There has to be a very good reason to make a change like that, and here
there is no reason at all.

  | That's not entirely clear to me.  For the moment, let's assume 
  | there's no barring of *.*.example.com.
  | 
  | Let's say we have there records (assuming IN class all the way):
  | 
  |        example.com     SOA
  |        *.example.com   A     1.1.1.1
  |        *.*.example.com A     2.2.2.2
  |        a.*.example.com A     3.3.3.3
  | 
  | Query for (*.example.com A)   -> 1.1.1.1 is the return, exact match

Queries that have '*' labels were my third case.   While perfectly valid,
they're unusual, and not what almost anyone is thinking of when we're
talking about wildcards (as the '*' in the zone that matches the '*' in
the query isn't wildcard at all).

  | Query for (a.example.com A)   -> 1.1.1.1 with closest encloser example.com
  | Query for (a.*.example.com A) -> 3.3.3.3 exact match, I think.
  | Query for (b.*.example.com A) -> 2.2.2.2 with closest encloser *.example.com
  | Query for (b.a.example.com A) -> 1.1.1.1 with closest encloser example.com

yes, I agree with all of those.

Those ones aren't even doubtful, they're all obvious.   The query you
need to explain carefully is a.b.example.com.

  | IOW - *.*.example.com creates a shadow between *.example.com and any 
  | subdomain of that name.

Sorry. I have no idea what that means.

  | Okay, RFC1034 forbids ("discourages") *.*.example.com.

Where is that?

  | Let's strike it from the example.
  | 
  |        example.com     SOA
  |        *.example.com   A     1.1.1.1
  |        a.*.example.com A     3.3.3.3
  | 
  | Query for (*.example.com A)   -> no change from before
  | Query for (a.example.com A)   -> ditto
  | Query for (a.*.example.com A) -> ditto
  | Query for (b.*.example.com A) -> NXDOMAIN
  | Query for (b.a.example.com A) -> no change from before
  | 
  | There's a change for queries in the shadow of *.example.com - they 
  | become NXDOMAIN if not listed in the zone file.

This isn't anything different from any other domain - if a name exists,
then a wildcard sibling doesn't apply to any of its sub-domains.  What
is supposed to be different here?

  | So - I wouldn't say they are "meaningless."

The "meaningless" was in the context of my second case, which was
assuming (though perhaps I didn't make this as clear as I should)
"normal" queries - the same kind we see every day, with no '*' labels
in the name being sought.  In that context, these sub-domains of '*'
labels are completely meaningless (or perhaps irrelevant is a better word).

  | Yeah.  Maybe I misunderstood the previous "in this message" comment.

I wrote the message sequentially, it was correct when I put in that
phrase, it may not have remained correct by the time I finished...

  | In my world, a.*.example.com wouldn't match a.x.example.com, 
  | *.example.com is the match.

Yes, absolutely.

  | Maybe there's the conundrum.  In this instance I have an answer for a 
  | name that does not block wild card matching. "x.example.com" returns 
  | data (A) but does not stand in the way of b.x.example.com and 
  | *.example.com.  Without DNSSEC, this could be terribly confusing to 
  | the astute resolver.

I see nothing confusing at all.   Resolvers know nothing of wildcards.
When a resolver gets an answer (without dnssec, which does make life
more difficult here, but in unavoidable ways I believe) the resolver
simply assumes that any answer it gets is an explicit RR in the zone,
and any answer it doesn't get (packet transport problems ignored) doesn't
exist.   No astuteness, or even anything beyond feeble mindedness
required at all for this.

  | My interest in this topic is more than academic (not that you are 
  | insinuating I'm being academic).  When I sat in on MARID in May, they 
  | wanted to be able to have a record like:  _marid.*.example.com.

Yes, that's absurd.  Making it clear that cannot work (the way they're
imagining) is certainly what this draft should do.

But to accomplish that we don't have to, and should not be, making
any domain names become illegal.   We just need to clarify how the
lookup algorithm works (and in the case of CNAME, perhaps, change it,
which is really a side issue here).

  | The options are to stand aside and let this be,

No, no matter what we do, the planned interpretation does not, and
cannot, ever work.   That would take a major redefinition of the DNS
lookup algorithms to accomplish, plus deployment of modified servers
all over the place.   Not likely.

  | create the notion of 
  | an illegal name, or to muffle the synthesis rules if *.<anydomain> 
  | has a (non-empty) subdomain itself.

No, nothing needs changing at all - merely a more explicit statement
of the current wildcard lookup procedures.

Certainly people don't understand this stuff as well as perhaps they
should (and since in general most of us just try to discourage wildcard
use in all cases, rather than explain it, that may be understandable).
If the method was well understood, no-one would be even suggesting that
silly technique.

  | That's what I've been saying about wild cards for some time.  "They 
  | aren't confusing, they're just misunderstood."

Yes.   So let's fix the problem, not redefine it into something else
and then fix that.   Let's just clarify how the things work, and (with
the possible exception of the way CNAME works), change nothing at all.

  | The effort is to get everyone to interoperate on this.  We want to 
  | stomp on corner cases that have gone haywire.  If not for just 
  | academic purity, but to be able to explain to groups like the MARID 
  | WG why "_marid.*.example.com" doesn't behave as they think it does.

Sure, we need to do that.   But doing that isn't going to fix whatever
broken implementations currently exist.   What this means is that in
practice, however well these odd cases are supposed to be defined, it
isn't possible to rely upon them doing what they should.   Fortunately,
apart from that _marid.*.whatever nonsense, no-one in practice ever
attempts to do this kind of thing (and that attempt is simply doomed to
fail, even if we were to do nothing - it just may take longer for the
authors of that draft to realise it).

kre

---

From: Edward Lewis <[email-masked]>
Date: Thu, 2 Sep 2004 16:13:39 -0400

>(either on the internet, or elsewhere).

We moved IQUERY to historic.

>phrase, it may not have remained correct by the time I finished...

Then I think I've wasted a lot of bit's on this.

>which is really a side issue here).

 From what I've heard, the WG disagrees with this line of reasoning.

Just because something is legal doesn't mean it has to remain legal.

>all over the place.   Not likely.

I don't see restricting the names having anything to do with the resolver side.

In addition (in answer to something I dropped) RFC 1034, 4.3.3. already says:
      <anydomain> should not contain other * labels...
which is a name restriction already.  It seems to me that there was 
an intent to restrict names involving wild cards.

---

From: Robert Elz <[email-masked]>
Date: Fri, 03 Sep 2004 04:40:13 +0700

Date:        Thu, 2 Sep 2004 16:13:39 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020410bd5d2ac62262@[192.168.1.100]>

  | We moved IQUERY to historic.

Yes, because that was broken as specified and simply didn't, and
couldn't work.   We can move anything else like that to historic
as well.   But one domain name is the same as any other domain name,
they all work just the same way - if it is OK to move one to historic
(or "make it illegal") it has to be just as OK to do the same to any
other arbitrary domain name.

  | Then I think I've wasted a lot of bit's on this.

Yes, sorry - but I think we mostly (or completely) agree on how the
things actually work.

The question is just whether there's anything needs to be changed to
clear up the misunderstandings that exist.

I still say no.  No changes, just explanation.   (The CNAME proposed
change is for other reasons).

  |  From what I've heard, the WG disagrees with this line of reasoning.

I'd like to hear from other members of the WG now.   In the past couple
of days at least, there has been nothing (on this topic) from anyone
except the two of us...  (since I started in on it anyway).

So, after this message, I'll go back to hibernate state for a while I
think (unless someone says something outrageous...)

  | Just because something is legal doesn't mean it has to remain legal.

No, as I said before, things can be changed - but we really have to be
very certain that the change is essential to do that kind of thing.

  | >No, no matter what we do, the planned interpretation does not, and
  | >cannot, ever work.   That would take a major redefinition of the DNS
  | >lookup algorithms to accomplish, plus deployment of modified servers
  | >all over the place.   Not likely.
  | 
  | I don't see restricting the names having anything to do with the
  | resolver side.

No, nor do I (unless of course there's someone somewhere actually doing
lookups of names with '*' (literal) labels in them which you're proposing
to prevent working).   Note I said "deployment of modified servers", nothing
there about resolvers.   Also note that the entire name lookup algorithm
occurs within servers, the resolvers do none of it (they just hand off
the name they're seeking to one server after another, as they're instructed,
until they eventually either get an answer (positive or negative) or decide
to give up trying.

  | In addition (in answer to something I dropped) RFC 1034, 4.3.3. already says:
  |       <anydomain> should not contain other * labels...

Ok, I see that.

  | which is a name restriction already.

Maybe, that's a section describing wildcard processing, not legal names,
so I think that can be argued either way.   That throw away remark doesn't
seem to have any impact on anything, and most likely shouldn't be there
at all.

  | It seems to me that there was 
  | an intent to restrict names involving wild cards.

I think it is important that we're clear that a '*' name is only a wildcard
when it is being used that way as part of the lookup algorithm.   Otherwise
it is simply an ordinary domain name.

When a server sees a '*' label in a zone file, there's no way it can tell
which of those two ways it will actually get used.   It may presume it is
likely to be used as a wildcard, as if a wildcard is needed, it is there to
fill the role - but if no-one ever does a lookup of a non-existing name
(yeah - I know - not a likely assumption, but nevertheless) then it would
never be used as a wildcard - whereas if there are lookups for the literal
'*' it is being used as an ordinary domain name label.

kre

---

From: Ben Laurie <[email-masked]>
Date: Sun, 05 Sep 2004 13:12:00 +0100

> '*' it is being used as an ordinary domain name label.

Is this really a distinction? If '*' is a wildcard, then it will match 
'*' just as well as anything else. So, if a server assumes it is always 
a wildcard, then it is never wrong, is it? So it isn't clear to me why 
it is important to make this distinction.

Unless you are trying to handle the 'x.*' case by saying this, in which 
case I agree but I'm not sure its a helpful way to express it.

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: Robert Elz <[email-masked]>
Date: Mon, 06 Sep 2004 02:36:58 +0700

Date:        Sun, 05 Sep 2004 13:12:00 +0100
    From:        Ben Laurie <[email-masked]>
    Message-ID:  <[email-masked]>

  | Is this really a distinction? If '*' is a wildcard, then it will match 
  | '*' just as well as anything else. So, if a server assumes it is always 
  | a wildcard, then it is never wrong, is it? So it isn't clear to me why 
  | it is important to make this distinction.

It matters because of the way the lookup algorithm is defined.   When
a label is found by an exact match (well, a case independent exact match)
a certain sequence of further actions takes place (including handling CNAME
records, and delegations).

On the other hand, when no match is found, then a check for a wildcard is
made, different steps follow - which includes auto-match of all the remaining
labels in the query, but doesn't include delegations, nor (currently)
following of CNAME records.

For better of worse, this is how it all is defined to work.   What we're
supposed to be doing is making it all clear.   Burying this distinction,
while an irrelevant one for most purposes, makes it almost impossible to
be as clear as we need to be about how it all works.

kre

---

From: Daniel Roesen <[email-masked]>
Date: Tue, 7 Sep 2004 01:40:10 +0200

> >Later on, someone noticed that 1034 discourages this.

It seems like BIND did change behaviour server-side when loading zones
containing such wildcard constructs between 8 and 9. The SourceForge
people got bitten by that:

http://sourceforge.net/docman/display_doc.php?group_id=1&docid=2352

<cite>
As of 2004-04-28 the CVS services will no longer function with the
hostname of cvs.PROJECTNAME.sourceforge.net. You should change your CVS
commands to use the host cvs.sourceforge.net [...]. This issue came
about as a result of upgrading from BIND 8 to BIND 9 which doesn't
allow for a wildcard in the middle of a hostname.
</cite>

Best regards,
Daniel

---

From: Alex Bligh <[email-masked]>
Date: Mon, 20 Sep 2004 16:05:18 +0100

> Yes, I'm actually spending time on the draft...

Where can the current version of the draft be found? Searches for
draft-ietf-dnsext-wcard-clarify-03.txt all have it removed as it's
expired, and -04 doesn't seem to be out yet.

I have a couple of nits in the original RFC wording which have probably
been found by someone else, but wouldn't mind checking...

Alex

---

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Sep 2004 16:15:45 +0100

>expired, and -04 doesn't seem to be out yet.

There isn't an active copy anywhere, as far as the IETF is concerned.

http://www.potaroo.net/ietf/idref/draft-ietf-dnsext-wcard-clarify/ is 
the one place I know to find the old copies.

(I have a copy that Robert Elz maintained but never made the ID repository.)

---

From: Alex Bligh <[email-masked]>
Date: Mon, 20 Sep 2004 16:51:10 +0100

A couple of comments on draft-ietf-dnsext-wcard-clarify-02.txt (in
the absence of a more recent version

1. QCLASS
=========

>    Section 1.
>    ...
>    Note that a wild card domain name has no special impact on the search
>    for a query type (QTYPE).  If a domain name is found that matches the
>    QNAME (exact or a wild card) but the QTYPE is not found at that
>    point, the proper response is that there is no data available.

What happens in the following scenario:
	$ORIGIN example.com
	* IN MX target.example2.com.
	foo IN TXT "bar"
	baz HS [blah]

If a query is of QCLASS IN and QTYPE MX is executed for "foo.example.com",
the correct response is no data, not the the wildcard MX. If a query of
QTYPE ANY and QCLASS IN is sent for "baz.example.com", is this true as
well? Or is the right response the wildcard? 4.3.3 of RFC1034 is unclear.

[aside: noticed this thinking a different CLASS might be useful for
NSEC' to get around the wildcard problem]

2. Names starting with '*'
==========================

Section (2) of wcard-clarify is clear; one thing it clarifies that
you haven't noticed is a miswording in 4.3.3 of 1034.

> In the previous algorithm, special treatment was given to RRs with owner
> names starting with the label "*". Such RRs are called wildcards.

This might be read to include "*foo.example.com". It's obviously meant to
mean "RRs with owner names starting with a label which exactly matches
'*'". The label starting with "*" case could be made clearer, partly
for reasons in [] below.

3. Labels with dots in them
===========================

(not strictly wildcards but I think relevant because of (2) above).

There does not appear to be anything which prevents having a single
label with a "." in it, i.e. a label of 0x03 0x41 0x2e 0x42, which
is a single label of "a.b" (as opposed to two concatenated labels
a.b). RFC 1034 s3.1 seems to be quite clear on that.

I am presuming these are legal because there is nothing saying they
aren't, and the reason we aren't "taking the easy way out" and
banning things like "foo.*.bar.example.com" is the principle of
binary transparency.

On the other hand, I think (according to 4.3) that no QNAME can
match these - correct? If not, what happens with labels starting
"0x2a 0x2e" (i.e. starting with "*.")?

[ Suggesting that the illustration in RFC 1034 section 3.5 is
made mandatory will I suspect win me no friends ]

Alex

---

From: Robert Elz <[email-masked]>
Date: Tue, 21 Sep 2004 03:44:59 +0700

Date:        Mon, 20 Sep 2004 16:51:10 +0100
    From:        Alex Bligh <[email-masked]>
    Message-ID:  <3E2A3B81EA464133E59C9314@[192.168.0.16]>

  | A couple of comments on draft-ietf-dnsext-wcard-clarify-02.txt (in
  | the absence of a more recent version

 -02 is the most recent published version.   Unless Ed has submitted a new
version in the past few days, there has never been a -03 (I was working
on that one - unbelievably slowly - when Ed took over again).

  | If a query of
  | QTYPE ANY and QCLASS IN is sent for "baz.example.com", is this true as
  | well?

I'm going to let someone else attempt to explain classes, I never understood 
them (at all...)    There's one theory that there is a single uniform namespace
and classes just allow different data types (a different set of RR types)
which may be able to be managed by servers that are different for the same
named domains (or might not be) (in which case, the answer should be
NODATA, except if the trees can be at different servers the HS record might
not necessarily be in the same server as the * record, which makes it all
very hard to get right).  There's another hyppothesis that a different class
is an entirely separate DNS naming tree, with its own set of everything,
and the two classes simply don't mix in any way at all (in which case the
wildcard would certainly apply).

  | Or is the right response the wildcard? 4.3.3 of RFC1034 is unclear.

1034 is totally useless about classes.   A "DNS classes clarifications"
doc would certainly be needed if there was ever to be any serious effort
to do anything (standard) with the things - but most impressions I've
heard are "don't go there".

The CH and HS classes are local hacks that do whatever the software that
implements them wants them to do...

  | 2. Names starting with '*'
  | ==========================
  | 
  | Section (2) of wcard-clarify is clear; one thing it clarifies that
  | you haven't noticed is a miswording in 4.3.3 of 1034.
  | 
  | > In the previous algorithm, special treatment was given to RRs with owner
  | > names starting with the label "*". Such RRs are called wildcards.
  | 
  | This might be read to include "*foo.example.com".

No, it can't (reasonably) be - it says 'the label "*"', not 'the
character "*"'.

  | It's obviously meant to
  | mean "RRs with owner names starting with a label which exactly matches
  | '*'".

Yes, that's the only thing it can mean "*foo.ex..." starts with the label
"*foo" not with the label "*".

  | The label starting with "*" case could be made clearer,

No harm in making it even clearer though.

  | 3. Labels with dots in them
  | ===========================
  | 
  | (not strictly wildcards but I think relevant because of (2) above).

Not really...

  | There does not appear to be anything which prevents having a single
  | label with a "." in it,

No, nothing at all.  What's more there's nothing that prevents a label that
consists entirely of the '.' character.

  | i.e. a label of 0x03 0x41 0x2e 0x42, which
  | is a single label of "a.b" (as opposed to two concatenated labels
  | a.b). RFC 1034 s3.1 seems to be quite clear on that.

Yes.

  | I am presuming these are legal

There's no need to presume, they are legal, and clearly legal, as you
indicated.

  | On the other hand, I think (according to 4.3) that no QNAME can
  | match these - correct?

No.  A QNAME that is 02 2a 2e 07 e x a m p l e 03 c o m 00
will match a "*." RR (of the appropriate type) in the example.com zone.

  | If not, what happens with labels starting
  | "0x2a 0x2e" (i.e. starting with "*.")?

No different than *foo - that's just another odd looking label, which has
no special properties whatever (aside from being pretty confusing to
novices).

Note that the textual representation for this, in master files, etc,
is "*\." not just ""*."

In practice it is just about impossible to actually use a label
containing a '.' from any (non DNS diagnostic) application, the
API's just aren't good enough to get the correct thing to the resolver
(they all start with text strings, and mostly don't handle escape
characters), which makes the things close to useless in practice
currently anyway.    But inside the DNS, where you should simply
never thing of domain names as text strings there is absolutely
no confusion whatever.

  | [ Suggesting that the illustration in RFC 1034 section 3.5 is
  | made mandatory will I suspect win me no friends ]

No....

kre

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Sep 2004 11:21:49 +0100

>NSEC' to get around the wildcard problem]

My point of view - I've not come across a zone that mixed classes. 
much less a zone file.

Quoting RFC 1034: "Since the class of all RRs in a zone must be the 
same, only the first RR in a zone need specify the class."  This is 
found under the example in 6.1.  (Search for the string to see the 
context.)

There's also this: "Note that the "cuts" in the name space may be in 
different places for different classes, the name servers may be 
different, etc." in section 4.2.

Given those passages, I'd say that the example above isn't a realistic example.

Overall, I have not seem much in the way of non-IN class work.  Yes, 
there's the "dig version.bind CHAOS TXT" stuff (specific to an 
implementation, cited as an example) but that isn't delegated, etc. 
I am aware that some folks have used the Hesiod class for stuff, but 
I haven't and haven't heard from anyone directly.

IOW - I don't have anything constructive to add here.  (Too bad I'm 
not paid by the word to say that...;))

>2. Names starting with '*'

Maybe the issue is "starting with the label '*'" vs. "starting with a 
label starting with '*'".  (Quotes changed to prevent "".)  What's 
meant in the text is that the whole label is "*", not just a prefix 
of it.

Is that what you mean?  Somewhere I think I defined the label in hex, 
just to be sure (length 1, char='*').

>3. Labels with dots in them

Definitely within spec.  But the label isn't printed as "a.b" but "a\.b".

>"0x2a 0x2e" (i.e. starting with "*.")?

Such a label isn't defined to be a wild card - or a source of 
synthesis.  What you've listed is a label "*\.", which isn't the same 
as "*".

>made mandatory will I suspect win me no friends ]

The context of 3.5 is:

"The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET)."

This isn't a restriction on domain names but an "out of scope" 
discussion of the impact of the selection of domain names for the 
convenience of applications in use in 1987.  (I suppose mail is still 
in use somewhere. ;))

I don't think that it was ever intended to restrict names to that 
syntax, nor even to 1123's definitions.  (That is for host names, not 
all domain names are host names.)