Subject: Re: wcard-clarify violating RFC 2119, section 6

From: [email-masked]
Date: Thu, 04 Sep 2003 12:09:23 +1000

> Not to be contrary, but I think the more _modern_ way to view it is that a
> DNS name is just a concatenated sequence of labels which forms a unique index
>  into
> a DNS database. From that standpoint, the distinction between "terminal" and
> "nonterminal" really loses its meaning and it seems rather silly and quaint f
> or a
> query of an empty "nonterminal" node to return anything different than a quer
> y of
> an empty "terminal" node. Empty is empty. Period. Whatever negative-caching
> optimizations are theoretically possible as a result of the seemingly-inconsi
> stent
> empty-terminal-vs-empty-nonterminal response differentiation seem to me to be
> underutilized and not worth the confusion and the extra code and resources
> required to interpret such response variations.
> 
> Obviously, the hierarchical structure of the DNS database is still important 
> from
> a zone-delegation/referral standpoint. But as a *database*structure*, the
> hierarhical paradigm has long been superceded by relational and/or contextual
> paradigms. Maybe it's time to let it go...

	Kevin this isn't about the "modern way".  This is about
	clearing up any ambiguities in the definition.  There are
	lots of nameservers that follow RFC 1034 and support empty
	nodes by returning NOERROR/NODATA.

	There are two nameservers that don't (one of which has been
	corrected) based on an interpretation of RFC 2535.

> - Kevin
> 
> --
> 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/>
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: [email-masked]
Date: Thu, 04 Sep 2003 13:59:02 +1000

> On Thu, Sep 04, 2003 at 09:17:12AM +1000, [email-masked] wrote:
> > 	You fail to account for "nor an existing subdomain".  It has
> > 	an existing subdomain (_ssh._tcp.host1.example).
> 
> My bad.  All seem consistent now (sorry for the long learning curve),
> except rfc1034 does not explicitly outlaw a leaf with an empty RR set.

	RFC 1034 provided no way to express such a construct.  It would
	require meta data to be transmitted.

> While wcard-clarify does that now explicitly in its definition of
> existence, it also outlaws tinydns's present behavior:
> 
> $ dnsq a ns.csi.hu a.ns.csi.hu | grep nx
> 76 bytes, 1+0+1+0 records, response, authoritative, nxdomain

	Which is one of the two nameservers that get this wrong.

	Mark

---

From: Robert Elz <[email-masked]>
Date: Thu, 04 Sep 2003 11:08:35 +0700

Date:        Thu, 04 Sep 2003 13:59:02 +1000
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	RFC 1034 provided no way to express such a construct.  It would
  | 	require meta data to be transmitted.

Yes, I guess the closest currently possible would be a name with just
a NULL RR - which is about as useful as a name with no RR's, given that
NULL has no defined uses (or syntax) that I'm aware of.

kre

---

From: Robert Elz <[email-masked]>
Date: Thu, 04 Sep 2003 11:40:14 +0700

Yes, of course, which is why I said "the closest currently possible",
it almost achieves the status of being an empty name, in that it has
no useful data, without actually being empty.

kre

---

From: [email-masked]
Date: Fri, 05 Sep 2003 12:22:41 +1000

> Kevin Darcy writes:
> > If no-one, or very few implementations, are actually using the
> > optimization that has been offered, and the behavior is confusing and
> > quirky and requires more programming logic to parse, let's clarify the
> > spec to simplify the response behavior -- i.e. empty node -> NXDOMAIN,
> > whether it's terminal or nonterminal -- and move on.
> 
> There are two separate proposals here:
> 
>    (1) Telling caches that they can't apply NXDOMAIN to subdomains. This
>        is important, and appears to have already been done by RFC 2308.
>        Existing caches already comply with this rule. New caches have to
>        comply too, because many server installations generate (and will
>        continue to generate) NXDOMAIN for empty nonterminals.
> 
>    (2) Telling servers that they have to use NXDOMAIN rather than NODATA
>        for nonempty terminals, or in any other situation where both
>        NXDOMAIN and NODATA work. I see no interoperability excuse for
>        this; NXDOMAIN is, from a protocol perspective, at best a minor
>        speedup. I chose NXDOMAIN because it simplified my code, not
>        because Vixie claimed that it was required; others might choose
>        NODATA for the same reason. Anyway, many existing installations
>        use NXDOMAIN, and many others use NODATA.
> 
> Neither proposal is tied to the definition of wildcards in DNSSEC.

	Actually it is.  You need to decide which RCODE you are
	going to accept.

	RCODE=????
	Question:
	foo.example A
	Authority:
	example SOA ...
	exampe SIG(SOA)
	a.example NXT bar.foo.example  (proves foo.example is empty and exist).
	a.example SIG(NXT)

> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
> 
> --