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: Wed, 18 Jun 2003 16:24:51 +0000

>    o Name servers MAY refuse to accept updates to add NS RR sets to a wild

i'd like SHOULD.

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 18 Jun 2003 14:13:01 -0400

I agree with Paul on this.  It should be a SHOULD or a MUST and not MAY.
MAY sounds too non-commital and someone who thinks they have a good reason
to use *.somedomain  IN NS  would be tempted to use it.

Scott

---

From: Peter Koch <[email-masked]>
Date: Wed, 18 Jun 2003 20:26:38 +0200

> to use *.somedomain  IN NS  would be tempted to use it.

This decision should not be left to the implementation because a valid zone
should be predictably served in a mixed implementation master/slave
environment. So, a MAY would add confusion as would a SHOULD in my opinion.
A MUST wouldn't hurt. Any "really special" application requiring wildcard
NS RRs would work on a case by case base anyway, as do those load balancing
or route optimizing "DNS servers", which know nothing but A RRs today.

-Peter

---

From: Matt Larson <[email-masked]>
Date: Wed, 18 Jun 2003 15:06:21 -0400

> wild card ought not be 'seen' in the search unless the QTYPE matches 

That is my interpretation of the algorithm.

> in the parent zone isn't the authoritative answer.  Grumble.

I'm sorry, but I'm having trouble parsing the last sentence of the
paragraph and relating the whole paragraph to the topic at hand.

> time (well, since 1034) at wild cards.

I'm not sure what you're implying.  I agree that "*" for an owner name
of an NS RRset is legal, but I disagree that an implementation
following the algorithm in section 4.3.2 of RFC 1034 would support
wildcard NS records in any useful way.

The wildcard secret sauce is in the final paragraph of step 3(c).
Here's all of 3(c) for completeness:

         c. If at some label, a match is impossible (i.e., the
            corresponding label does not exist), look to see if a
            the "*" label exists.
 
            If the "*" label does not exist, check whether the name
            we are looking for is the original QNAME in the query
            or a name we have followed due to a CNAME.  If the name
            is original, set an authoritative name error in the
            response and exit.  Otherwise just exit.
 
            If the "*" label does exist, match RRs at that node
            against QTYPE.  If any match, copy them into the answer
            section, but set the owner of the RR to be QNAME, and
            not the node with the "*" label.  Go to step 6.

Clearly, wildcard synthesis only occurs when the QTYPE of the query
matches the type of the wildcard.  In other words, a wildcard
synthesis resulting from a wildcard NS RRset would only apply when
QTYPE is NS.  This algorithm cannot generate a valid referral when
QTYPE is not NS.

> It would take a serious 
> detrimental impact on the protocol to now bar them

I don't know that I agree with that, but I don't have enough data
about usage (or lack thereof) in the wild to back up my skepticism.

> will likely lead to lame delegations.

Synthesizing delegations is one thing, but that can't happen as a
result of the algorithm in section 4.3.2.  The same is true of CNAME
processing--that happens before wildcard substitution in the algorithm

I believe we either need to clarify the existing algorithm and point
out that it does not allow wildcard CNAME and NS records in the manner
they are sometimes implemented, or we need to change the algorithm to
allow them.  I don't care either way, but the current discrepancy
between standard and practice is untenable.  I'm afraid in particular
that ambiguity surrounding wildcard CNAME has repercussions for DNSSEC
validation.

>   o Name servers MAY refuse to accept updates to add NS RR sets to a wild

I don't think this is the way to go.  I believe this is your chain of
logic:

1. Wildcard NS records can be used to synthesize delegations.
2. Synthesized delegations are fraught with danger (i.e., lame
delegations) and should be avoided by the unwary.
3. Let us discourage them with the language I propose.

My contention is that #1 is incorrect, so better alternatives would be
to either 1) explain that wildcard NS records only work when QTYPE=NS
(and a similar clarification/explanation for CNAME) or 2) change the
algorithm to support them in the way one intuitively expects them to
work.

Matt

---

From: Edward Lewis <[email-masked]>
Date: Wed, 18 Jun 2003 15:33:32 -0400

At 15:06 -0400 6/18/03, Matt Larson wrote:
Clarifying...

>paragraph and relating the whole paragraph to the topic at hand.

Assuming I'm looking at example.com:

labela   CNAME labelc
labelb   NS    labeld

A query for labela.example.com, CNAME, IN yields an authoritative 
answer, "labela CNAME labelc".

A query for labelb.example.com, NS, IN yields a (non-auth) referral 
to labeld.example.com.

I was pointing this out because, in step c, once I match a wild card 
name, the proper response, according to the text as written, is to 
just return the CNAME for  QTYPE=CNAME - but extending this to just 
returning the NS for QTYPE=NS isn't a straight forward leap.  (And 
for QTYPE=any, axfr, ixfr.)

I was trying to point out that solving for CNAME in this instance 
doesn't help solve for NS...;(  Using the CNAMe as an analog for NS 
doesn't help.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: [email-masked]
Date: Thu, 19 Jun 2003 10:18:09 +1000

> algorithm to support them in the way one intuitively expects them to

	To make them work wild card NS record would hace to occult
	all other non DNSSEC types.  Also "*" would have to be a
	single label match.  You could have glue address records
	at the label but not below it.
 
	My preferred solution to wildcard NS records is a MUST NOT
	appear.

	The only place where I have seen them attempted is in the
	IN-ADDR.ARPA tree.  Worst case senario is 256 delegations
	under IN-ADDR.ARPA.  For IP6.ARPA it is 16.

	Named has $GENERATE to cope with this.  I havn't looked to
	see what the other vendors have.

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 19 Jun 2003 14:04:56 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:
    Edward> So, the suggestion for this case is to state:

    Edward>    o Name servers MAY reject (refuse to load) zones with any wild
    Edward>    card domain 
    Edward>      name owning an NS RR set. 

  When you write "refuse to load" do you mean from disk, or do you mean xfer
from primary? Or 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). 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.

    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?

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

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

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

>   When you write "refuse to load" do you mean from disk, or do you mean xfer

Both.

>     Edward>      card domain name.

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.

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 24 Jun 2003 14:10:24 -0700 (PDT)

I see no reason to specify that servers SHOULD or even MUST reject a
zone merely because it contains a wildcard NS record.  It's not like
such records cause any harm just by existing - the issue is just that
users are confused over what they do (or more precisely, what they
don't do, namely create multiple delegations).  Documenting the issue
and encouraging servers to issue warnings would be a better approach.
-- 
Andreas Gustafsson, [email-masked]