Subject: * NS

From: Edward Lewis <[email-masked]>
Date: Mon, 20 Sep 2004 15:34:35 +0100

Since midday yesterday a couple of RIPE attendees have talked about 
the "* NS" issue.

A couple of things seem clearer now (at least to me), but still we 
have a conundrum.

The current thinking is that there should be no restriction on a zone 
with a "* NS" because a domain name beginning with a "*" isn't always 
being used as a source of synthetic records.

E.g.,

         example.com.     SOA   (SOA rdata)
                          NS    (NS rdata)
                          NS    (NS rdata)
         *.foo            TXT   (TXT rdata)
         www              A     (A rdata)
         *                NS    (NS rdata)
                          NS    (NS rdata)

I'm going to use a convention for the purpose of this message of:

    Q(*, NS) is the same as (QNAME=*; QCLASS=IN; QTYPE=NS)
    ANSWER(#): Answer section and answer count
    AUTHORITY(#): Authority section w/count

Query: Q(*.example.com, NS) returns:

    ANSWER(2): *.example.com. IN NS (x2)

    This is a case of (RFC 1034, 4.3.2) Step 3.a (exact name match) being
    invoked.

Query: Q(*.example.com, A) returns:

    This depends.  If the server has loaded a zone named *.example.com. then
    we wouldn't be looking at this zone.

    Assuming there is no loaded zone for *.example.com., then the answer comes
    from Step 3.b (cut point it hit).  The answer would be:

    AUTHORITY(2): *.example.com. IN NS (x2)

QUERY Q(www.example.com, TXT) returns:

    ANSWER(0)

    This is from 3.a - exact name match, but no matching RR set.

QUERY Q(www.*.foo.example.com, A) returns:

    Name Error

    This is from 3.c.  A match failed at the label * of *.foo.example.com.
    There is no * label below this (*.*.foo.example.com) - setting aside the
    "anydomain should not contain *" text - so there is no name match, hence
    the name error return.

QUERY Q(smtp.example.com, A) returns:

     Seeing no match for smtp.example.com as Step 3.a, the response will
     have to be from 3.b or 3.c.  It looks like 3.b is not the right Step
     either as *.example.com is not in the path to smtp.example.com.  So
     it looks like 3.c.

     Looking into 3.c, we are now trying to match types, or "chase" a CNAME
     (as the other part of the draft proposes).  There are no A records, so
     it looks like the answer is either:

     ANSWER(0)

     or:

     AUTHORITY(2): smtp.example.com IN NS (x2)

     It comes down to the meaning of the word "match" in the last paragraph
     of 3.c.  If we are deciding between 3.a or 3.b, meaning that the query
     name is a cut point, the presence of the NS occludes the A.  Does that
     constitute a "match?"

     I've also been given a third choice - not bother to answer the question.
     IOW - leave it unspecified.  I'm assuming that this isn't a generally
     held position, but I ought to check.

     Oh, and there's another problem, the "conundrum." Is the synthesis of
     the (smtp.example.com IN NS) set legal?  To separate the issue, I'll use
     another query.

QUERY Q(smtp.example.com, NS) returns:

     In this case, we are in Step 3.c, with the NS matching exactly.

     The problem is:

     Assuming the child (and not the parent) is authoritative for the NS set,
     is it legal for the parent to synthesize the child NS set?

     The irony here is, by following established rules in generating the NS
     set for the answer (here it is the answer and not the referral because
     we've fallen into step c) the parent has delegated away the authority
     for the name.  The parent is no longer allowed to answer for this. In
     hindsight, the answer ought to have come from 3.b - but we didn't know
     to go there until we stepped halfway through 3.c.

(Is it the jet lag, or is this stuff really muddy?)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Tue, 21 Sep 2004 04:23:33 +0700

Date:        Mon, 20 Sep 2004 15:34:35 +0100
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <a06020403bd7489f8c2ff@[193.0.8.231]>

  | A couple of things seem clearer now (at least to me), but still we 
  | have a conundrum.

I doubt it is quite that bad.

  | QUERY Q(smtp.example.com, A) returns:
  | 
  |      Seeing no match for smtp.example.com as Step 3.a, the response will
  |      have to be from 3.b or 3.c.  It looks like 3.b is not the right Step
  |      either as *.example.com is not in the path to smtp.example.com.  So
  |      it looks like 3.c.
  | 
  |      Looking into 3.c, we are now trying to match types, or "chase" a CNAME
  |      (as the other part of the draft proposes).  There are no A records, so
  |      it looks like the answer is either:
  | 
  |      ANSWER(0)
  | 
  |      or:
  | 
  |      AUTHORITY(2): smtp.example.com IN NS (x2)

It is clearly ANSWER(0).

  |      It comes down to the meaning of the word "match" in the last paragraph
  |      of 3.c.  If we are deciding between 3.a or 3.b, meaning that the query
  |      name is a cut point, the presence of the NS occludes the A.  Does that
  |      constitute a "match?"

What A?   I'm not sure what you're thinking of here?

The algorithm is simple.   Look for an exact name match ("match" means
identical labels modulo case independence).   Not found - done with
4.3.2 (3a) - and 4.3.2 (3b) cannot apply either.   Then look for a wildcard
record (ie: label '*') - that exists, but no RR's of the appropriate type.
Hence copy nothing to the answer section.  "Go to step 6" (ie: we're done).

In case you doubt the definition of "match" (for names) - just look at 4.3.2
(3c) - we only start looking for '*' labels when a match is "impossible" - that
is when there is no match.   If you start imagining that the presence of a '*'
label causes a name match, then this whole section would be absurd.
The '*' label does not "match" the QNAME, rather it causes RR's to be
(able to be) synthesised that have a label which does match the QNAME
(which don't have to be tested for that purpose, as they're constructed
to satisfy it).

  |      I've also been given a third choice - nt bother to answer the question.
  |      IOW - leave it unspecified.  I'm assuming that this isn't a generally
  |      held position, but I ought to check.

No, this one is clear, and simple.

  |      Oh, and there's another problem, the "conundrum." Is the synthesis of
  |      the (smtp.example.com IN NS) set legal?

This one is a very hard case to be sure about.   Fortunately, for any
practical purpose, it doesn't really matter.

  | QUERY Q(smtp.example.com, NS) returns:
  | 
  |      In this case, we are in Step 3.c, with the NS matching exactly.

Yes.

  |      The problem is:
  | 
  |      Assuming the child (and not the parent) is authoritative for the NS
  |      set, is it legal for the parent to synthesize the child NS set?

Yes, that's where things get hairy.   The "delegations cancel wildcards"
rule suggests that NODATA (ANSWER(0)) would be appropriate, yet, the
algorithm suggests that ANSWER(2) (the 2 NS records) would be correct.

This is the one I'd just leave undefined.

Fortunately (leaving aside whatever implications this may have for
dnssec) this makes absolutely no difference to anything that matters,
as absolutely nothing (real) does QTYPE=NS queries.   That is, the set
of people reading this message (subscribers to namedroppers, etc) and
a few more like us are the only entities that would ever issue such a
query - it is basically useless for applications.
 
  |      The irony here is, by following established rules in generating the NS
  |      set for the answer (here it is the answer and not the referral because
  |      we've fallen into step c) the parent has delegated away the authority
  |      for the name.  The parent is no longer allowed to answer for this. In
  |      hindsight, the answer ought to have come from 3.b

No, it shouldn't - 3b only applies when we have an exact match.  There's
no "smtp" in the zone file, hence that one cannot possibly occur.

Personally I lean towards generating AA NS records that satisfy the
query - that is, there's no delegation here, the name "smtp.example.com"
hasn't been delegated anywhere, and hence the example.com zone is still
authoritative for the data - and then the '* NS' records cause synthesis
of the answer section records (which are from the example.com zone, and
hence AA answers).    Of course this puts us in the novel position of
having NS records with no zone cut.

There's no possible practical use for this nonsense however, so it isn't
in the least bit important.

kre

kre

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Sep 2004 09:38:47 +0100

>   | QUERY Q(smtp.example.com, A) returns:
...
>What A?   I'm not sure what you're thinking of here?

The A in the query, well, the occlusion would be the A in the subzone named
smtp.example.com that matches the type queried.

>(which don't have to be tested for that purpose, as they're constructed

My issue isn't "match" for names, but "match" for types.  1034 is 
inconsistent with terms - QTYPE ANY, or QTYPE *, is different that * 
domain names.  (A cache interprets QTYPE ANY, it doesn't do any 
synthesis based on * domain names.)  That's why I think it's unclear 
what is meant by "match" for types.

I favor the ANSWER(0) choice myself, but I want to hear what the 
group thinks.  There is another place in the text that supports the 
treatment of NS as a match for a queried A - if there's a name match 
at a cut point.  (This is just to support why the AUTHORITY(2) answer 
option is a candidate.)

>query - it is basically useless for applications.

Now that you've raised the dnssec word ;)  DNSSEC makes this yuckier. 
I've been trying to avoid the complications until we clarify the base 
specification.

In a nutshell, the problem is "* DS" - unlike the NS set, the DS is 
authoritative at the parent.  So, if synthesizing an NS set is 
illegal because the synthesizing zone is not authoritative, 
synthesizing a DS is legal.  Now we can have a DS set without an NS 
set...ugh.

>having NS records with no zone cut.

I have in my mind a Road Runner - Wile E. Coyote cartoon and the ACME 
black hole.  When the hole is placed on a road, the Road Runner runs 
over it like it's just a black mat.  When the Coyote jumps on it, he 
falls into the ersatz hole.

>in the least bit important.

It reminds me of Saturday morning cartoons.  That's a good thing. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer