1

I'm planning to migrate my domain's DNS from one provider to another. ("mydomain.com" as I have to censor the real name) Technically, it's just a matter of changing the NS records before the registrar change, but I'd like to make sure I didn't miss some domains by spoofing the DNS server on my local machine and testing.

I first tried changing my /etc/resolv.conf to "nameserver 2.22.230.67" (it's one of the new nameservers), but it no longer returns anything for CNAME entries pointing to different domains (edgekey.net):

$ dig +short login.mydomain.com
prod.mydomain.com.edgekey.net.
$ dig +short prod.mydomain.com.edgekey.net
e8727.dscx.akamaiedge.net.
$ dig +short e8727.dscx.akamaiedge.net
$

I then tried to install and configure bind but quickly gave up, and tried again with dnsmasq with this entry:

server=mydomain.com/2.22.230.67

The problem was not resolved although dnsmasq correctly resolves CNAMES if I manually ask it by issuing multiple queries:

$ dig +short login.mydomain.com
prod.mydomain.com.edgekey.net.
$ dig +short prod.mydomain.com.edgekey.net
e8727.dscx.akamaiedge.net.
104.84.78.23
$ nslookup login.mydomain.com
Server:         127.0.0.1
Address:        127.0.0.1#53

login.mydomain.com   canonical name = prod.mydomain.com.edgekey.net.
prod.mydomain.com.edgekey.net        canonical name = e8727.dscx.akamaiedge.net.
Name:   e8727.dscx.akamaiedge.net
Address: 2a02:26f0:2b00:396::2217
Name:   e8727.dscx.akamaiedge.net
Address: 2a02:26f0:2b00:3a9::2217
$ ping login.mydomain.com
ping: login.mydomain.com: Name or service not known

Am I doing something wrong or expecting too much from dnsmasq?

I have already given up and launched the next steps, migrating the DNS and test in production, but I'm still curious as to how I should have tested that.

If I were on windows 10, I could probably try the powershell command Add-DnsClientNrptRule which very much looks like what I need, but for now I'd like a solution for Linux.

Camusensei
  • 231

1 Answers1

1

You're expecting too much from it. Both /etc/resolv.conf and dnsmasq are "stub" resolvers – they do not know how to follow delegations, and they do not know how to chase aliases. They both rely on your provided server being a full "recursive" resolver which does all necessary processing and immediately returns the final result.

(2.22.230.67 is not such a server. It is an authoritative-only server which answers only queries for domains it directly hosts, but does not answer recursive queries. Very few public servers are configured to do both jobs at once, though it's more common inside corporate networks.)

This also makes a difference to BIND: if you configured the domain as a "forward" zone, it too expects the server to accept a recursive query and return a complete, final answer. Instead, in your case the correct type would be "static-stub":

# /etc/named.conf

zone "mydomain.com." {
    type static-stub;
    server-addresses { 2.22.230.67; };
};

(Do not use "type stub" – that does something slightly different.)

If BIND did not work, Unbound is your next option. The following should do the job:

# /etc/unbound/unbound.conf

stub-zone:
    name: "mydomain.com."
    stub-addr: 2.22.230.67
    stub-first: yes

Similarly to BIND, Unbound has two zone types – "stub-zone" which expects to be pointed to an authoritative server which may return incomplete answer, whereas "forward-zone" expects to be pointed to a recursive server which always returns a complete, final answer. For example, you would use a forward-zone to point all remaining queries to 1.1.1.1 or 8.8.8.8.

(The dnsmasq "server=" option is like "forward-zone" in Unbound. As mentioned in the beginning, dnsmasq is not a recursive resolver, so it does not have any equivalent to "stub-zone".)

grawity
  • 501,077