Subject: wild cards and NS records

From: Edward Lewis <[email-masked]>
Date: Wed, 18 Jun 2003 09:51:13 -0400

The third 'special type' for the wild card is the NS record.

There are a couple of ways to look at this.

One, NS referrals are handled in step b of the algorithm, and wild 
cards are synthesized in step c.  From this observation, NS's at a 
wild card ought not be 'seen' in the search unless the QTYPE matches 
NS.

There's a complication with NS that is not present with CNAME.  When 
asking for the CNAME RR at a name, we get the authoritative answer. 
Swapping NS for CNAME here gives the non-authoritative name as the NS 
in the parent zone isn't the authoritative answer.  Grumble.

Barring NS's from being at a wild card domain name isn't being 
suggested, but strongly discouraged.  NS's have been legal for some 
time (well, since 1034) at wild cards.  It would take a serious 
detrimental impact on the protocol to now bar them - and empirically 
speaking, this isn't happening.

However, discouraging them seems to be a good idea.  Synthesized 
delegations, if not done just right (as in to a name server that 
knows it will synthesizing zones for step 2 of its search algorithm) 
will likely lead to lame delegations.

So, the suggestion for this case is to state:

   o Name servers MAY reject (refuse to load) zones with any wild card domain
     name owning an NS RR set.
   o Name servers MAY refuse to accept updates to add NS RR sets to a wild
     card domain name.

MAY, not MUST. ?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

...as graceful as a blindfolded bull in a china shop...

--
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: Paul Vixie <[email-masked]>
Date: Sun, 22 Jun 2003 06:44:42 +0000

>   When you write "refuse to load" do you mean from disk, or do you
> mean xfer from primary? Or both?

what i meant when i agreed with ed's proposal was: "both."

>   The reason that I ask is that people are often not in control of
> their secondaries (this is often good I argue, as it isolates extent
> of a screw up).

according to dns's definitions, the zone owner has the ultimate
authority, which may include choosing different slave servers if
necessary to enforce zone policy or support the necessary protocol
feature set (like DNAME for example).

>    So, having a secondary updated, and then go lame, often without the
> knowledge of either the primary operator or the secondary operator, is
> really bad.

that's what soa-serial-number monitoring tools are for, methinks.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Jun 2003 10:25:59 -0400

At 14:04 -0400 6/19/03, Michael Richardson wrote:
>   When you write "refuse to load" do you mean from disk, or do you mean xfer
>from primary? Or both?

Both.

>     Edward>    o Name servers MAY refuse to accept updates to add NS RR sets
>     Edward>    to a wild
>     Edward>      card domain name.
>
>   This means dyn-update?

Yep.

I think of updates as degenerate cases of the zone loading process. 
Reading zones from disk and receiving them via 'xfr's are the same to 
me as receiving an update request - all three are preludes to a 
possible zone change.  They differ in the number of records 
'ordinarily' changed, but if you look at the before and after effect 
on the server (eg the serial number), it all looks the same.