3

I am using BIND 9.10.3_P2 to setup DNS records for domain speedydrive.net. The domain itself has glue records on parent servers with 2 IP addresses for NS servers.

Everything looks fine except the fact that when I check if DNS is OK, I get this result:

Check DNS: http://www.intodns.com/speedydrive.net

It claims mismatching NS records, missing SOA, etc. Is there really a problem in the domain name configuration, or is it a problem of the intodns check tool which reports some bullshit? How can I check (using Linux command line) that the domain's DNS is configured properly?

I have one personal domain configured in EXACTLY the same way (only using different bind version 9.10.1_P1 on different servers IP addresses) and that domain reports no errors at all at intodns. There is also no firewall anywhere. So I am puzzled. Thank you

  • Posted an answer with relevant links. Cheers – Rui F Ribeiro Feb 9 '16 at 21:14
1

The issue is due to the difference between the DNS name using capitals, and a interaction between BIND changes and (now) buggy script/commands due to issues with case sensitivity.

This URL check_dig is case sensitive, together with this one check_dig: expected answer is now incasesensitive should shine a light in similar problems at the application/scripting level.

This is where the change that provoked the aforementioned behaviour in BIND 9.9.5 is documented: Case-Insensitive Response Compression May Cause Problems With Mixed-Case Data and Non-Conforming Clients

  • 1
    For now I rewrote my BIND config files to use lowercases everywhere, so all the check tools are not confused. This solution allows me to use my favorite check tool as usual, while using newest BIND versions on server. Thanks! – Tomas M Feb 11 '16 at 17:55
1

The info can be manually verified using the Linux command line tools whois and dig.

whois provides information from your domain registrar, most importantly your authoritative nameservers:

 $ whois speedydrive.net
 ... lots of registration info ...
 Name Server: ns1.speedydrive.net
 Name Server: ns2.speedydrive.net
 DNSSEC: unsigned

dig is a great low level tool for querying DNS servers directly. While there is a lot of detail to its use the basic use is dig -t <type> <query> @<server name or IP>

$ dig -t ns speedydrive.net @ns1.speedydrive.net
...
;; ANSWER SECTION:
SPEEDYDRIVE.NET.        3600    IN      NS      NS2.SPEEDYDRIVE.NET.
SPEEDYDRIVE.NET.        3600    IN      NS      NS1.SPEEDYDRIVE.NET.
$ dig -t ns speedydrive.net @ns2.speedydrive.net
...
;; ANSWER SECTION:
SPEEDYDRIVE.NET.        3600    IN      NS      NS1.SPEEDYDRIVE.NET.
SPEEDYDRIVE.NET.        3600    IN      NS      NS2.SPEEDYDRIVE.NET.

So those look pretty valid to me. I even tried querying the (different) IPs returned by a.gtld-servers.net and they also reported NS records. So I don't see anything that would agree with the note on that report:

WARNING: One or more of your nameservers did not return any of your NS records.

  • 3
    I would venture to guess their script is not accounting for the RR to be in all capitals...DNS makes no distinction on that. – Rui F Ribeiro Feb 1 '16 at 16:53
  • Interesting is that other domain which is configured exactly the same (with just the domain name and IP addresses different) has no errors at intodns.com – Tomas M Feb 1 '16 at 21:08
  • 2
    @RuiFRibeiro this was exactly the problem! Bind version 9.9.5 and above has a new feature, which returns names exactly as defined, while the older versions of bind made them lowercase. The tool at intodns.com expects to get lowercase so it fails to find the NS records even if provided, since I configured it uppercase. – Tomas M Feb 9 '16 at 9:13
  • 1
    @RuiFRibeiro please put this as answer to this question, and I will accept it. Thanks! – Tomas M Feb 9 '16 at 9:14

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.