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
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 (
ssh) sends that resolution error.
Everything is working fine when using google dns (188.8.131.52) - but not when using my company DNS.
OK, performed additional troubleshooting and tested google (184.108.40.206) 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 220.127.116.11... 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.
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 @18.104.22.168 www.onet.pl -t A | grep "213" www.onet.pl. 15 IN A 22.214.171.124 root@arrakis:/tmp# dig @126.96.36.199 www.onet.pl -t A | grep "213" www.onet.pl. 60 IN A 188.8.131.52
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.