1

Kubuntu (Ubuntu 14.04.2 LTS, kernel 3.13.0-48-generic) installed 2 months ago (not installed yet newest updates).

I have noticed that my resolver is failing:

root@arrakis:~# telnet onet.pl
telnet: could not resolve onet.pl/telnet: No address associated with hostname
root@arrakis:~# ssh onet.pl
ssh: Could not resolve hostname onet.pl: No address associated with hostname

strace and wireshark confirm that I am sending two DNS queries: A and AAAA and receive both answers - correct A and empty AAAA. Immediately after receiving the second response applications (telnet/ssh) sends that resolution error.

Everything is working fine when using google dns (8.8.8.8) - but not when using my company DNS.

OK, performed additional troubleshooting and tested google (8.8.8.8) and compared to my company DNS and the results are the following: when typing telnet www.onet.pl my local resolver always sends DNS query for A and AAAA records, and always got both answers. Also dig for both DNS server return similar (A IN record and empty AAAA IN record). But the difference working (google DNS) vs non working (company DNS) scenario is: flag recursive: google can do recursive and my company DNS server can not. That is the only difference. Why my local resolver does not want to accept response with recursion disabled (when having IN A address already provided) ?

From the user point of view working scenario (google DNS):

root@arrakis:/tmp# telnet onet.pl 80
Trying 213.180.141.140...
Connected to onet.pl.
Escape character is '^]'.

Non working scenario (company DNS):

root@arrakis:/tmp# telnet onet.pl 80
telnet: could not resolve onet.pl/80: No address associated with hostname

Attaching screenshots for both scenarios.

enter image description here

enter image description here

The only reasonable explanation I would see is: if in query i have "Recursion desired" and in response i do see it's not supported - then i would drop that response ? Could anybody confirm ? That would be a bit crazy since all DNS queries i am sending have "Recursion desired".... (as per my understanding of rfc1035 it's incorrect behavior and we should accept response)

There is one more small difference between working and non working scenario. For working (google DNS) A response includes just A IN with ip address. For non-working (company DNS) A response includes the same and additionally multiple additional authoritative servers. I guess that is normal since it's a response from non recursive server and are just the result of the previously mentioned difference. The fact the we do include A IN record additionally might be a bit odd (if we do return A IN record probably because it was cached before there is no need to return additional authority records) but i believe still should be acceptable.

Just to confirm, DNS response for A always return the correct entry in the answer section:

root@arrakis:/tmp# dig @8.8.8.8 www.onet.pl -t A | grep "213"
www.onet.pl.            15      IN      A       213.180.141.140
root@arrakis:/tmp# dig @173.38.200.100 www.onet.pl -t A | grep "213"
www.onet.pl.            60      IN      A       213.180.141.140

For the same request but "-t AAAA" we do not have answer section. Just authority.

I am currently using a very good workaround. I have bind server on my laptop with recursion enabled and forwarders pointing to both google and company DNS. And passing all that traffic via my bind. And everything is working fine - as expected.

To summary: a buggy behavior in linux in my opinion.

  • 1
    Have you tried running a DNS query? What's the output of that query? Use dig -v to see the actual messages, and try maybe using -t ANY instead of -t A to view all the data being returned. – Thomas Ward May 9 '15 at 21:30
  • root@arrakis# telnet www.wp.pl 25 telnet: could not resolve www.wp.pl/25: No address associated with hostname, "dig @173.38.200.100 www.wp.pl -t A" returning 2 A records. – user2913139 May 10 '15 at 6:45
  • 1
    edit your question and show us the complete result of the AAAA query with dig, proving that it truly is an empty RRset. – JdeBP May 10 '15 at 7:16
  • OK, performed additional troubleshooting and tested google (8.8.8.8) and compared to my company DNS and the results are the following: – user2913139 May 10 '15 at 14:58
  • @user2913139 EDIT your QUESTION with the outputs - otherwise there is no output available for us to see – Thomas Ward May 10 '15 at 15:37

Your Answer

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

Browse other questions tagged or ask your own question.