Subject: Re: progress on wcard draft

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

At 6:48 +1000 10/2/04, Mark Andrews wrote:

>	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.

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

"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: 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

	QNAME=bar.example. QTYPE=NS

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: 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: 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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 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