[dns-operations] Any dreamhost DNS admins?

Doug Barton dougb at dougbarton.email
Wed Feb 20 09:15:03 UTC 2019


On 2/19/19 9:24 PM, Paul Vixie wrote:
> 
> 
> Mark Andrews wrote on 2019-02-19 20:52:
> ...
>>>> If the final name doesn’t exist then NXDOMAIN is fine.
>>>
>>> Agreed.  This is quite correct when the CNAME target is in the same 
>>> zone.
>>
>> Or if the server can determine it from another zone it serves or if it
>> recursed to construct the answer.
> even assuming a mixed mode server that's both authoritative and 
> recursive, nothing it had to recurse for or could recurse for should 
> have an impact on answers to questions with RD=0. so the answer to 
> out-of-zone cname chains that end outside the zones this server is 
> authoritative for should be dictated by the last zone's status, so, 
> either NOERROR, REFUSED, or SERVFAIL, but never NXDOMAIN.

Thanks to all who replied, although I'm a bit surprised by some of the 
answers.  :)

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?

I did notice that the dreamhost.com servers believe that they are auth 
for the zone that the target of my CNAME is in, although they have no 
records for it other than NS and SOA (and the domain is not delegated to 
them). Some of the responses so far seem to indicate that under those 
circumstances NXDOMAIN would be an appropriate status, but I agree with 
what I think Paul is saying, that it's not right here.

So while it's pathological that the dreamhost server thinks it's auth 
for a domain that is not delegated to it, that still shouldn't result in 
an NXDOMAIN response when it actually has a CNAME at the label I'm 
querying for, in the zone that it IS auth for.

I should have been more specific that I'm querying an auth server 
directly, using either dig or Net::DNS. The domain for the target of the 
CNAME is delegated to a completely different set of name servers. I'm 
querying specifically for an A record when I get this result, but I get 
the same result if I try for an AAAA or TXT record at that same label. 
(Probably other records too, but I didn't try them.)

Unfortunately I cannot share the name I'm querying for on the public 
list, but I can show you the packet header:

; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> REDACTED a @ns1.dreamhost.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22980
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 2800

To be clear, I'm specifically asking the server that is auth for the 
domain for an A record for a host within the domain. It's responding 
with NXDOMAIN but also an ANCOUNT of 1, and the CNAME is in the ANSWER 
section of the packet, with no recursion results or ADDITIONAL data. The 
status I'd expect (based on BIND, and other behavior) is NOERROR, along 
with the ANCOUNT of 1 of course.

I get essentially the same result using Net::DNS:

;; Answer received from 64.90.62.230 (164 bytes)
;; HEADER SECTION
;;	id = 44467
;;	qr = 1	aa = 1	tc = 0	rd = 0	opcode = QUERY
;;	ra = 0	z  = 0	ad = 0	cd = 0	rcode  = NXDOMAIN
;;	qdcount = 1	ancount = 1	nscount = 1	arcount = 0
;;	do = 0

I don't think it's dig or Net::DNS version-dependent, as I get the same 
results on my Mac High Sierra system.

So what am I missing here?

:)

Doug


More information about the dns-operations mailing list