Slow DNS Resolution on Ubuntu Linux Server 14.05 LTS

Posted by & filed under Linux, Server Admin.

This all started with WordPress timeouts. I was trying to activate some premium plugins, and the license activation was timing out. I started doing some digging and found they use the WordPress core library WP_http which in turn uses curl to make the request. I wrote my own code to use WP_Http and it failed in the same way with a timeout. I added a timeout parameter to the wp_remote_get() call, and it was able to complete without a timeout. I then used a IP address in place of the domain name and it worked without the need for the timeout parameter.

With that info in hand, I decided it must be on the server. I started doing some tests:

I then did the same test from another server that uses the same DNS servers in resolv.conf:

After much googling, I found a few number of suggested solutions:

  • Disable IPv6
  • Ensure /etc/nsswitch.conf is set correctly (hosts: files dns)

Neither of these worked for me. Finally, I added the following directive into my resolv.conf and it fixed the issue!

Apparently, this is actually somewhat related to ipv6 — from the resolv.conf manpage:

Now, I get good response times when I curl:

Looks like the resolver sends parallel requests, fails to see the IPv6 response, waits 5 sec and sends sequential requests because it thinks the nameserver is broken. By adding the options single-request, glibc makes the requests sequentially be default and does not timeout.

I found some good info and hints on this issue here: https://bbs.archlinux.org/viewtopic.php?id=75770

Lastly, to bring this whole thing full circle, the WprdPress plugins now are able to get out and communicate successfully. Woohoo!

Enumerating a DNS zone by brute force

Posted by & filed under Linux, Server Admin.

Sometimes a situation pops up where I need to retrieve the contents of a DNS zone but do not have access to the DNS servers. This is typically a situation where a client’s IT person is no longer available and before moving the name servers, we need to recreate the DNS zone on our name servers. If the current host of the DNS zone cannot release the records, we have a few options.

1. Try a zone transfer. I previously wrote about this. This is highly unlikely to work, but if the DNS server is poorly configured, it’s a possibility. This works rarely but if it does work will be the most accurate.

2. Brute force the zone. It sounds bad, but the reality of it is that most sysadmins don’t log or throttle DNS requests, and therefore with a decent enough dictionary of words it is possible to enumerate a large majority of the dns zone. I have mirrored the zip file containing bfdomain and the dictionaries here. (original source)

UPDATE: One other thing that I noticed later on is the fact that this is seemingly only capturing A records, so things like the MX record would not be tried. The python script could be modified easily to add this functionality. Also, the nmap version of this may already do this.

More dictionaries and wordlists:
packetstormsecurity.org/Crackers/wordlis…
www.cotse.com/tools/wordlists1.htm
www.outpost9.com/files/WordLists.html
www.openwall.com/wordlists/
wordlist.sourceforge.net/
www.ai.uga.edu/ftplib/natural-language/m…
www.insidepro.com/dictionaries.php
www.room362.com/storage/saved/hugelist.t…

Dumping DNS Zones

Posted by & filed under Uncategorized.

It is possible to attempt to dump a zone using the AXFR parameter of the dig command:

$ dig -t AXFR @dns.server.domains.is.on.com domain.name.to.dump.com

Done! If the command fails withe “Transfer failed.” then the DNS server is properly secured against unauthorized zone transfers.

RFC 1918

Posted by & filed under DNS, Networking, Server Admin.

I recently setup a BIND dns server and after monitoring the logs for some time found lines like this:

RFC 1918 response from Internet for 0.10.168.192.in-addr.arpa

This means one of two things… either the bind server itself is querying the internet for local subnets and leaking info the the internet, or a DNS client queried them. Since the logs indicate the source IP, I know it is not the BIND server.

To remedy this, I enabled RFC1918 zones on the server to catch the queries before the leak to the internet. It ended up looking something like this:

zone "10.IN-ADDR.ARPA" {
type master;
file "empty";
};

zone "16.172.IN-ADDR.ARPA" {
type master;
file "empty";
};

...

zone "31.172.IN-ADDR.ARPA" {
type master;
file "empty";
};

zone "168.192.IN-ADDR.ARPA" {
type master;
file "empty";
};

empty:
@ 10800 IN SOA . . (
1 3600 1200 604800 10800 )
@ 10800 IN NS .

Removing MX records from a Microsoft DNS Server via script

Posted by & filed under DNS, Email, Programming, Server Admin.

We recently switched our barracuda system from using two equally weighted MX records to using one MX record that points to two same-named A records. We are hoping that this will help better load balance the Barracuda cluster. I wrote a quick-n-dirty batch script to remove the second barracuda MX record from our DNS zones:

for /f %%h in (domains.txt) do dnscmd /RecordDelete %%h @ MX 10 servername.net /f

This script takes the input file domains.txt and processes each domain contained in the text file. The format is one domain per line…