Ever since the launch of our DNS scan, we’ve had the warning about mismatched
NS records. Many users choose to ignore this, but there’s a pretty good reason we give a big warning whenever those records don’t line up.
In this blogpost, we’ll show what can happen with misconfigured
How DNS usually works
Take this example of
example-dnsspy.be, one of our playground domains. If you were to look up how this domain is configured, you could see it is configured with 4 nameservers:
You can verify this using the
+trace flag in
$ dig +trace example-dnsspy.be ... example-dnsspy.be. 86400 IN NS ns4.nucleus.be. example-dnsspy.be. 86400 IN NS ns3.nucleus.be. example-dnsspy.be. 86400 IN NS ns1.nucleus.be. example-dnsspy.be. 86400 IN NS ns2.nucleus.be. ;; Received 827 bytes from 188.8.131.52#53(d.ns.dns.be) in 4 ms
The nameservers are returned by one of the authoritative nameservers for the
.be zone, in our example it used
d.ns.dns.be to get that information.
Your DNS client now knows it can query one of those nameservers for the records you want. And this is where it gets interesting. Most clients just work like this:
$ dig @ns1.nucleus.be. example-dnsspy.be. example-dnsspy.be. 3600 IN A 184.108.40.206
The DNS client takes one of the authoritative nameservers (randomly) and queries it for your requested records. Which is fine. However, they don’t all do this.
Domain delegation via NS records
The client can also query your domain and ask for
NS records. These are returned by your authoritative nameservers and are used to delegate (part of) your zone to other nameservers.
See this example, that might clear things up.
$ dig @ns1.nucleus.be. example-dnsspy.be. NS example-dnsspy.be. 86400 IN NS ns1.sedoparking.com. example-dnsspy.be. 86400 IN NS ns2.sedoparking.com. ;; Received 113 bytes from 2a03:a800:7::4#53(ns2.nucleus.be) in 3 ms
One of our nameservers is responding to the
NS query with 2 unrelated nameservers. I took the nameservers from a popular domain selling service, Sedo, as they have them configured to reply to any DNS query with a default, catch-all, IP address. Useful for testing, nothing more.
So what’s going on?
Well, our domain
example-dnsspy.be should respond with the nameservers that are authoritative for its zone. However, it responded with a set of unrelated nameservers. Depending on the DNS client, it will now query those instead. It is, for instance, what Unbound does.
The entire DNS flow for requesting the IP behind
example-dnsspy.be then looks like this.
$ dig @ns1.nucleus.be. example-dnsspy.be. NS example-dnsspy.be. 86400 IN NS ns1.sedoparking.com. example-dnsspy.be. 86400 IN NS ns2.sedoparking.com. $ dig @ns1.sedoparking.com. example-dnsspy.be. example-dnsspy.be. 300 IN A 220.127.116.11
This can have wide consequences for the availability of your zone!
One way of determine the IP behind our domain gives you the address
18.104.22.168, the other gives you
This is why it’s important to match your NS records with your actual, authoritative, nameservers. The availability of your domain depends on it.
When does this happen?
Misconfigured NS records are usually the result of a DNS migration from one provider to another, where zone files are copy/pasted without modifying the underlying NS records correctly.
Alternatively, if someone configures them by hand and makes a typo, it can become possible to register the typo-domain and hijack (some) parts of the DNS.
You can’t control how the clients’ nameserver will query for your domain, but you can control how your nameservers respond. Make sure you’ve got that part covered.