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

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

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

---

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: 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: Edward Lewis <[email-masked]>
Date: Wed, 6 Oct 2004 10:15:17 -0400

At 13:15 +1300 10/6/04, Don Stokes wrote:
>
>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.

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: Kevin Darcy <[email-masked]>
Date: Wed, 06 Oct 2004 18:40:06 -0400

Paul Vixie wrote:

>>>If the intent is -- do we have rough WG consensus on this? -- to
>>>exclude 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.
>>    
>>
>
>i do not agree with kevin's multiple-interpretation assertion.  the
>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