Subject: Re: progress on wcard draft

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

--
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: 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. ;)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

---

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: Don Stokes <[email-masked]>
Date: Sun, 03 Oct 2004 20:52:46 +1300

Edward Lewis <[email-masked]> wrote:
>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.)

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.

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

-- don