[dns-operations] question regarding rcodes REFUSED vs NOTAUTH

[Mark Andrews]

In message <5765B325.2020403 at redbarn.org>, Paul Vixie writes:
> 
> 
> Mark Andrews wrote:
> > In message<0FE2F15C-E1C0-47CC-8605-FE8464DF77A7 at iis.se>, Roger Murray write
> s:
> >> Hey everybody,
> >>
> >> I have some questions regarding expected rcodes and what can be found in
> >> the wild. ...
> >> Questions:
> >> Is there more/another rfc that can shed more light on this difference?
> >
> > REFUSED is or should be a policy based result.
> >
> > NOTAUTH is a data driven result where data includes the list of
> > configured zones.
> 
> while that sounds reasonable to me, i don't think there's an RFC that 
> describes the use of NOTAUTH or the other recent RCODEs for use in 
> QUERY. they are defined in RFC 2136 and an UPDATE initiator should 
> expect to hear them.

There is nothing defined for when you send a AXFR request to a
server that doesn't serve the zone.  RFC 1034/RFC 1035 ignore the
possiblity.

> >> Anyone know why different nameservers are implementing the response codes
> >> differently?
> >
> > Different authors.  NOTAUTH is more precise than REFUSED and that
> > is why I switched named to using it if the QNAME is wrong.
> 
> given that there's a recent AXFR clarification RFC, it's odd that noone 
> proposed expanding the RCODE values available to a responder.

Actually it is there.

   e) In the absence of an error, the server MUST set the value of this
      field to NoError(0).  If a server is not authoritative for the
      queried zone, the server SHOULD set the value to NotAuth(9).
      (Reminder: Consult the appropriate IANA registry [DNSVALS].)  If a
      client receives any other value in response, it MUST act according
      to the error.  For example, a malformed AXFR query or the presence
      of an OPT resource record sent to an old server will result in a
      FormErr(1) value.  This value is not set as part of the AXFR-
      specific response processing.  The same is true for other values
      indicating an error.

> i do not think it's wise to answer QUERY with any opcode that did not 
> exist when QUERY was defined, unless it's first proposed and accepted as 
> a protocol change to QUERY. RFC 2136 does not do this.

We should also move to using NXRRSET for NOERROR NODATA and EDNS(1) would
be a good way to signal that the client supports NXRRSET.

> -- 
> P Vixie
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org