13

I'm debugging a DNS resolution error for the domain auth.otc.t-systems.com with Cloudflare's server, but got stuck. The strange thing is that the lookup succeeds/fails depending on the machine that runs the query, but I can't figure out where the configuration differs.

The failure is always with following message: server can't find auth.otc.t-systems.com: SERVFAIL

1.1.1.1 is Cloudflare's DNS.

What I've tried so far:

Any hints how I can further debug this?

Improve this question
1

2 Answers 2

Reset to default
12

Try using dig. Twenty years ago they tried to deprecate nslookup, but its firmly ingrained into muscle memory now and impossible to get rid of, but dig is far superior. For example.

dig +trace auth.otc.t-systems.com @1.1.1.1

Will trace the resolution fully for you, and you can see where they differ.

Improve this answer
8
  • Thanks, I didn't know that about nslookup. I've now tried the dig command and strangely it returns the correct ip on my machine. I've posted the output from the command on both my machine and the local machine here gist.github.com/thomas88/600d367387505a13223a5270c89eedda. Whatever dig does different, my browser (Chrome on Mac) seems to be more in line with nslookup - it can't resolve the address.
    – Thomas Obermüller
    Oct 9, 2018 at 9:20
  • 2
    There isn't any reason to expect different results between dig and nslookup for this query. However since 1.1.1.1 is an anycast address the result can differ depending on which server the query end up being served by.
    – kasperd
    Oct 9, 2018 at 9:33
  • 1
    What's the point of using both +trace and @1.1.1.1? Are you sure you understand how these options work together?
    – Barmar
    Oct 9, 2018 at 16:52
  • 1
    Yes, I'm certain I understand how these work together. The point of using @<address> would be to specify the dns servers that his client is using in the two locations. In the example given, its cloudflare's, but if another client uses a different dns server, it would be specified there. For example, where I am, the server address in resolv.conf is a company one, but I can still resolve from 1.1.1.1
    – Sirch
    Oct 10, 2018 at 12:04
  • 1
    @PatrickMevzek that's true. But it's not helpful for determining why resolution isn't working with that nameserver, since all the rest of the processing will bypass it. Unless you think the problem is with how it resolves the root servers.
    – Barmar
    Jul 26, 2019 at 1:29
4

Network people have used for ages 1.1.1.1 as a replacement to another private address in random interfaces of switches/routers APs. (I am myself on a location at this moment where the public facing IP adress of the hundreds of wireless APs is 1.1.1.1 )

I bet my money in the machines you are not able to talk to Cloufare's 1.1.1.1 that you have an (imtermediate) route there for such interface.

For instance, in my case, 1.1.1.1 is giving me my IP address:

$ sudo tcpdump -i any -n host 1.1.1.1 and port 67
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
13:11:51.037186 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296
13:11:51.037250 IP 1.1.1.1.67 > 10.x.x.x.68: BOOTP/DHCP, Reply, length 296
Improve this answer
5
  • 4
    This is why RFC 3849 and RFC 5737 have to be rigorously enforced.
    – kasperd
    Oct 9, 2018 at 12:12
  • 2
    "Too low" is a tricky basis for determining anything, though. Cloudflare have a lot of PoPs. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=1.30 ms is my RTT to the real thing.
    – Håkan Lindqvist
    Oct 9, 2018 at 12:12
  • @HåkanLindqvist Your value does seem a too low delay for an external connection....but yeah, not a reliable metric.
    – Rui F Ribeiro
    Oct 9, 2018 at 12:17
  • @RuiFRibeiro Latency seems about right for same-city connectivity with no high-latency link involved. (Traceroute shows 4 addresses within my ISP, a Cloudflare address at an internet exchange in my city, then 1.1.1.1.)
    – Håkan Lindqvist
    Oct 9, 2018 at 13:13
  • It seems that I can reach the Cloudflare DNS, only it fails for the domain for me. I've run nslookup for auth.otc.t-systems.com and serverfault.com. Here's the result from tcpdump: gist.github.com/thomas88/03acc781f45c9427863b1876c75acb4d
    – Thomas Obermüller
    Oct 9, 2018 at 13:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.