In message <prayer.1.3.5.1311141624090.27...@hermes-2.csi.cam.ac.uk>, Chris Tho
mpson writes:
> A user here was confused by the fact that
>
> dig -t DS cam.ac.uk @authdns0.csx.cam.ac.uk
>
> gives an (authoritative!) "nodata" response. (Well actually he was using
> "host" rather than "dig", but the principle is the same.)
>
> The server is authoritative-only and gives REFUSED when queried about
> other zones, so my first thought was that it ought to have deduced
> that the DS record for cam.ac.uk lives in ac.uk, and that is not one
> of the zones it is authoritative for, and so REFUSED would be the right
> response.
>
> If the nameserver is authoritative for both parent and child, and
> the DS record for the child is requested, it correctly returns the
> one from the parent zone. Well, obviously this must work, as the
> situation is common.
>
> So is this a BIND bug? Or is it somehow allowed by small print in
> the RFCs somewhere?
RFC 4035 Section B.8. DS Child Zone No Data Error
> [Adding +dnssec provides a response that proves there is no DS
> record for cam.ac.uk in the zone cam.ac.uk, which of course is true.]
>
> --
> Chris Thompson
> Email: c...@cam.ac.uk
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
