Subject: Re: progress on wcard draft

From: Edward Lewis <[email-masked]>
Date: Tue, 5 Oct 2004 17:33:21 -0400

Looking at Don's (quoted below) and Robert's last responses:

>In effect, this is reversing steps 3b and 3c, making the wildcard
>decision before the zone cut decision.

First, the caution has gone out that the algorithm in 4.3.2 isn't 
pseudocode, so the ordering isn't important.  E.g., 3b and 3c aren't 
meant to be in any specific order, so there's no need to "reverse the 
order."

But, there's something more significant from that comment.

Once we've arrives at step 3, only one of part a, part b and part c 
can be executed.

So, let's say we have a '* NS' and the query is for NS and an owner 
name that results in wildcard processing.

In this instance, the fact that we are synthesizing a cut point is 
immaterial because we've already committed to part c.  I.e., as we've 
said before, we don't jump from one part to another mid-processing.

Ergo, I think we can explain ourselves out of having a special case 
here.  That is, once the parent synthesizes something, it has 
determined it is authoritative for whatever it's about to synthesize.

I don't think this (pretty much useless) case matters, but at least 
we can explain it with making a special (and pretty much useless) 
case out of it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Robert Elz <[email-masked]>
Date: Wed, 06 Oct 2004 05:33:48 +0700

Date:        Tue, 5 Oct 2004 17:33:21 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020418bd88c2194f5c@[192.136.136.113]>

  | I don't think this (pretty much useless) case matters, but at least 
  | we can explain it with making a special (and pretty much useless) 
  | case out of it.

Yes.

Or in other words, 1034 is already explicit on all of this, though it
does take careful reading.

We should really be spending more effort on killing the myths
than on worrying about this very unusual situation.   That is, whatever
an implementation does in this case, isn't really going to make a difference
that anyone (anyone sane Bill... - sorry for the aside, response to a
private message) will ever even notice, much less care about.

Make it plain that wildcards are not pattern matching on queries, and
that it is impossible to wildcard delegate, and most of what is really
needed here will be done.

kre

---

From: Don Stokes <[email-masked]>
Date: Wed, 06 Oct 2004 13:15:45 +1300

>said before, we don't jump from one part to another mid-processing.

Sure.  My reading of 1034 sec 4.3.2 is that you can't use a wildcard NS
to synthesise a referral, so if referral synthesis is codified, we need 
to realise that this would supersede the algorithm specified in 1034.

>we can explain it with making a special (and pretty much useless) 

Before we abandon synthesised referrals completely, consider this
possible configuration.  I have two sets of name servers, one set, call
them A & B, as the delegated name servers for a domain.  I have two
more, C & D, for "customer" domains.  A & B have:

	$ORIGIN foo.example.
	@	SOA ...
		NS	a
		NS	b
		A	10.0.0.99
	a	A	10.0.0.1
	b	A	172.16.0.1
	c	A	10.0.0.3
	d	A	10.0.0.4
	mail	MX	10.0.0.99
	www	A	10.0.0.99
	*	NS	c
		NS	d

C & D carry customer domains within foo.example.  They are not BIND
servers (I can think of a way to do this using BIND, but it's messy
and would confuse the issue), but respond with authoritative,
synthesised data for <whatever>.foo.example, e.g. given queries for
bar.foo.example, they would return:

	$ORIGIN bar.foo.example.
	@	SOA ...
		NS	c.foo.example.
			d.foo.example.
		MX	0 mail.foo.example.
		A	10.0.0.101
	www	A	10.0.0.101

plus -- and this is important --  any other records specific to the
customer, e.g. 

	myhost	A 	192.168.1.2

Now, sure, this could all be done using normal referrals, but to do so,
A & B need to have information about the customer domains on C & D. 
Simply referring all queries for <whatever>.foo.example to C & D allows
the sub-zones to be carried by C & D, while keeping parent data on A &
B. 

For this to work, A & B really have to synthesise referrals for the * NS
records.  If the word is that wildcard NS records don't provide wildcard
referrals, then another way would have to be found to do this, at least
if the parent domain was to be secondaried on standards-compliant
platforms.

-- don