[dns-operations] Any dreamhost DNS admins?

[Petr Špaček]

On 20. 02. 19 13:19, Tony Finch wrote:
> Doug Barton <dougb at dougbarton.email> wrote:
>>
>> My understanding of NXDOMAIN has always been that it means "I have
>> nothing at that label." Am I missing something there? If I'm right, how
>> does that status reconcile with an ANCOUNT > 0?
> 
> It comes from the algorithm in section 4.3.2 of RFC 1034.
> 
> [snip]
> 
>    3. Start matching down, label by label, in the zone.  The
>       matching process can terminate several ways:
> 
>          a. If the whole of QNAME is matched, we have found the
>             node.
> 
>             If the data at the node is a CNAME, and QTYPE doesn't
>             match CNAME, copy the CNAME RR into the answer section
>             of the response, change QNAME to the canonical name in
>             the CNAME RR, and go back to step 1.
> 
> [snip]
> 
>          c. If at some label, a match is impossible (i.e., the
>             corresponding label does not exist), look to see if a
>             the "*" label exists.
> 
>             If the "*" label does not exist, check whether the name
>             we are looking for is the original QNAME in the query
>             or a name we have followed due to a CNAME.  If the name
>             is original, set an authoritative name error in the
>             response and exit.  Otherwise just exit.
> 
> Curiously, this says that an in-zone CNAME should not provoke an NXDOMAIN.
> 
> In actual implementations, the RCODE refers to the *end* of the
> CNAME chain that appears in the answer, tho I can't find the right RFC
> that says so.

I just recalled this:

https://tools.ietf.org/html/rfc6604#section-3

3.  RCODE Clarification

   The RCODE field in a DNS query response header is non-zero to
   indicate an error.  Section 4.3.2 of [RFC1034] has a resolution
   algorithm that includes CNAME processing but has been found to be
   unclear concerning the ultimate setting of RCODE in the case of such
   redirection.  Section 2.1 of [RFC2308] implies that the RCODE should
   be set based on the last query cycle in the case of an xNAME chain,
   but Section 2.2.1 of [RFC2308] says that some servers don't do that!

   When there is an xNAME chain, the RCODE field is set as follows:

      When an xNAME chain is followed, all but the last query cycle
      necessarily had no error.  The RCODE in the ultimate DNS response
      MUST BE set based on the final query cycle leading to that
      response.  If the xNAME chain was terminated by an error, it will
      be that error code.  If the xNAME chain terminated without error,
      it will be zero.

Petr Špaček  @  CZ.NIC


> 
> RFC 1035 also says NXDOMAIN is only meaningful in authoritative responses,
> which also seems to be ignored in practice.
> 
> Things get weird when there's a cache or RA involved, and authoritative
> servers have differed on how strongly they wall off zones from each other.
> I have somehow managed to get my server to answer differently on localhost
> and on its public interface and I'm not sure how (the relevant acl is
> supposed to include both addresses...)
> 
> ; <<>> DiG 9.13.6 <<>> +norec outofzone.dotat.at @::1
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48267
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
> 
> ; <<>> DiG 9.13.6 <<>> +norec outofzone.dotat.at @131.111.57.57
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43198
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> Tony.