Subject: thesaurus attack

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Sep 2004 10:13:39 -0400

Now that I've got your attention, let's talk wild cards...

In the past week or so -

1) The history of wanting to clean up what's the deal with wild cards 
has returned, with some talk about legal names.  (This is one of the 
issues on the table.)

2) A well known coder supported the idea of making some names 
illegal, presumably this makes the coding cleaner as you then know to 
have "if"'s in some places.

3) A well known protocol analyst rejected the idea of makeing some 
names illegal because imposing restrictions would have two impacts - 
possibly retroactively creating bugs in code and restricting the 
theory and concept of the protocol.

4) Many unnamed operators have remained silent on the subject because 
no one really does this anyway.  Oh, 'cept that the MARID WG seems to 
have thought they might have wanted to open this box belonging to 
Pandora.

As editor of the document, I'd like to see us all get to something we 
can live with.  From the MARID experience, it's clear that we want to 
clarify what's going on here, ergo, we need to do something.

I'll float this idea.  It's an idea, I think it can work, but it's up 
to the WG.

REMOVE the restriction in 1034: "<anydomain> should not contain other 
* labels".

This opens the protocol to places it's not been, so there's no danger 
to old code.  Further, by relaxing a restriction it does not impinge 
another part of the protocol.

As far as "is it doable" - a lot of text has already been floated 
showing how the matching is "supposed to" work in the face of 
interior "*"s.  No one pointed out a problem with it until the words 
in 1034 were raised.

Those words in 1034 are the only ones that define "illegal" names in 
DNS.  Without them, we have no restrictions other than length (label 
and name).  In addition, dropping the restriction drops one more "if" 
statement (whose "then" clause wasn't really defined) while still 
leaving us with a "decidable" algorithm.

Comments?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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/>

---

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

At 10:13 -0400 9/8/04, Edward Lewis wrote:
>As far as "is it doable" - a lot of text has already been floated showing how
>the matching is "supposed to" work in the face of interior "*"s.  No one
>pointed out a problem with it until the words in 1034 were raised.

In another conversation, it was pointed out that I should mention 
where this text is.  It's in a retired version of the wcard draft, 
but available here:

http://www.potaroo.net/ietf/old-ids/draft-ietf-dnsext-wcard-clarify-00.txt

Look in "Appendix A."

---

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

Date:        Wed, 8 Sep 2004 10:13:39 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020407bd64c0ca0a9b@[192.136.136.102]>

  | I'll float this idea.  It's an idea, I think it can work, but it's up 
  | to the WG.
  | 
  | REMOVE the restriction in 1034: "<anydomain> should not contain other 
  | * labels".

I am all in favour of that, I don't think that restriction ever
made sense.

However...

  | This opens the protocol to places it's not been, so there's no danger 
  | to old code.

No.   It doesn't.   The extra '*' labels don't magically work as
wildcards, the lookup algorithm in 4.3.2 or 1034 would continue
unchanged.

The text that was in Appendix A of the wildcard draft is certainly
not needed, not that, or anything like it.   And explain the way
that wildcard lookups get done (with a liberal sprinkling of the words
from 1034 that explain how a '*' is an RR generator, and a complete
quashing of the notion that there is any kind of name pattern matching
happening - there isn't).

kre

---

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

Asking for clarification...

>wildcards, the lookup algorithm in 4.3.2 or 1034 would continue

So, looking at an example I used in another message, *.example.com is 
not a wildcard (synthesis source) because there's a 
*.bar.*.example.com?

>happening - there isn't).

Do you think the text in Appendix A is wrong?

Just to make sure the text is preserved in the archives, here is Appendix A:

Appendix A: Subdomains of Wild Card Domain Names

In reading the definition of section 2 carefully, it is possible to
rationalize unusual names as legal.  In the example given, *.example.
could have subdomains of *.sub.*.example. and even the more direct
*.*.example.  (The implication here is that these domain names own
explicit resource records sets.)  Although defining these names is not
easy to justify, it is important that implementions account for the
possibility.  This section will give some further guidence on handling
these names.

The first thing to realize is that by all definitions, subdomains of
wild card domain names are legal.  In analyzing them, one realizes
that they cause no harm by their existence.  Because of this, they are
allowed to exist, i.e., there are no special case rules made to disallow
them.  The reason for not preventing these names is that the prevention
would just introduce more code paths to put into implementations.

The concept of "closest enclosing" existing names is important to keep in
mind.  It is also important to realize that a wild card domain name can
be a closest encloser of a query name.  For example, if *.*.example. is
defined in a zone, and the query name is a.*.example., then the closest
enclosing domain name is *.example.  Keep in mind that the closest
encloser is not eligible to be a source of synthesized answers, just the
subdomain of it that has the first label "*".

To illustrate this, the following chart shows some matches.  Assume that
the names *.example., *.*.example., and *.sub.*.example. are defined
in the zone.

        QNAME                Closest Encloser   Wild Card Source
        a.example.           example.           *.example.
        b.a.example.         example.           *.example.
        a.*.example.         *.example.         *.*.example.
        b.a.*.example.       *.example.         *.*.example.
        b.a.*.*.example.     *.*.example.       no wild card
        a.sub.*.example.     sub.*.example.     *.sub.*.example.
        b.a.sub.*.example.   sub.*.example.     *.sub.*.example.
        a.*.sub.*.example.   *.sub.*.example.   no wild card
        *.a.example.         example.           *.example.
        a.sub.b.example.     example.           *.example.

Recall that the closest encloser itself cannot be the wild card.  Therefore
the match for b.a.*.*.example. has no applicable wild card.

Finally, if a query name is sub.*.example., any answer available will come
from an exact name match for sub.*.example.  No wild card synthesis is
performed in this case.

---

From: Peter Koch <[email-masked]>
Date: Fri, 10 Sep 2004 20:50:40 +0200

> not a wildcard (synthesis source) because there's a 

I'd say it is as long as there are RRSets owned by *.example.com, which
was the case in your example. Now if you left out the ``TXT 1'' RR from

> *               TXT    1
> bar.*           TXT    2
> *.bar.*         TXT    3

there'd be a '*' label as an empty non-terminal. To avoid empty terminals,
this should not instantiate '*.example.com' as a wildcard. However, that
conflicts with step 3 of the algorithm in 1034.

> Appendix A: Subdomains of Wild Card Domain Names

Applying the split terminology 'asterisk label' vs. wildcard could clarify
a lot here.

>         b.a.*.*.example.     *.*.example.       no wild card

[...]

> the match for b.a.*.*.example. has no applicable wild card.

Applying the rule "it's just a star" I find this difficult to understand
and inconsistent with the idea that the wildcard covering all subtrees.
What about *.*.example. as a QNAME? That would be covered by closest
encloser *.example. and *.*.example.com as a wildcard source.

-Peter

---

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

>conflicts with step 3 of the algorithm in 1034.

Ahh, yeah, what about empty non-terminal '*' nodes in the tree and 
the role they might play as a source of synthetic records.  Sigh.

I suppose if you read the very last paragraph of step 3, you would 
take this to mean that any name matching an empty non-terminal '*' 
node would result in a no error, no data return (neglecting the CNAME 
rules).

>encloser *.example. and *.*.example.com as a wildcard source.

I don't think that's right.

If you have *.example.com and *.*.example.com in the zone and the 
query is for *.*.example.com, then you'd get a direct hit on the 
latter zone member.

If the query was for *.*.*.example.com, you'd match the 
*.*.example.com "source of synthesis" - not the *.example.com.

Does that make sense?

---

From: Robert Elz <[email-masked]>
Date: Sat, 11 Sep 2004 03:08:56 +0700

Date:        Fri, 10 Sep 2004 11:36:13 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020409bd677918a675@[192.168.1.100]>

  | Asking for clarification...

  | So, looking at an example I used in another message, *.example.com is 
  | not a wildcard (synthesis source) because there's a 
  | *.bar.*.example.com?

No (I agree with your 3 "yes" answers).

But you can really only talk about a wildcard in the context of a
particular query, in some queries a '*' is a wildcard, in others it
is not.

  | Do you think the text in Appendix A is wrong?

Yes, some of it - but the worst is that it isn't explaining things
in the correct way.   Giving lists of domain names with '*'s in
them makes things look like patterns, and people are tempted to
do pattern matching.   That way gets very confusing, and the
answers people start assuming end up all over the place.   I don't
think any of the answers from the examples is wrong, just the way
it is explained.

  | The first thing to realize is that by all definitions, subdomains of
  | wild card domain names are legal.

This makes no sense, sub-domains of a domain which is *.xxx are legal,
but if it (*.xxx) is being used as a wildcard, it ends any query, whether
or not the '*' might have sub-domains is irrelevant.

  | The concept of "closest enclosing" existing names is important to keep in
  | mind.

Yes, though I'm not real sure I like that term - but I'm not sure what
would be a better one.

  | It is also important to realize that a wild card domain name can
  | be a closest encloser of a query name.

Not a wildcard domain, a '*' label.

  | For example, if *.*.example. is defined in a zone,

That's irrelevant here, but you do need to assume that *.example.com is
defined.

  | and the query name is a.*.example., then the closest
  | enclosing domain name is *.example.

"... which is not a wildcard, but simply a domain".

  | Keep in mind that the closest
  | encloser is not eligible to be a source of synthesized answers, just the
  | subdomain of it that has the first label "*".

That is, if there is a sibling domain (child of the same parent) for
the rightmost domain that does not explicitly exist, and that sibling
is '*', then any RRs it owns which are the same type as te QTYPE are
the answer returned for the QNAME.   If there are no RR's of the appropriate
type, NODATA is returned (shouldn't be using bindisms, but here everyone knows 
what I mean).

  | To illustrate this, the following chart shows some matches.  Assume that
  | the names *.example., *.*.example., and *.sub.*.example. are defined
  | in the zone.

... and that there are no other '*' labels in (or below) example.
(without that, some of the answers below might be wrong).   You also need
to assume that various other domains don't exist (like a.example).

  |         QNAME                Closest Encloser   Wild Card Source
  |         a.example.           example.           *.example.
  |         b.a.example.         example.           *.example.
  |         a.*.example.         *.example.         *.*.example.
  |         b.a.*.example.       *.example.         *.*.example.
  |         b.a.*.*.example.     *.*.example.       no wild card
  |         a.sub.*.example.     sub.*.example.     *.sub.*.example.
  |         b.a.sub.*.example.   sub.*.example.     *.sub.*.example.
  |         a.*.sub.*.example.   *.sub.*.example.   no wild card
  |         *.a.example.         example.           *.example.
  |         a.sub.b.example.     example.           *.example.
  | 
  | Recall that the closest encloser itself cannot be the wild card.

This is a direct contradiction of what was said earlier ...

	It is also important to realize that a wild card domain name can
	be a closest encloser of a query name.

  | Therefore
  | the match for b.a.*.*.example. has no applicable wild card.

the reason is that *.*.example. is the longest match (closest encloser),
as there is no a.*.*.example. (we're assuming, without stating it) and
there is no *.*.*.example which would be the only candidate to be the
wildcard.

  | Finally, if a query name is sub.*.example., any answer available will come
  | from an exact name match for sub.*.example.  No wild card synthesis is
  | performed in this case.

But if the lookup is algorithm is clear, none of this should be needed.
Just make it plain that it is possible for any string to be a domain
name label, including '*', and that those strings can match exactly against
the same string in the QNAME.

To be a wildcard, there's only ever one possibility - a '*' label which is a
sibling of the rightmost label in the QNAME which is not explicitly present
in the DNS tree.

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 11 Sep 2004 04:02:47 +0700

Date:        Fri, 10 Sep 2004 20:50:40 +0200
    From:        Peter Koch <[email-masked]>
    Message-ID:  <[email-masked]>

  | To avoid empty terminals,

There's no reason to do that.    We don't have them in the normal name
tree, but the reason for that is that there's no way to represent them.

Here, the "empty terminal" only appears in the answer to a query, where it
cannot be detected as being terminal, so there's no need to do anything
special to avoid this case, just leave it.

kre

---

From: Peter Koch <[email-masked]>
Date: Fri, 10 Sep 2004 23:42:08 +0200

> node would result in a no error, no data return (neglecting the CNAME 

yes.

> query is for *.*.example.com, then you'd get a direct hit on the 

agreed.

> *.*.example.com "source of synthesis" - not the *.example.com.

Probably not, sorry for the confusion. It's easy if we don't translate '*'
to "all names":

Given a zone example.com

@	SOA ...
	NS  ...
*	TXT " ... "

A QNAME something.example.com is matched by the wildcard. A QNAME *.example.com
is NOT matched by the wildcard but gives a direct match. This does not change
the result, but is important for the next step. A QNAME of a.*.example.com
results in NXDOMAIN. That's because the wildcard matches all names except
those which "exist". "*.example.com" does exist, so the tree is pruned here.
Now that's consistent with Appendix A claiming that b.a.*.*.example is not
covered bey either *.example or *.*.example.
The common assumption that in an otherwise empty zone (see above) the '*'
covers *all* names is just wrong. To really catch all you'd have to add

*.*	TXT " ... "
*.*.*	TXT " ... "
[...]

up to the maximum domain name length (whatever that really is).
All that's already said in terms of closest encloser etc in the draft, but
I guess an example like this with some prose in the appendix won't hurt.
The joke helped.

-Peter

---

From: Peter Koch <[email-masked]>
Date: Sat, 11 Sep 2004 00:14:08 +0200

> special to avoid this case, just leave it.

OK, but then for the sake of clarity the draft should mention this case
explicitly, e.g.:

Empty Terminals

  Empty terminals (leaves) do not exist without wildcards because there is no
  defined way to bring a name into existence without making it or one of
  its descendants (then it would be no longer a terminal) the owner of at
  least one RR. Although there is a NULL RR type specified in RFC 1035,
  its purpose is left open.
  With '*' names in the zone, empty leaves can exist iff the '*' does not
  own any RRSets.
  Given example.org,
	@	SOA ...
		NS  ...
	_.*	NULL {or any other type}
  any name X.example.org with $X != '*' will exist (not result in an
  authoritative name error if queried for) but have no RRs associated with it.

-Peter

PS: Wouldn't that stop me from "enumerating" enum zones ?-)

---

From: Robert Elz <[email-masked]>
Date: Sat, 11 Sep 2004 06:01:14 +0700

Date:        Sat, 11 Sep 2004 00:14:08 +0200
    From:        Peter Koch <[email-masked]>
    Message-ID:  <[email-masked]>

  | OK, but then for the sake of clarity the draft should mention this case
  | explicitly, e.g.:

Perhaps, I'm not sure it is really important enough to anything to matter.
Who really cares after all?   The resolver can't (normally) tell (either
whether the name is terminal, or unless it was an ANY query, whether it is
actually empty).   For DNSSEC purposes (with me being no expert on that stuff)
as I understand it, the proofs need to involve the '*' record explicitly,
as there's no way to actually sign the fabricated RR returned (or not
without on-line keys) - so this is already an odd special case.

  | Empty Terminals

But if this is to be included ...

  |   Although there is a NULL RR type specified in RFC 1035,
  |   its purpose is left open.

That sentence doesn't belong, not that it is wrong, it is simply
irrelevant - you might just as well mention that the HINFO RR type
exists (or any other arbitrary one).   The NULL RR is an RR, just
like any other (however undefined its purpose is...)

kre

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Sep 2004 16:38:55 -0400

>without on-line keys) - so this is already an odd special case.

On the first cut, authenticated denial ("DNSSEC purposes") doesn't 
require proof that there is no "*"/"wild card"/"source of synthesis," 
all that is needed is to prove that there are no matching RRsets to 
the query.

The choice is to 1) customize the reply *message* to the query or 2) 
prove by showing that at each step of the 4.3.2 algorithm that name 
matches fail.  Of course 1 means on-line keys, which is something the 
design of DNSSEC has tried hard to avoid.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Sep 2004 16:26:40 -0400

>or not the '*' might have sub-domains is irrelevant.

I don't see a difference between what you are saying and what I had said.

>Yes, though I'm not real sure I like that term - but I'm not sure what

If you imagine the name space as a two-dimensional field (like the 
Venn diagrams I learned sets from), domains would be nested.  That's 
where the notion of "closest enclosure" comes from.  It's not so 
clear if you think of the stick and node tree diagram.

>Not a wildcard domain, a '*' label.

I think there's an obvious terminology problem.

A wild card domain has become too overloaded I think, that's why I've 
floated "source of synthesis" or "synthesis source."

The closest encloser is the smallest domain surrounding the query 
(search) name.  The source of synthesis would be the domain inside 
the closest encloser that is identified by the label '*' - no matter 
whether there are other names in the "source of synthesis'" domain.

>"... which is not a wildcard, but simply a domain".

Given a query (name, type, class), there is a closest encloser and 
there may be a source of synthesis.  The two can never be the same.

But, what is a closest encloser for one query may be the source of 
synthesis for another query.

(E.g., *.example.com could be the closest encloser for 
foo.*.example.com and it *could* be the source of synthesis for 
foo.example.com.)

>This is a direct contradiction of what was said earlier ...

I don't see that.  "the wild card" = "source of synthesis" is what I 
meant.  Perhaps if the interpretation is "wild card" means 
"*.something" yea.  That's why I think we need to update the 
terminology.

>	be a closest encloser of a query name.

I thought that was what I was saying in Appendix A.

>the same string in the QNAME.

I'm furrowing my brow now because I thought it was clear that the 
algorithm wasn't clear. ;)  Implementations have diverged, as 
evidence...

---

From: Robert Elz <[email-masked]>
Date: Tue, 14 Sep 2004 04:30:38 +0700

Date:        Mon, 13 Sep 2004 16:38:55 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a0602040bbd6bb479d3e3@[192.136.136.102]>

  | >as I understand it, the proofs need to involve the '*' record explicitly,
  | 
  | On the first cut, authenticated denial ("DNSSEC purposes") doesn't 
  | require proof that there is no "*"/"wild card"/"source of synthesis," 

I'll reply to other messages later, but in the above, I wasn't talking
about denial at all, but proof of legitimacy of a RR generated (synthesised)
from a wildcard RR.

That is, I lookup foobar.example. MX, which doesn't exist, but example.
contains *.example. MX 10 whatever.   That means the answer I get is
foobar.example. MX 10 whatever.   That RR needs to be authenticated, but
there cannot be a SIG for it (or not without on-line keys).

Without having attempted to find the actual answer to this, I'd assume that
what is required is the *.example. record itself, its SIG, plus proof that
foobar.example. doesn't exist - all being used as positive proof that the
MX record in the answer section is indeed what it is supposed to be.

kre

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Sep 2004 07:45:04 +1000

> clear if you think of the stick and node tree diagram.

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 14 Sep 2004 08:11:19 +1000

> MX record in the answer section is indeed what it is supposed to be.

	If * has data of the requested type then the RRSIG(type) for *
	+ noqname proof (NSEC + RRSIG(NSEC)).

	If * has data but not of the requested type then NSEC for * +
	RRSIG(NSEC) + noqname proof.

	If * has no data but has children the NSEC that spans * +
	noqname proof.

		e.g. qname d.a.example
		a.example NSEC b.*.a.example	(nodata proof, wildcard exists
						 with nodata)
		b.*.a.example NSEC e.example	(noqname proof, deepest match
						 gives a.example -> *.a.example
						 for wildcard)

---

From: Edward Lewis <[email-masked]>
Date: Mon, 13 Sep 2004 18:13:02 -0400

>	deepest match / longest match

The reason I avoided those terms is that they are too lexically close 
to what's used in routing to mean the same thing, only completely 
differently.  I.e., the most significant bit in an address is on the 
left, the most significant label is on the right.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Ben Laurie <[email-masked]>
Date: Tue, 14 Sep 2004 12:00:48 +0100

> or not the '*' might have sub-domains is irrelevant.

I find this very confusing. Are you saying that if *.xxx is being used 
as a wildcard, that's because the query didn't match any of the 
subdomains, and that's why they're irrelevant?

> to assume that various other domains don't exist (like a.example).

It would probably best to present a complete zone file.

Cheers,

Ben.

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

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: Ben Laurie <[email-masked]>
Date: Tue, 14 Sep 2004 12:15:04 +0100

Edward Lewis wrote:
> Ahh, yeah, what about empty non-terminal '*' nodes in the tree and the 
> role they might play as a source of synthetic records.  Sigh.
> 
> I suppose if you read the very last paragraph of step 3, you would take 
> this to mean that any name matching an empty non-terminal '*' node would 
> result in a no error, no data return (neglecting the CNAME rules).

Wouldn't this mean (since all nonexistent names match the '*') that 
there's a synthesized (or real) closest encloser for all names at that 
level.

In other words, if a.*.example exists, then a query for x.y.example 
would cause y.example to be synthesized as the closest encloser? So, if 
the zone looked like:

a.*.example 	TXT "1"
*.example	TXT "2"

Then a query for x.y.example would yield NXDOMAIN (since y.example is an 
ENT). If a.*.example was not present, the result would be "2".

Cheers,

Ben.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Sep 2004 09:19:42 -0400

At 12:15 +0100 9/14/04, Ben Laurie wrote:

>
>In other words, if a.*.example exists, then a query for x.y.example would
>cause y.example to be synthesized as the closest encloser? So, if the zone
>looked like:
>
>a.*.example 	TXT "1"
>*.example	TXT "2"
>
>Then a query for x.y.example would yield NXDOMAIN (since y.example 
>is an ENT). If a.*.example was not present, the result would be "2".

The closest encloser is never synthesized - it's the closest domain 
in the tree to the name that is sought.

Recall that synthesis only happens when you've found that an exact 
match fails.  The last point of "success" is the closest encloser.

For x.y.example, the closest encloser would be example.com.  As there 
is a *.<closest encloser> (= *.example), that is the source of the 
synthetic records.

The result you have is right, but y.example.com is not the closest 
encloser.  Recall that when performing match rules to find the source 
of synthesis, multiple labels can match a '*'.  (Not true when 
'matching down the tree, label by label.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Sep 2004 09:14:32 +0100

Edward Lewis wrote:
>> Then a query for x.y.example would yield NXDOMAIN (since y.example is 
>> an ENT). If a.*.example was not present, the result would be "2".
> 
> 
> The closest encloser is never synthesized - it's the closest domain in 
> the tree to the name that is sought.
> 
> Recall that synthesis only happens when you've found that an exact match 
> fails.  The last point of "success" is the closest encloser.
> 
> For x.y.example, the closest encloser would be example.com.  As there is 
> a *.<closest encloser> (= *.example), that is the source of the 
> synthetic records.
> 
> encloser.  Recall that when performing match rules to find the source of 
> synthesis, multiple labels can match a '*'.  (Not true when 'matching 
> down the tree, label by label.)

It was more a question than a result, but now I'm puzzled. If the 
closest encloser is not synthesized (which is fine by me, I just thought 
that you were implying it could be), then surely the result is "2" in 
both cases and never NXDOMAIN?

Cheers,

Ben.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 23 Sep 2004 09:38:05 +0100

At 9:14 +0100 9/23/04, Ben Laurie wrote:

>It was more a question than a result, but now I'm puzzled. If the closest
>encloser is not synthesized (which is fine by me, I just thought that you were
>implying it could be), then surely the result is "2" in both cases and never
>NXDOMAIN?

By definition, the closest encloser is never synthesized.  (You don't 
synthesize names, you synthesize records.)  It's like this:

                              .
                            / | \
                          uk com edu
                              |
                           example
                           /  |  \
                         abc def ghi
                             /|\
                            x y z
                             /|
                            * w
                              |
                              *

If the sought name is foo.bar.w.y.def.example.com., then I match down 
the tree (label by label) until I see that at w.y.def.example.com. is 
as far as I can match.

Using Venn diagram notation:

         +--------------------------------------------+
         |  .                                         |
         |  +-------+ +--------------------+ +------+ |
         |  | uk    | | com                | | edu  | |
         |  +-------+ |                    | +------+ |
         |  +---------+                    +--------+ |
         |  | +-----------------------------------+ | |
         |  | | example                           | | |
         |  | | +-----+ +---------------+ +-----+ | | |
         |  | | | abc | | def           | | ghi | | | |
         |  | | +-----+ |               | +-----+ | | |
         |  | |       +-+               +-+       | | |
         |  | |       | +---+ +---+ +---+ |       | | |
         |  | |       | | x | | y | | z | |       | | |
         |  | |       | +---+ |   | +---+ |       | | |
         |  | |       | +-----+   +-----+ |       | | |
         |  | |       | |               | |       | | |
         |  | |       | |  +---+ +---+  | |       | | |
         |  | |       | |  | * | | w |  | |       | | |
         |  | |       | |  +---+ |   |  | |       | | |
         |  | |       | |  +-----+   |  | |       | | |
         |  | |       | |  |         |  | |       | | |
         |  | |       | |  |  +---+  |  | |       | | |
         |  | |       | |  |  | * |  |  | |       | | |
         |  | |       | |  |  +---+  |  | |       | | |
         |  | |       | |  +---------+  | |       | | |
         |  | |       | +---------------+ |       | | |
         |  | |       +-------------------+       | | |
         |  | +-----------------------------------+ | |
         |  +---------------------------------------+ |
         +--------------------------------------------+

(Note this is a domain diagram, not a zone diagram.)

If you look to see what smallest box covers the sought name, you'll 
see it's the box labeled w inside the box(y) inside the box(def) 
inside the box(example) inside the box(com) inside the box(.) (=the 
universe).

That's a better representation of "closest encloser" its the existing 
domain that encloses the sought name "most closely."  I suppose that 
I got the workd closest from drawing lines to the tree, enclosing 
from the idea of the domain Venn diagram.