4

While developing my DNS checking tool and running test reports I've noticed a DNS issue with ns4.serverfault.com:

Full report here:

http://www.dnsinspect.com/serverfault.com

Different glue is offered by parent name servers and domain name servers:

  • ns4.serverfault.com IP=69.59.196.18 at parent name servers (Registrar, Name.com)
  • ns4.serverfault.com IP=69.59.196.122 at name servers (ns{1,2,3,4}.serverfault.com)

This error may introduce small delays in DNS resolution process:

vitalie@black:~$ dig @69.59.196.18 serverfault.com +short

; <<>> DiG 9.7.0-P1 <<>> @69.59.196.18 serverfault.com +short
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

vitalie@black:~$ ping -c 3 69.59.196.18
PING 69.59.196.18 (69.59.196.18) 56(84) bytes of data.
From 69.59.218.226 icmp_seq=2 Time to live exceeded
From 69.59.218.226 icmp_seq=3 Time to live exceeded

--- 69.59.196.18 ping statistics ---
3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2008ms
14
  • 5
    I think the wording has to be "the glue provided by the parent name servers has to match the data provided by the authoritative name servers" as the latter would not provide "glue".
    – the-wabbit
    Commented Feb 6, 2013 at 21:25
  • If you're developing a DNS checking tool you should first ensure you have a proper understanding of the topic.
    – John Gardeniers
    Commented Feb 7, 2013 at 10:06
  • @syneticon-dj I've updated the message. Thank you!
    – vitalie
    Commented Feb 7, 2013 at 11:42
  • @JohnGardeniers I don't mind to learn new things, if you have comments or suggestions they are welcomed. :)
    – vitalie
    Commented Feb 7, 2013 at 11:47
  • 1
    Understanding DNS goes way beyond anything that we could cover in comments but there are some really great articles and books on the subject. The concept of glue records in particular is something a great many people seem to have trouble with. In this instance the important part is what syneticon-dj said, the authorative name servers for the domain do not provide glue. Glue records exist so that we can find those authorative name servers. The distinction is really important.
    – John Gardeniers
    Commented Feb 8, 2013 at 2:05
  • Indeed, DNS is very complex and many have problems understanding it, this is why I developed this tool. I wanted to share with everyone what I've learned about DNS and to help people find their DNS problems. Thank you for your observation!
    – vitalie
    Commented Feb 8, 2013 at 9:36
  • I'm not sure it would cause any delays in resolving. If you do a dig +trace ns4.serverfault.com, you get the proper IP.
    – Alex
    Commented Feb 8, 2013 at 20:23
  • 1
    dig +trace is using your local DNS resolver to resolve names.
    – vitalie
    Commented Feb 9, 2013 at 10:46
  • @vitalie, actually no. The +trace will trace the delegation path starting from the root name servers in order to resolve. So starting from the root servers, then the gtld servers, then serverfault's name servers.
    – Alex
    Commented Feb 11, 2013 at 17:44
  • 1
    It will start from root name servers but it will resolve names using local resolver. Make a simple test, start a tcpdump while running query or just remove temporarily your name servers from /etc/resolv.conf.
    – vitalie
    Commented Feb 11, 2013 at 20:25
  • @vitalie again...that's wrong. Your DNS server in resolv.conf will give you the IPs of all the root servers. Those will give you the GTLD servers responsible for that domain and finally you will get the results from the SOA. By removing the name servers from /etc/resolv.conf you are just briking the first step. That's all. Just look at the results from dig Received 169 bytes from 198.252.206.80#53(ns1.serverfault.com) in 22 ms or Received 135 bytes from 192.31.80.30#53(d.gtld-servers.net) in 36 ms
    – Alex
    Commented Feb 11, 2013 at 20:56
  • 1
    I'm trying to tell you that dig +trace is acting as recursive name server just partially. It will follow referrals (authority section) from root servers but it will resolve name servers names through your DNS caching server.
    – vitalie
    Commented Feb 12, 2013 at 8:05
  • 1
    Start a tcpdump before launching dig command to see what I mean (Ex: tcpdump -i eth0 -n src 8.8.8.8 \or dst 8.8.8.8).
    – vitalie
    Commented Feb 12, 2013 at 8:08
  • 2
    After trying a few times to explain in 600 characters or less why vitalie is right about the behavior of +trace, I eventually gave up and did a self Q&A that covers the topic in-depth.
    – Andrew B
    Commented Feb 27, 2013 at 8:00

2 Answers 2

Reset to default
2

All the name servers have been added for our domains (NS1-NS4.SERVERFAULT.COM) and the glue record for NS4 has been updated to the correct IP.

Therefore I think this should be resolved, please let me know if you still notice any misconfiguration.

2

The comments are stating to be a bit long and I believe the question/statement deserve at least one answer.

A little recap, parent name servers have wrong glue records for ns4.serverfault.com

As it stands, the glue record is wrong and should match the Authoritative Name Servers.

The glue records are the entries that you will find in the Name Servers section when querying the registrar of a domain.

whois serverfault.com | grep -A 4 "Name Servers"

Name Servers:
    ns1.serverfault.com
    ns3.serverfault.com
    ns4.serverfault.com

That's why you never see ns2.serverfault.com in the glue records of the parent name servers. Even if it's allowed to answer queries for serverfault.com with the AA flag.

These records are the delegated name servers.
They ARE NOT the Authoritative Name Servers.

Authoritative Name Servers are the NS RRs found in the zone. As stated in the RFC 1035 (section 3.2.2)

One way to get all the Authoritative Name Servers is to ask for the NS entry of a zone to the SOA of that zone.

dig +short serverfault.com soa
ns1.serverfault.com. sysadmins.stackoverflow.com. 2013020902 600 600 604800 1440

dig +short @ns1.serverfault.com serverfault.com ns
ns3.serverfault.com.
ns1.serverfault.com.
ns2.serverfault.com.
ns4.serverfault.com.

These are the only name servers allowed to answer queries for serverfault.com with the AA flag. (Authoritative Answer). And are not allowed to do recursive query for serverfault.com.



Now, to the trace and glue issue.

If I have no cache of anything with regards to serverfault.com, my resolver will do the equivalent of a dig +trace serverfault.com

As a matter of fact, that command is basically asking your resolver to act as a cache server with an empty cache.

Running dig +trace serverfault.com along with tshark -R "udp.port == 53" -i wlan0

PC ask resolver for all root servers. (Iterative, meaning no RD flag)

m.y.i.p -> m.y.d.ns DNS 59 Standard query NS <Root>

Resolver answers.

0.244995 m.y.d.ns -> m.y.i.p    DNS 378 Standard query response NS e.root-servers.net NS f.root-servers.net NS g.root-servers.net NS h.root-servers.net NS i.root-servers.net NS j.root-servers.net NS k.root-servers.net NS l.root-servers.net NS m.root-servers.net NS a.root-servers.net NS b.root-servers.net NS c.root-servers.net NS d.root-servers.net

Then you'll have all the A request for every root servers along with the resolvers answer. But these two lines are important here...(Recursive, with RD flag)

0.331326 m.y.i.p -> m.y.d.ns DNS 78 Standard query A k.root-servers.net
0.344396 m.y.d.ns -> m.y.i.p DNS 408 Standard query response A 193.0.14.129

PC ask k.root-servers.net for A serverfault.com (no RD flag)

0.428328 m.y.i.p -> 193.0.14.129 DNS 75 Standard query A serverfault.com

k.root-servers.net answers with the GTLD servers responsible for .com.

0.479877 193.0.14.129 -> m.y.i.p. DNS 535 Standard query response

Again, my PC will ask for the A record of all the GTLD servers to my resolver. (with RD flag)

0.634209 m.y.i.p -> m.y.d.ns DNS 78 Standard query A l.gtld-servers.net
0.647336 m.y.d.ns -> m.y.i.p DNS 414 Standard query response A 192.41.162.30

PC ask l.gtld-servers.net for A serverfault.com (no RD flag)

0.662461 m.y.i.p -> 192.41.162.30 DNS 75 Standard query A serverfault.com
0.763867 192.41.162.30 -> m.y.i.p DNS 177 Standard query response

l.gtld-servers.net gives the delegated name server and my PC ask my resolver for the IP of each one of them. (with RD flag)

0.765100 m.y.i.p -> m.y.d.ns DNS 79 Standard query A ns1.serverfault.com
0.777483 m.y.d.ns -> m.y.i.p DNS 211 Standard query response A 198.252.206.80
0.777707 m.y.i.p -> m.y.d.ns DNS 79 Standard query A ns3.serverfault.com
0.790625 m.y.d.ns -> m.y.i.p DNS 211 Standard query response A 69.59.196.217
0.791522 m.y.i.p -> m.y.d.ns DNS 79 Standard query A ns4.serverfault.com
0.803938 m.y.d.ns -> m.y.i.p DNS 211 Standard query response A 69.59.196.122

Note that you will always receive these 3 delegated servers in that order.

It will pick one of them and ask for the IP for serverfault.com in my case, ironically enough it picked ns4.serverfault.com. (no RD flag)

0.804629 m.y.i.p -> 69.59.196.122 DNS 75 Standard query A serverfault.com
0.905948 69.59.196.122 -> m.y.i.p DNS 227 Standard query response A 198.252.206.16

Since the last query is with no RD flag and is asked to one of the Authoritative Name Server, a dig +trace will always give you an answer with flag AA...meaning not from your resolvers cache but rather from one of the Authoritative Name Server.

You have just completed the delegation path from Root to Authoritative Name Servers.

The reason why ns4.serverfault.com will resolve properly even if the glue record is wrong is that your resolver, or any resolver, will actually learn about ns1.serverfault.com and ns3.serverfault.com.

Both of them are able to answer queries for serverfault.com and you will know about them first.

3
  • 1
    This is a nice writeup but it should be mentioned that the glue record for ns4.serverfault.com really appears to be incorrect and should be changed. Which I suppose was one of the intentions of the question.
    – the-wabbit
    Commented Feb 13, 2013 at 14:00
  • You're right, I edited the answer to reflect that.
    – Alex
    Commented Feb 13, 2013 at 15:07
  • l.gtld-servers.net gives the delegated name server and my PC ask my resolver for the IP of each one of them. (with RD flag) - I'm really bad at explainging things :), this is what I'm trying to tell you, dig is asking your resolver to do the dirty job for you: resolve ns{1,2,3}.serverfault.com.
    – vitalie
    Commented Feb 13, 2013 at 17:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .