Subject: Re: clarity on wildcards

From: [email-masked]
Date: Fri, 28 Feb 2003 23:15:12 +1100

> Hi.
> 
> I recently found out that there are some discrepancies in how different
> implementations handle wildcards. Let's say the DNS server authoritative
> for the zone "c." contains these records:
> *.c. A 192.168.1.1
> a.b.c. A 192.168.1.2
> 
> BIND8.3.4 gives these results:
> z.a.b.c. NXDOMAIN
> b.c. NODATA
> b.b.c. NXDOMAIN
> d.c. A 192.168.1.1
> 
> BIND9.2.2rc1 gives these results:
> z.a.b.c. NXDOMAIN
> b.c. A 192.168.1.1
> b.b.c A 192.168.1.1
> d.c. A 192.168.1.1

	9.2.2rc1 is wrong.  Fixed in 9.3.
 
> tinydns gives these results:
> z.a.b.c. A 192.168.1.1
> b.c. A 192.168.1.1
> b.b.c. A 192.168.1.1
> d.c. A 192.168.1.1

	this is wrong
 
> Mark Andrews has said[1] that BIND9.3 does this:
> b.c. NODATA or NXDOMAIN (does not match *.c)
> which implies
> b.b.c. NXDOMAIN
> 
> Edward Lewis has said[2] (as I understood it, please correct me if I 
> am wrong, this discussion includes elements I am not familiar with) that 
> this is the correct response:
> b.b.c. 192.168.1.1 (matches *.c)
> which implies
> b.c 192.168.1.1 (matches *.c)

	Ed is wrong.
 
> By my own understanding of RFC1034, BIND9.2.2rc1 is the only one listed
> that gets all cases right. In my opinion, b.c should match the wildcard, 
> because RFC1034 says:
> ---
> Wildcard RRs do not apply:
> 
>    - When the query is in another zone.  That is, delegation cancels
>      the wildcard defaults.
> ---
> which implies that other RRs do not cancel the wildcard. I say this 
> because, if a zone includes this delegation:
> d.e.c.	NS	some.name.server.
> or in fact any label attached to d.e.c., then by BIND8/BIND9.3 logic, 
> anything on the form *.e.c is already cancelled, and only specifying that 
> *.d.e.c is cancelled is pointless, especially when it additionally limits 
> this to delegations.
> 
> Also, the reverse case is detailed, where a subdomain of the query name 
> exists between the query name and the wildcard:
> ---
> Wildcard RRs do not apply:
> [snip]
>    - When the query name or a name between the wildcard domain and
>      the query name is know to exist.  For example, if a wildcard
>      RR has an owner name of "*.X", and the zone also contains RRs
>      attached to B.X, the wildcards would apply to queries for name
>      Z.X (presuming there is no explicit information for Z.X), but
>      not to B.X, A.B.X, or X.
> ---
> but if a.b.c were to cancel b.c from matching *.c, that would surely be
> worthy of mention? In addition, this definition implies that existence of
> a name is existence of an RR attached to that name, not the existence of
> an RR where the label has the name at the end.

	Nodes are allowed to be empty.
 
> So, which one _is_ right? Please support your arguments thoroughly, I am
> clearly not the only one who needs to be convinced.

	Label matching is done a label at the time from the root.
	Only if a label doesn't match do you look for a wildcard
	at the same level as the non-matching wildcard.

	For d.b.c,  c matches, b matches, d doesn't match so you look
	for a wild card at this level (*.b.c).  This doesn't exist

	Read section "4.3.2. Algorithm" again.  Pay close attention
	to the references to the "*" label in step 3.

> [1] http://marc.theaimsgroup.com/?l=bind-users&m=104634519523021&w=2
> [2] http://marc.theaimsgroup.com/?l=namedroppers&m=103549359131894&w=2
> 
> Ketil Froyn
> [email-masked]
> http://ketil.froyn.name/
> 
> 
> 
> 
> 
> --
> 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, Internet Software Consortium
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: Robert Elz <[email-masked]>
Date: Fri, 28 Feb 2003 19:24:59 +0700

Date:        Fri, 28 Feb 2003 12:24:05 +0100 (CET)
    From:        Ketil Froyn <[email-masked]>
    Message-ID:  <[email-masked]>

  | BIND8.3.4 gives these results:

This one is correct.

All the others shown are wrong.

  | Wildcard RRs do not apply:
  | 
  |    - When the query is in another zone.  That is, delegation cancels
  |      the wildcard defaults.
  | ---
  | which implies that other RRs do not cancel the wildcard.

No it doesn't.   You can't make inferences like that, they make
no logical sense.

  | I say this 
  | because, if a zone includes this delegation:
  | d.e.c.	NS	some.name.server.
  | or in fact any label attached to d.e.c., then by BIND8/BIND9.3 logic, 
  | anything on the form *.e.c is already cancelled, and only specifying that 
  | *.d.e.c is cancelled is pointless,

Yes, I agree, and have wondered why that particular limitation needed
to be there - perhaps it is just to make it clear that a wildcard can
never result in a referral.

  | Also, the reverse case is detailed, where a subdomain of the query name 
  | exists between the query name and the wildcard:
  | ---
  | Wildcard RRs do not apply:
  | [snip]
  |    - When the query name or a name between the wildcard domain and
  |      the query name is know to exist.

This is the one that makes it clear.   If b.b.c exists, then necessarily
b.c exists as well (note, you need to go back and investigate the definition
of a "domain" to see why this is so, and note that domains are not required
to own any RR's).   So *.c cannot apply to a.b.c as a name between the
wildcard domain and the query domain is known to exist (that is, b.c).

  | So, which one _is_ right? Please support your arguments thoroughly, I am
  | clearly not the only one who needs to be convinced.

This discussion has been had many times - just go back and check the
namedroppers archives, you'll find it, more than once.   There really
is no need to do it all again.

kre

---

From: Edward Lewis <[email-masked]>
Date: Fri, 28 Feb 2003 08:01:58 -0500

>Edward Lewis has said[2] (as I understood it, please correct me if I

What I wrote in message [2] is wrong (it predates the wild card 
clarification document).  What is in the wild card clarifications 
draft says that b.c. is the "closest enclosing" domain of b.b.c, 
hence the only potential wild card to synthesize an answer would be 
at *.b.c.  In your example, there isn't one, hence an authoritative 
name error is the correct response.

 From the list included, only the Bind 8.3.4 gives the right responses 
in all cases.

>    - When the query is in another zone.  That is, delegation cancels

Unless b.c has an NS set itself, it belongs to the same zone as *.c. 
So this isn't the reason the wild card is "blocked."

>an RR where the label has the name at the end.

Read section 3.1 of 1034 and 4.3.2 Step 3 part c.  I tried to 
summarize it in the wild card clarify draft - let me know if the text 
there fails.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer