Subject: progress on wcard draft

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Oct 2004 11:24:27 -0400

I'm finally started in on an update of the document.  While I'm 
reconstructing it based on discussions over the past month or so, I 
have one more open question:

Can an NS record be synthesized?

E.g., (assuming [Q]CLASS=IN for all)

         example.        SOA    ...
                         NS     ns1.example.
                         NS     ns2.example.
         *               NS     ns3.example.
                         NS     ns4.example.
         ns1             A      192.0.4.1
         ns2             A      192.0.4.2
         ns3             A      192.0.4.3
         ns4             A      192.0.4.4

QNAME=bar.example. QTYPE=NS

Option1
-------

Synthesize "bar.example. NS ns3.example." and "bar.example. NS ns4.example."

Downside: Non-authority is doing the synthesis.  (In making the NS 
records, the zone/server is delegating away the right to make them.)

Option2
-------

No answer - (name error) or (no error and answer count = 0)

Downside: Making an exception to the (virtual?) rule in RFC 1034/sect 
4.3.2/step 3/part c/last paragraph governing matching of types.

Option3
-------

Return code of something like "not implemented"

Downside: it's "giving up" on answering this.

--------

Of the three options, #1 is probably the easiest to defend as there's 
always been a debate on the meaning of "authority" for NS records 
even if RFC 2181 gives parental NS's lower cred than child NS's.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Fri, 01 Oct 2004 23:27:59 +0700

Date:        Fri, 1 Oct 2004 11:24:27 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020406bd8324579eb1@[192.136.136.113]>

  | Can an NS record be synthesized?

For this particular query (only a query with QTYPE=NS), yes.

  | QNAME=bar.example. QTYPE=NS
  | 
  | Option1
  | -------
  | 
  | Synthesize "bar.example. NS ns3.example." and "bar.example. NS ns4.example."

Yes, that's what needs to happen.

  | Of the three options, #1 is probably the easiest to defend as there's 
  | always been a debate on the meaning of "authority" for NS records 
  | even if RFC 2181 gives parental NS's lower cred than child NS's.

But in this case the answer is authoritative, whereas normally an NS
answer returned from the parent would not be.   There's no delegation
here, just NS records being returned in response to an NS query (the
same as if they were any other record type).

This is a particularly weird, but totally harmless and irrelevant side
issue - I agree we should be precise in what happens (though this is another
place where I wouldn't object too much to saying "server dependent" or
"undefined behaviour") but in practice, no-one should ever care, as
no-one is really likely to ever have '* NS' - given that the chances of
anyone ever using '*' as a label in a domain name other than with the
intent of it being a wildcard is close to 0, and '* NS' simply doesn't work
as a wildcard for any useful purpose.

kre

---

From: Edward Lewis <[email-masked]>
Date: Fri, 1 Oct 2004 14:19:57 -0400

>same as if they were any other record type).

Thanks for your patience - I recall you've said this before, last 
week in fact.  I ask the ({WG} - {kre}) "any other comments?"

Are you (Robert) saying that, like the question of "does a name 
exist" is relative to whether the point of view is the server or the 
client?  If the server synthesizes the records, the client will think 
there's a delegation.  Or, when you say "There's no delegation, just 
NS records" do you mean that "in reality, there's no place to go 
anyway" even though the servers tells the client that there is?

>as a wildcard for any useful purpose.

Well, there are a lot of "particularly weird, but totally harmless" 
members of the WG. ;)

---

From: Mark Andrews <[email-masked]>
Date: Sat, 02 Oct 2004 06:48:32 +1000

> as a wildcard for any useful purpose.

	Well I've seen *.123.123.in-addr.arpa used in the wild as an
	attempt to delegate to 0.123.123.in-addr.arpa ...
	255.123.123.in-addr.arpa.  It didn't work very well.
 
--
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: Fri, 1 Oct 2004 17:00:11 -0400

>	255.123.123.in-addr.arpa.  It didn't work very well.

Like I said "particularly weird" folks do run DNS servers.

It's pretty clear that trying to synthesize a zone is dicey, but 
that's not the issue here.

Assuming that a server serves one zone, and that zone has a "* NS" in 
it, should the server return a

      synthesized referral message?

      no error/no data?

      not implemented?

It doesn't matter at this juncture (being that we are defining a 
client-server protocol) whether the first option leaves us with 
something sensible.  If we decide that the parent is authorized to 
synthesize the NS set, it'll be up to the client to deal with this. 
Who knows, maybe I will have a server that is able to conjure up 
zones on the fly?

'Course, it would only really be interesting if "* NS" reacted as a 
referral in step 3b of RFC 1034 s4.3.2.  Perhaps the client has a 
goofy resolver that looks for NS's before determining if it has the 
sight server.

What I'm trying to say is that if we ignore the motivation for the 
query, we might be able to hammer this out.

Is the nonsensical answer worse than saying "no answer, no data" as 
if there were no records to synthesize from?

I know that we question the sanity of anyone who does this - but 
there are folks that do.  What should be written about the situation.

I'm also not demanding to be able to specify this as in 
MUST/SHOULD/etc.  These are engineering documents, not 
specifications, so words of guidance would be sufficient.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Don Stokes <[email-masked]>
Date: Sun, 03 Oct 2004 20:52:46 +1300

>records, the zone/server is delegating away the right to make them.)

To me, 

        example.        SOA    ...
        *               NS     ns3.example.
                        NS     ns4.example.

says "delegate anything below example. that we don't otherwise know
about to ns3 & ns4.example.", which I think is exactly what you're
suggesting.  Any other interpretation is putting different behaviour on
an above-zone-cut NS, even if it does (probably) mean a special case in
the wildcard processing of the server handling the wildcard.  

This is quite at odds with a strict reading of RFC 1034 sec 4.3.2, which
would suggest returning a synthesised answer for an explicit NS query,
but never responding with a delegation response to any other query. 

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

>even if RFC 2181 gives parental NS's lower cred than child NS's.

-- don

---

From: Robert Elz <[email-masked]>
Date: Sat, 02 Oct 2004 22:13:23 +0700

Date:        Fri, 1 Oct 2004 17:00:11 -0400
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020416bd83737b0fba@[192.136.136.113]>

  | Like I said "particularly weird" folks do run DNS servers.

Yes - which is why we need to make it clear what works, and from what
follows, it is clear to me that it is (not yet) clear to you, or perhaps,
somewhere analytically, you know what actually works, but sub-consciously
you're still flirting with ...

  | It's pretty clear that trying to synthesize a zone is dicey,

No, not "dicey", impossible - the DNS lookup algorithm does not allow
it to function.

  | Assuming that a server serves one zone, and that zone has a "* NS" in 
  | it, should the server return a
  | 
  |       synthesized referral message?

Never.

  |       no error/no data?

This depends upon the query and what else is in the zone.

  |       not implemented?

I assume we're talking about opcode==0 ?   How can that possibly be
"not implemented" in any server relevant to what we're discussing?
If the server doesn't implement queries, then what it does with wildcards
cannot possibly be relevant to us.

Note there's no "breakout point" in the lookup algorithm for the server
to give up and say "too hard for me...".

Even if the server is deficient, and doesn't implement wildcards at all
(which is certainly something I can imagine existing), "not implemented"
cannot possibly be a rational answer to any query - the client has just
asked about some particular name, doing a perfectly normal query, it
cannot possibly be expected to assume that a server deciding to send back
"not implemented" to its query happens to mean "well, there's this thing
that looks like a wildcard in the zone, but I don't have the wildcard
algorithm implemented, so I can't give you the correct answer" - that's
absurd.   What the server needs to answer in this case is NXDOMAIN if there
was no wildcard in the zone file, the name doesn't exist, and it needs to
object to '*' labels (and abandon the zone completely) if it finds one,
(a '*' label in the zone that is) as it is unable to process it correctly,
and in that case reply 'server failed".

Note, in this message you didn't say what query we're talking about.

It cannot be the one from the earlier message

as you talk about a referral as one of the possible answers.

The answer to that particular question isn't a referral, it is an
answer.   That is, the synthesised NS records go in the answer section.

In a referral, the NS records (which can never be synthesised) go in
the authority section - the two are totally different things.

(Incidentally, I suspect that for a "normal" NS record, a QTYPE=NS query
asked of the parent server, not also being a server for the delegated zone,
should really result in a referral, rather than an answer, but I suspect
that isn't what happens in most cases, but I am temporarily out of contact
with all nameservers, everywhere, and can't check a few different versions
to verify it - the drawbacks of answering mail from a laptop...)

  | If we decide that the parent is authorized to 
  | synthesize the NS set, it'll be up to the client to deal with this.

Yes, but note this only happens with clients that send NS queries, which
is no normal resolver.

  | Who knows, maybe I will have a server that is able to conjure up 
  | zones on the fly?

Whether you do or not, it is irrelevant, as there's no way in the lookup
algorithm for a '* NS' record to generate dynamically created referrals.

People have from time to time fantasised about this happening, but to
allow it, we'd need to make a major change to the DNS.   It won't, and
cannot, happen according to the algorithms in 1034.

On the other hand, if you do have a server that conjures up zones on the
fly, it can also conjure up explicit NS records to accompany the zone,
and no-one can really tell that the zone was created during the microsecond
between receiving the query, and sending the reply, rather than 5
minutes earlier - wildcard records would be irrelevant to this however.

  | 'Course, it would only really be interesting if "* NS" reacted as a 
  | referral in step 3b of RFC 1034 s4.3.2.

Which it doesn't.   3b only gets used when there has been a name match.
Wildcards only get looked at in 3c, which only happens when there is no
name match.    The two cases are exclusive.

  | Perhaps the client has a  goofy resolver that looks for NS's
  | before determining if it has the sight server.

For that it would first need to figure out NS's for what domain name.
This isn't easy.   Resolvers doing lookups simply do not ask for NS
records -- the most you might expect as an outside possibility, would
be, having been given a referral, the resolver may check the servers
to which it has been referred, to get the auth list of NS records - but
this only happens (can only happen) when there has been a genuine
referral to start with, which implies NS records owned by an explicit
name that exactly matched some trailing part of the QNAME (including
the whole thing of course).

  | What I'm trying to say is that if we ignore the motivation for the 
  | query, we might be able to hammer this out.

Which query are we back to now?   This looks as if you're back to the
QTYPE=NS query, in which case, the answer is "synthesise away".

  | Is the nonsensical answer worse than saying "no answer, no data" as 
  | if there were no records to synthesize from?

Which is "the nonsensical answer" ??   if I have "* NS foo." in my example.
zone file, and someone does "QNAME bar.example. QTYPE=NS", then returning
"bar.example. NS foo." isn't "nonsensical", it is exacly what I told my
server it was required to return.   Telling it that might be stupid on my
part, but the answer itself is 100% correct (and required).

  | I know that we question the sanity of anyone who does this - but 
  | there are folks that do.  What should be written about the situation.

Just tell them that it cannot work as a wildcard delegation, as the * isn't
ever used in referrals.    That is, as in the case Mark mentioned, it simply
does not, and cannot, work the way they were hoping it might work.

We need to make that clear.   Whether we shouldbother confusing the issue by
saying anything at all about QTYPE=NS queries I am less certain.  A good
argument could be made for simply "forgetting" to cover this case, and then
referring anyone who actually tries it back to 1034 when they ask.

And back to one part of an earlier message ...

[email-masked] said in <a0602040ebd834e8a674e@[192.136.136.113]>:
  | Are you (Robert) saying that, like the question of "does a name  exist" is
  | relative to whether the point of view is the server or the  client?

No, of course not.   If there is a wildcard, then all direct sub-domains
exist.   That is, treating letters as representing a single label (of
any length) and dots ('.') as being a divider between labels, and '*'
as itself, then if "x." exists, and "*.x." exists, then "a.x." exists for
every possible a.   (Which is explicitly not saying anything about "b.a.x.").

Now whether "a.x." exists because that name is explicitly configured into
the DNS, or whether it exists because of the wildcard doesn't matter here
(it will matter, I assume, to the decision of what dnssec type RR's need
to be included to prove the name exists) - but it exists.   It might, or
might not, have any resource records attached to it.

[email-masked] said (same message):
  | If the server synthesizes the records, the client will think  there's a
  | delegation.

No, it won't.   Or, perhaps better, "no, it shouldn't".   If it got a
referral, then it could imply there's a delegation.   But from getting
answers in the answer section, even of type NS, all it can conclude is
that there are NS records for the name queried.

Of course, the client in reality isn't doing QTYPE=NS, so this isn't a
very serious question.

[email-masked] said:
  |  Or, when you say "There's no delegation, just  NS records" do you mean that
  | "in reality, there's no place to go  anyway" even though the servers tells
  | the client that there is?

No, I mean there is no delegation (from either the server, or clients
point of view), and getting NS records in the answer section does not
imply referral, or that there is any delegation.

NS records normally only appear in replies in the authority section.
There they are (or can be) a referral, but a wildcard '* NS' record
will never cause them to get put there (other than as an explicit '* NS'
if the referral is literally for the '*' sub-domain itself).

I know this is kind of mind blowing in a way - which is why (as I said
earlier, in this message, and others) that just leaving all this as
undefined, or forgetting to mention it at all, or ... wouldn't bother
me too much, as it isn't something that makes a difference in real
life.

Unless someone is dumb enough to actually have a '*' zone, and delegate it,
no-one is going to have '* NS' records, if this doc does a good enough
job of explaining that they won't do what people are hoping they will
achieve when they attempt it now.   Even if they do have '* NS' records,
nothing actually does QTYPE=NS queries, to hit the corner case.

kre

ps: it is possible that you're getting no other comments, because in
general we agree on what the rules should be, and there is no-one out
there who disagrees, so no-one is bothering to say anything.

---

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

>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

---

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: Mark Andrews <[email-masked]>
Date: Wed, 06 Oct 2004 08:46:23 +1000

> needed here will be done.

	So you would have no objection to a implementation refusing
	to load a zone with wildcard NS records?  Since they can't
	work it is better to report the error immediately.

	Similarly "* DNAME" cannot work.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 05 Oct 2004 23:05:01 +0000

> 	to load a zone with wildcard NS records?

i would.

>       Since they can't work it is better to report the error immediately.

just because they aren't wildcards doesn't mean they can't work.  someone
may want to create a zone called *.VIX.COM some day.  it won't be a wild
card, but a literal label of "*" is nowhere invalidated as a zone name,
nor is a literal domain name of "FOO.*.VIX.COM" invalid (even though it
would not be allowed as a hostname or mailname).

> 	Similarly "* DNAME" cannot work.

documenting the cases that are different, like "*" labels that won't have
wildcard-like effects, is a good idea.  insisting that valid labels and
valid domain names be rejected just because they happen not to have the
usual meaning in some context, is not a good idea.

---

From: Robert Elz <[email-masked]>
Date: Wed, 06 Oct 2004 06:45:20 +0700

Date:        Wed, 06 Oct 2004 08:46:23 +1000
    From:        Mark Andrews <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	So you would have no objection to a implementation refusing
  | 	to load a zone with wildcard NS records?  Since they can't
  | 	work it is better to report the error immediately.

I wouldn't use such an implementation, just like I wouldn't use
one that refuses to load zones containing "peculiar" names - but
others apparently like such things, so whatever...

But they do "work" and work just fine (or should - the definition of
what should be done is clear at least, so they can work in a bug free
implementation).   What they don't do is what (many) people expect
them to do - which is an entirely different thing entirely.

This is much the same as sticking an IPv4 address as the RDATA of an
MX record.   It is perfectly legal - the address looks just like a
domain name, but it doesn't work (except by accident due to buggy
implementations of various things).

A server could look for that, and refuse to load a zone containing
such a record - but shouldn't, as you never know when someone is
going to do that who actually knows what they're doing.  As in

	name IN MX 10 1.2.3.4
	1.2.3.4 IN A 126.0.0.1

which should all work just fine, ignoring implementations with bugs
(here, both DNS & MTA implementations.)

  | 	Similarly "* DNAME" cannot work.

DNAME isn't in 1034, and my memory of just how it is defined, and how
it alters the lookup algorithm isn't that good, so I won't comment on
that one for now.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 05 Oct 2004 20:09:52 -0400

>name match.    The two cases are exclusive.
There's nothing in 3b which says that it only applies to a full match of 
QNAME. 3b gets invoked when "a match would take us out of the 
authoritative data", which is certainly true if one presumes that 
wildcard NSes constitute delegations, and that the answering server 
happens to not be authoritative for the "synthetically" delegated 
subzone. Yes, that's circular, but so is the result if one makes the 
opposite presumption. Whether the lookup algorithm allows or precludes 
(wildcard NSes == delegation) depends entirely on whether one presumes 
at the outset that it does or does not.

My point here is that the lookup algorithm does not _ipso_facto_ 
preclude wildcard NSes from serving as delegations. One has to look to 
the definitions (such as they are) of "delegation" and/or "zone cut" to 
determine that. And as far as I can tell, there's nothing there to say 
definitively that the owner names of delegating NS records have to 
*literally* match the name of the subzone they are delegating. The text 
can just as easily be read to say that anything suffices which is 
*understandable* as delegating one or more subzones, e.g. wildcards, 
potentially. The *intent* of a wildcard NS to delegate is quite clear, 
so I think the burden of proof should be on those wishing to deny that 
intent to show why it is specifically excluded. Section 4.2.2 doesn't 
help, since it says only that the delegation NS RRs and glue RRs 
"necessary to make the delegation effective" are required in the parent 
zone. That's very soft language. Wildcard NSes can "effectively" 
delegate subzones, as long as one does not read the RFC with the 
presumption that they cannot. Similarly, Section 4.2.1 refers to "data 
that describes delegated subzones". Certainly, wildcard NSes can 
"describe" delegated subzones, without actually having owner names which 
are literally, bit-for-bit equivalent to the names of those subzones 
(just as I can "describe" a house without actually using the word 
"house"). The text admits of multiple interpretations.

If the intent is -- do we have rough WG consensus on this? -- to exclude 
wildcard NSes from functioning as delegations, I think the proper way 
would be to go back and tighten the definitions of "delegation" and/or 
"zone cut" as they relate to wildcards, or _vice_versa_. I don't see how 
a dissection of the lookup algorithm yields that result in any 
non-tautological way.

Nor, of course, is the absence of any wildcard delegations from Section 
6 dispositive proof that they are forbidden...

- Kevin

---

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Oct 2004 10:18:31 +1000

> (here, both DNS & MTA implementations.)

	As it should.

	However emitting a warning (with knob to disable) on this
	(and similarly NS rdata) when it contains a IP address (w/
	or w/o the terminating period) is quite reasonable to do
	as is a common mis-configuration.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Oct 2004 10:45:05 +1000

> 6 dispositive proof that they are forbidden...

	Does a "* NS" match only one label?
		(This would usually be the intent.)
	Does a "* NS" match multiple labels?
		(This is what RFC 1034 would imply.)
	Can you sub delegate from a wild card delegation?
		(This would require single label match sematics.)
	How is this going react with anti-cache poisoning code?
		(Especially if you have multiple match.)
	Do you get a consistant namespace from all servers involved
	without adding additional constraints?
		(e.g. child server must have a copy of the parent zone.)
	Does the zone lookup algorithm process the wildcard (child servers)?

	Once you allow "* NS" to wildcard match you have to decide how to
	answer these and other similar questions.

	Mark

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 6 Oct 2004 09:46:04 +0200

On Tue, 05 Oct 2004 20:09:52 -0400
Kevin Darcy <[email-masked]> wrote:

>  wildcard NSes from functioning as delegations,

We don't.

Iff the scripture can be interpreted unambiguosly we do not have to
get consensus on this.  We just need consensus on the fact that
everybody reads the same. You just argued that there are multiple
interpretations possible.

If there is consensus that the text can be interpreted in two ways
than we have to make the choice on what the sensible thing is. (One of
the options is to clarify that both interpretations are possible and
that therefore interoperabillity cannot be expected.)

-- Olaf

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 6 Oct 2004 10:15:17 -0400

>if the parent domain was to be secondaried on standards-compliant

The way I see Step 3 now reading, in summary fashion is:

      a) if there is an exact match with a CNAME, restart the process with
         the new search name.

      b) if you run across a cut point, you issue a referral.

      c) if you find an exact match not a CNAME, you answer from that
         otherwise, you look for the wildcard (set) that equals the QTYPE.

The WG has already moved to amend the above to add to make step c:

      c) if you find an exact match not a CNAME, you answer from that
         otherwise, you look for the wildcard (set) that equals the QTYPE,
         OR you look for a wildcard CNAME and you restart the process with
         the new search name.

What is proposed above would make c:

      c) if you find an exact match not a CNAME, you answer from that
         otherwise, you look for the wildcard (set) that equals the QTYPE,
         OR you look for a wildcard CNAME and you restart the process with
         the new search name OR you look for a wildcard NS (set) and
         synthesize a referral message.

Does that sound like a decent categorization of the proposal?  Does 
that sound reasonable?

BTW - "exact match" in step a means strict DNS label equality, not a 
match by wildcard rule.  This may not be the right interpretation. 
If we take the word "match" in the original part a to mean "by 
wildcard rule" then the three parts could be seen as:

      a) if there is an exact or wildcard match with a CNAME, restart the
         process with the new search name.

      b) if you run across a cut point, you issue a referral.

      c) if you find an exact match not a CNAME, you answer from that
         otherwise, you look for the wildcard (set) that equals the QTYPE,
         OR you look for a wildcard NS (set) and synthesize a referral message.

All this does is move one clause of C to A - which is the 
justification for changing C to "chase" the CNAME.

Then again, b uses "match" too, so maybe we could read the three parts as:

      a) if there is an exact or wildcard match with a CNAME, restart the
         process with the new search name.

      b) if there is an exact or wildcard match with an NS, you issue a
         referral.  (The one exception is that the sought name (SNAME) is
         not the zone's SOA owner name/apex.)

      c) otherwise you answer from the exact or wildcard matching name.

In a way - re-interpreting "match" makes the three parts balance 
better - we no longer have a and b with specific rules and c having 
multiple parts.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 6 Oct 2004 09:47:42 -0400

At 20:09 -0400 10/5/04, Kevin Darcy wrote:

>QNAME. 3b gets invoked when "a match would take us out of the authoritative
>data", which is certainly true if one presumes that wildcard NSes constitute
>delegations, and that the answering server happens to not be authoritative for
>the "synthetically" delegated subzone. Yes, that's circular, but so is the
>result if one makes the opposite presumption. Whether the lookup algorithm
>allows or precludes (wildcard NSes == delegation) depends entirely on whether
>one presumes at the outset that it does or does not.

(Speaking as the document editor:)

You are hitting on the one issue that keeps me up at night, the lack 
of attention paid to what it means to "match."  (As I said, this as 
editor.  As me, I really do sleep quite well.)

>My point here is that the lookup algorithm does not _ipso_facto_ preclude

What does "ipso facto" mean?  The only times I've heard it is a 
comedy when the character wants to sound like a lunatic professor. ;) 
(Not that I am attaching any of that characterization to *anyone* on 
this list.)

>wildcard NSes from serving as delegations. One has to look to the definitions
>(such as they are) of "delegation" and/or "zone cut" to determine that. And as
>far as I can tell, there's nothing there to say definitively that the owner
>names of delegating NS records have to *literally* match the name of the
>subzone they are delegating. The text can just as easily be read to say that
>anything suffices which is *understandable* as delegating one or more
>subzones, e.g. wildcards, potentially. The *intent* of a wildcard NS to
>delegate is quite clear, so I think the burden of proof should be on those
>wishing to deny that intent to show why it is specifically excluded. Section
>4.2.2 doesn't help, since it says only that the delegation NS RRs and glue RRs
>"necessary to make the delegation effective" are required in the parent zone.
>That's very soft language. Wildcard NSes can "effectively" delegate subzones,
>as long as one does not read the RFC with the presumption that they cannot.
>Similarly, Section 4.2.1 refers to "data that describes delegated subzones".
>Certainly, wildcard NSes can "describe" delegated subzones, without actually
>having owner names which are literally, bit-for-bit equivalent to the names of
>those subzones (just as I can "describe" a house without actually using the
>word "house"). The text admits of multiple interpretations.

This is where the word "match" becomes the problem.  As in "c. If at 
some label, a match is impossible (i.e., the corresponding label does 
not exist)" - I have taken a match to be 1) case-folded bitwise 
sameness (equality).  Also, 2) the matches are done on what is in the 
tree, and the synthesized names are not.

'Course, that has been my interpretation.  I guess I didn't figure it 
enough of an issue to raise the meaning of "match" as an issue.

In the next version of the doc I plan to include an ASCII-art 
rendition of a small example zone to illustrate the tree concept. 
Looking at it that way gives the strong impression that "if at some 
label, a match" refers to just the nodes as they sit in the tree, not 
as if they might match.

OTOH, there is "is impossible" which opens the question of what are 
the possibilities for matching.

And, OTOF (foot) - I'm quoting from step 3 part c - the exact 
match/wildcard step and not from step 3 part b - which is where the 
question of zone cut (or delegation point) arises.

>wildcard NSes from functioning as delegations, I think the proper way would be
>to go back and tighten the definitions of "delegation" and/or "zone cut" as
>they relate to wildcards, or _vice_versa_. I don't see how a dissection of the
>lookup algorithm yields that result in any non-tautological way.

I'm not the chair, but as editor, I don't think I have a clear enough 
consensus to have faith that the document is "done."  I hope to have 
a draft out last week, err, this week, and will have something by 
next week (IETF deadline) - just to have a draft active for the 
meeting in November.

>Nor, of course, is the absence of any wildcard delegations from Section 6
>dispositive proof that they are forbidden...

Well, if it did, the wcard clarification document would be a lot shorter. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Robert Elz <[email-masked]>
Date: Wed, 06 Oct 2004 23:41:16 +0700

Date:        Tue, 05 Oct 2004 20:09:52 -0400
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  | There's nothing in 3b which says that it only applies to a full match of 
  | QNAME.

I didn't say "full match of a QNAME" I said "name match", and perhaps
should have instead said "label match".

  | 3b gets invoked when "a match would take us out of the 
  | authoritative data", which is certainly true if one presumes that 
  | wildcard NSes constitute delegations,

No, it isn't - wildcards are not matches - they're *never* matches.
(a '*' label might be a match to a '*' label in a query, but then it
isn't a wildcard - or isn't acting as one for this query).

Just look at 3c, it clearly says, if there is no match, then look for
a '*' label - it doesn't say that makes a match, instead, it says to
synthesise records (if there's an appropriate RR type at '*'), stick them
in the answer section, and goto 6 (ie: get out of here).   That is, once
you have used the wildcard, the algorithm is quite explicit, you're done,
and there's no way to add a referral to the reply ('6' actually is where
additional info records get added, but they affect nothing).

This really is very clear.

  | Whether the lookup algorithm allows or precludes 
  | (wildcard NSes == delegation) depends entirely on whether one presumes 
  | at the outset that it does or does not.

No, it doesn't.   I know that, because I presumed at the outset that it
did (allow them), having listened to people go on and on for years about
wildcard delegations, and zone synthesis, and stuff, as if they were
expected to happen (and just no-one had bothered to implement them, and
perhaps they were a crazy idea anyway - the big question always seemed to
be how we would get them onto he secondary servers).

Then I actually read the text in 1034 carefully.   That changed my
mind.  There is definitely no way to synthesise zones (using the wildcard
algorithm in 1034 - servers could do it other ways, or even by
perverting wildcards).

  | My point here is that the lookup algorithm does not _ipso_facto_ 
  | preclude wildcard NSes from serving as delegations.

Maybe I'm a lunatic professor, but I know what ipso facto is, and you're
wrong, the lookup algorithm does preclude them.

Where you go wrong is in treating wildcards as if they're matching
something.   They don't, and never did.   It's a great pity that '*'
was used as the wildcard character, given its use in regular expressions,
and "glob" patterns, but we can't do anything about that now.

  | The *intent* of a wildcard NS to delegate is quite clear,

You mean the intent of people who use the things - yes, it probably is,
in almost every case.    The intent of the standard in '* NS' is just
to delegate the '*' name (literally) however - and that really probably
only because it is a legal name itself, as well as being a wildcard,
just as is everything else (between 1 & 63 octets).

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 06 Oct 2004 23:43:04 +0700

Date:        Wed, 06 Oct 2004 10:18:31 +1000
    From:        Mark Andrews <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	However emitting a warning (with knob to disable) on this
  | 	(and similarly NS rdata) when it contains a IP address (w/
  | 	or w/o the terminating period) is quite reasonable to do
  | 	as is a common mis-configuration.

Yes, as I said - implementations can do whatever hand holding for the
"average" user they like - but if they're to be generally used, they also
need to be able to handle all the weird cases.

Most certainly any such knob needs to affect only locally loaded zones
(primary server stuff) - not AXFR transferred data.

kre

---

From: Paul Vixie <[email-masked]>
Date: Wed, 06 Oct 2004 17:28:42 +0000

> > If the intent is -- do we have rough WG consensus on this? -- to
> > exclude wildcard NSes from functioning as delegations,
> 
> We don't.
> 

i do not agree with kevin's multiple-interpretation assertion.  the
document is unambiguous as written, and the best we can do is clarify
that wildcard NS's are not supported by the present specifications.

> that therefore interoperabillity cannot be expected.)

ouch.  i hope not.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 6 Oct 2004 13:50:52 -0400

>(primary server stuff) - not AXFR transferred data.

Although I did at one time mention logging an event, which I did to 
provide an example of courses of actions, I don't think any 
statements on logging belong in a DNS "specification" document.

Logging is good, logging is admirable, but as far as DNS is 
concerned, it is not an interoperability issue.  (Perhaps to SYSLOG 
WG or some-such.)

Unless there's sentiment otherwise, I plan to omit any discussion of 
logging from the wcard clarification document.  But - discuss away 
anyhow.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 06 Oct 2004 18:40:06 -0400

Paul Vixie wrote:

>document is unambiguous as written, and the best we ca
>
I withdraw my assertion that wildcard NSes could be reasonably 
interpreted under RFC 1034 to be capable of functioning as delegations. 
Upon re-reading Section 4.3.3, I notice that wildcards "should be in the 
authoritative data of the zone", so that, in my opinion, is dispositive: 
delegating NS records are not in the authoritative data of the zone they 
delegate, therefore wildcard NSes cannot (legally) have a delegating 
function. Sorry for the confusion.

I still maintain, however, that
a) It is 4.3.3 that bars this, not the lookup algorithm specification 
(4.3.2), and
b) there is too much disharmony/disjointedness between the "structural" 
description of "wildcards" in 4.3.3 and the "functional" description of 
how asterisk-labels work in the context of the lookup algorithm (4.3.2). 
Hopefully the wcard-clarify draft can improve on this.

                     - Kevin

---

From: Don Stokes <[email-masked]>
Date: Thu, 07 Oct 2004 14:53:31 +1300

>Does that sound like a decent categorization of the proposal?  Does 

I think so.  Note that c is pretty heavily overloaded -- it actually
describes quite a number of possible outcomes.  Perhaps it should be
subdivided into:

i   * does not exist
ii  * CNAME exists
iii * NS exists
iv  * <some other type> exists

>wildcard rule" then the three parts could be seen as:

My interpretation of sec 4.3.2 is that "match" always means by strict
equality.  Wildcard processing is described explicitly as looking for a
"*" label *after* a "match" has failed -- I think that makes it pretty
clear that a "match" does not include a wildcard match.

Therefore I think it's a pretty big stretch to assume that "match"
could imply wildcard matches as well as strict ones.

Using the phrase "exact match" would help avoid incorrect
interpretations, but either way, I don't see any ambiguity in the
existing text.

>better - we no longer have a and b with specific rules and c having 

I think that will get ugly.  What constitutes a "wildcard match" is well
defined in 3c, and trying to redefine the word "match" gets messy,
especially since 3a divides the matching process up into matching the
QNAME, and then matching the QTYPE.  3c deals with no QNAME match, but
does look for a QTYPE match, while 3b matches the node only. 

Thus I think simply adding the case for * NS as a referral in 3c will be
much tidier.

-- don