dig (and other tools) only returning A records

Question

I've been trying to work out why the PHP getmxrr() and checkdnsrr() methods do not return successfully for working domains in a number of vagrant VMs that I use.

When looking into this further I tried using simple dig commands and I only get an ANSWER for A records. Anything else returns nothing.

As an example, here is the 'correct' ANSWER section for an ANY enquiry showing all of the records for that exist for an example domain (from an AWS-hosted server). You can see that their are at least NS, TXT, A and MX records:

Debian AWS VM:

$ dig reiss.com ANY 

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> reiss.com ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65366
;; flags: qr rd ra; QUERY: 1, ANSWER: 20, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;reiss.com.         IN  ANY

;; ANSWER SECTION:
reiss.com.      55  IN  NS  ns2.dnsmadeeasy.com.
reiss.com.      55  IN  NS  ns3.dnsmadeeasy.com.
reiss.com.      55  IN  NS  ns4.dnsmadeeasy.com.
reiss.com.      55  IN  NS  ns0.dnsmadeeasy.com.
reiss.com.      55  IN  NS  ns1.dnsmadeeasy.com.
reiss.com.      55  IN  MX  1 reiss-com.mail.protection.outlook.com.
reiss.com.      55  IN  TXT "v=spf1 ip4:212.49.201.210 ip4:80.168.187.225 ip4:109.68.12.42 ip4:79.125.20.120 ip4:46.51.172.2 ip4:46.51.172.4 include:spf.protection.outlook.com include:spf.mandrillapp.com -all"
reiss.com.      55  IN  TXT "loaderio=44b80a8be72962eccbd8ad01b6bfcac7"
reiss.com.      55  IN  TXT "google-site-verification=vrc2bvxpw2quwligK1dYuIFG6SLPp6PsOj3FlbNKmmo"
reiss.com.      55  IN  TXT "globalsign-domain-verification=DxtJ51OaIp87_OgmKu-iPxmFMN4i0CvhJtymIzHDyK"
reiss.com.      55  IN  TXT "vzjt+g3yB76l1eAihRfinxKPdAJvcxO5AAXUVdOlnqDRjHA8l+fHdBKsUp+mrKeCB2GTaX4GCUpFo5PoYNvTgw=="
reiss.com.      55  IN  SOA ns0.dnsmadeeasy.com. dns.dnsmadeeasy.com. 2008025750 43200 3600 1209600 180
reiss.com.      55  IN  A   52.85.142.187
reiss.com.      55  IN  A   52.85.142.218
reiss.com.      55  IN  A   52.85.142.227
reiss.com.      55  IN  A   52.85.142.253
reiss.com.      55  IN  A   52.85.142.33
reiss.com.      55  IN  A   52.85.142.79
reiss.com.      55  IN  A   52.85.142.108
reiss.com.      55  IN  A   52.85.142.145

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Feb 18 12:48:12 UTC 2017
;; MSG SIZE  rcvd: 872

Virtual machine (Centos 7):

Looking at individual requests on my Vagrant VM though and I get:

$ dig reiss.com A 

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> reiss.com ANY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32964
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;reiss.com.         IN  ANY

;; ANSWER SECTION:
reiss.com.      3600    IN  A   52.85.142.79
reiss.com.      3600    IN  A   52.85.142.218
reiss.com.      3600    IN  A   52.85.142.227
reiss.com.      3600    IN  A   52.85.142.253
reiss.com.      3600    IN  A   52.85.142.145
reiss.com.      3600    IN  A   52.85.142.33
reiss.com.      3600    IN  A   52.85.142.108
reiss.com.      3600    IN  A   52.85.142.187

;; Query time: 1 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Sat Feb 18 12:48:24 GMT 2017
;; MSG SIZE  rcvd: 155

But any other type of record returns nothing:

$ dig reiss.com MX

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> reiss.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 2267
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;reiss.com.         IN  MX

;; Query time: 0 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Sat Feb 18 14:52:15 GMT 2017
;; MSG SIZE  rcvd: 38


$ dig reiss.com TXT

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3.2 <<>> reiss.com TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id: 24668
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;reiss.com.         IN  TXT

;; Query time: 0 msec
;; SERVER: 10.0.2.3#53(10.0.2.3)
;; WHEN: Sat Feb 18 14:53:36 GMT 2017
;; MSG SIZE  rcvd: 38

These commands work fine on the AWS server as well as on my Mac OSX host machine locally, it just seems to fail inside my Vagrant/Virtualbox VM.

The problem is also affecting PHP so I don't think it's anything to do with the dig command.

Any ideas?

Although `ANY` requests are useful for debugging; please request specific (`SOA` , `DNS` , `MX` etc.) records instead: https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ and https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-02 and also consider that since ANY requests might be too large to fit in the usual UDP datagram they might be transmitted over TCP instead, which might fail if only UDP 53 is opened in a firewall — HBruijn, Feb 18 '17 at 13:17
Thanks. I did try individual types as well. To confirm - for `dig reiss.com MX` I get the expected ANSWER on Mac OSX Host and AWS VM, but nothing in my Centos 7 VM — Peter Ward, Feb 18 '17 at 13:52
@PeterWard What is this server at `10.0.2.3` and why is it responding with `NOTIMP`? — Håkan Lindqvist, Feb 18 '17 at 15:15
Aha! This VM is setup with 2 virtual network adapters. One of these is configured as NAT and 10.0.2.3 is the IP of the Host. `etc/resolv.conf` has the following which appears to be autogenerated: `nameserver 10.0.2.3`. Changing this to `8.8.8.8` makes dig work for all queries. I don't know whether the host should be setup as the nameserver and needs to pass on DNS queries or just stick to using something like google... — Peter Ward, Feb 18 '17 at 17:53
@PeterWard Can you add any information on what software/config `10.0.2.3` is running, that might make it possible to properly answer the updated question? The way it responds with `NOTIMP` (not implemented) to seemingly bog standard queries makes me suspect that it's some highly specialized implementation that may not be suitable for this use. — Håkan Lindqvist, Feb 19 '17 at 13:18
`10.0.2.3` is the host machine - a Macbook Pro running OSX Sierra. NetworkManager appears to be setting this ip of the Host machine as the DNS server when Vagrant starts the VM. I'm not sure if this is expected or standard. I couldn't find any configuration within the Vagrantfile to specify this, neither on the VM side. My resolution for now has been to prevent NetworkManager from updating /etc/resolv.conf using a nodns option then manually override it to `8.8.8.8` but this feels quite hacky... Some of my team have the same problem when running from Windows so unlikely a Mac issue. — Peter Ward, Feb 19 '17 at 14:18

score 5 · Answer 1 · answered Feb 18 '17 at 13:18

5

The way ANY works is that the server that receives the query should return the records it has for that name (regardless type).

The implication of this is that when directed at a caching recursing server, it typically just returns whatever it already has in the cache (valid behavior).

Ie, ANY is of limited use for actual production use but can be relevant in troubleshooting, etc.

answered Feb 18 '17 at 13:18

Håkan Lindqvist

33,741
5
65
90

OK thanks. As above the use of `ANY` might have been misleading me as it explains the Mac OSX behaviour. However the main problem is that requesting any type other than A responds with nothing. I will update/clarify the question. – Peter Ward Feb 18 '17 at 14:46

score 1 · Answer 2 · edited Apr 13 '17 at 12:13

After the helpful clues provided here,I realised that the above was a symptom. The real problem was the DNS settings through Vagrant of running the network adapter in NAT mode.

There is more info on this post: Vagrant / VirtualBox DNS 10.0.2.3 not working.

However, the suggestions here did not work for me, I already had the following applied:

vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]

I tried removing this or the alternative:

vb.customize ["modifyvm", :id, "--natdnsproxy1", "on"]

Neither worked. I would still end up with a resolv.conf as follows and dig will not work for MX, TXT, or SOA records:

# Generated by NetworkManager
search local
nameserver 10.0.2.3

My (probably dirty) solution was to disable the resolv.conf update in NetworkManager and hard-code google for DNS.

/etc/NetworkManager/NetworkManager.conf:

[main]
dns=none

/etc/resolv.conf:

search local
nameserver 8.8.8.8
nameserver 10.0.2.3

If you change network adapters then the 10.0.2.3 is no longer dynamic so you need to be careful, but this workaround did the job for me.

I'm sure there's a better way, maybe I should be using a Bridged adapter instead...

dig (and other tools) only returning A records

2 Answers2