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 NS records.

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:

• ns1.nucleus.be
• ns2.nucleus.be
• ns3.nucleus.be
• ns4.nucleus.be

You can verify this using the +trace flag in dig.

$ 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 194.0.44.1#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	31.193.180.217

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	72.52.4.119

This can have wide consequences for the availability of your zone!

One way of determine the IP behind our domain gives you the address 31.193.180.217, the other gives you 72.52.4.119.

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.

Want to make sure you’re safe? Scan your domain through our DNS scanner or try out DNS Spy and get notified for all kinds of potential DNS problems that can hinder your domains’ availability.

Share this post