[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Q-10: Reaction to "Silly" NXT's

What's below is wrong, close but wrong...I realized this changing planes in Atlanta. I forgot to account for the substitution of the last SNAME for the wild card in a synthesized record.

What's needed is to first make the list of SNAMEs and then, if there is a wild card synthesized name, add the wild card name to the end of the SNAME list.

Then, without a wild card synthesized record in the answer, then the only NXT will:

1) span the TNAME if NXDOMAIN and AA
2) be owned by the TNAME with NOERROR and AA to say the data is missing
3) be owned by the TNAME with NOERROR and AA=0 to say that the DS RR is absent
(also - NS present, DS not present, ...)

If there's a synthesized record, then there may be two (or one or zero) NXT's:
1) one nxt will span the penultimate name in SNAME plus wild card list
2) the other NXT will
2a) span the wild card domain name
2b) be synthesized from the wild card NXT
2c) be the ugly case - stating that a wild card owned delegation is unsecure.

It's possible that the above can be done in just one NXT.

Perhaps this isn't thought through well enough, maybe I need to talk through this live with someone. The upshot - I'd like to state the rules about how a resolver should interpret an NXT occurring in a message.

At 19:24 -0700 6/6/03, Edward Lewis wrote:
I have to admit that my head hurts from recent travels and this thread.
Here is how I would summarize this, not to squash other's input, but to
allow others to check against what I am thinking.

Look at the header: is the response code NXDOMAIN or NOERROR? Is the AA
bit set?

Look at the answer section: this is a bit more convoluted

1) Find the sequence of SNAME (search names) appearing in the answer
section. SNAME #1 ought to be QNAME. If there are multiple SNAMEs,
then the transition from SNAME #i to SNAME #i+1 has to occur via CNAMEs
or DNAMEs. In any case, we need to identify SNAME#n - which is the
last name searched. Let's call it TNAME. (QNAME and SNAME appear in
RFC 1034. Olafur and I agreed on TNAME.)

It's common that QNAME = TNAME.

If the QNAME != TNAME, there is a penultimate SNAME, SNAME#n-1, that is
significant if there are wild card synthesized answers.

If the answer section is empty, there is no penultimate SNAME, QNAME =
SNAME#1 = TNAME.

Note that the owner of any DNAME is not a member of the SNAME list, but
the "on-the-fly CNAME"'s owner is. (A knowledgeable resolver will
discard the CNAME and regenerate it on its own as it that is needed it
verify the on-the-fly one anyway, a check is then unnecessary.) The
DNAME is only needed to validate the on-the-fly CNAME.

2) Determine if TNAME owns data requested and if the data is the result
of a wild card synthesis.

3) Any NXT found in the answer section has no special meaning to DNS.

Look at the authority section:

1) There will NEVER, NEVER, NEVER be more than two NXT's that are
appropriate here.

2) If no wild card synthesized records appear in the answer section, there will NEVER be more than one NXT that is appropriate.

3) If there is a wild card synthesized record, then one NXT MUST span
the penultimate SNAME in the list. I.e., the NXT's owner name <
SNAME#n-1 < NXT's RDATA next name.

4) The (other) NXT that appears MUST be one of three:

4a) The NXT spans the TNAME - and NXDOMAIN is the return code and an
AA bit of 1.

4b) The owner of the NXT is equal to the TNAME and demonstrates that
QTYPE is absent with a return code of NOERROR and an AA bit of 1. (And
that there is no data corresponding to TNAME, QTYPE in the answer section.)

4c) The owner of the NXT is an ancestor of QNAME and demonstrates that
an NS is present at the owner name and that no DS is present - and AA
bit is 0. (This is a referral or out-of-server CNAME.)

5) It is possible (common?) that no NXT appears.

Any NXT appearing here that does not conform to the rules in 3 or 4
is an error, I would recommend that the reply message MUST be discarded
and the resolver continue to wait for a "sane" response.

Because of the "on-the-fly" CNAME, the DNAMEs in the answer section can
be forgotten once the CNAME is validated.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Okay, okay, the previous sig wasn't all that good...

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>