In message <canljsvu5re7xh_-9t77x-d_rnxoa9x9+bkwrx-b_l5gpjb_...@mail.gmail.com>
, abby pan writes:
> Ted Lemon <[email protected]>
> 
> >
> > I think this document could be made a lot simpler if it simply said what
> > it says in the abstract, without placing new requirements on DNS caches.
> >  Right now it says DNS caches SHOULD take an NXDOMAIN on a particular
> > domain as applying to all names under it.   This is certainly a valid
> > thing to do, and I can think of ways to do it reasonably efficiently
> > even wish a hashed cache, but reasonably is still O(number of labels)
> > instead of O(1).
> >  If you just say what the abstract says and nothing more, that allows
> > implementations to be "more efficient," as you suggest, without
> > requiring implementations to be less efficient.   Granted, it's a
> > SHOULD, but I think that still goes too far.   You should just say
> > that NXDOMAIN means what you want it to mean, and leave it at that.
> >
>
> another choice :  Authority Server return NODATA/NXDOMAIN as nxdomain cut,
> but no change on DNS cache.  Some impact on NSEC/NSEC3 records.
>
> - no names under foo.example => NXDOMAIN  at  foo.example

If you want to signal NOERROR + bottom of zone you need a new rcode
and signaling that you support the new rcode.  The above imply is
just wrong as it changes what NXDOMAIN means.

> - zone with bar.foo.example, where foo.example does not exist => NODATA
> or  NOERROR + NULL Answer    at  foo.example

Well a explict NODATA rcode would be useful and again signaling of support
for the new rcode is needed.

NXDOMAIN at a empty non terminal only came about as the result of
bad wording in RFC 2535.  "no names" should have been "no names
with data" (the difference is crucial in determining which rcode
is returned).  Only RFC 2535 nameservers are allowed to return
NXDOMAIN for a empty non-terminal and they should few and far between
these days.  Every other NXDOMAIN at a empty non terminal is the
result of miss-interpreting STD 13 or a operational error e.g.
missing delegation in a parent zone.

> Best Regards
> Pan Lanlan
>

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

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to