Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I run a server which amongst other things uses tinydns for DNS and axfrdns for handling transfer requests from our secondary DNS (another system). I understand that tinydns uses port 53 on UDP and axfrdns uses port 53 on TCP.

I've configured axfrdns to only allow connections from my agreed secondary host. I run logcheck to monitor my logs and every day I see spurious connections on port 53 (TCP) from seemingly random hosts. They usually turn out to be from ADSL connections.

My question is; are these innocent requests or a security risk? I am happy to block repeat offenders using iptables but don't want to block innocent users of one of the websites I host.

Thanks, Darren.

share|improve this question

4 Answers 4

up vote -2 down vote accepted

I assume you are using the server as an authoritive DNS server for a domain name. If that is the case any client that would need to resolve a name that your server has authority for would only need to use UDP. TCP is to be used for zone transfers.

And i also asume that you do not want the world to be able to do zone transfers. While not a security risk in itself zone transfers are usually only allowed to the secondary/backup dns servers. Most dns software also has ACL's to controll wich server is allowed to do zone transfers so you also have a second method of restricting that. But since i see security as allow only what is needed i suggest that you block tcp on port 53 for hosts that dont need to do zone transfers from you.

As a side note, tcp connections from random adsl hosts on tcp port 53 have malicious intent. This is because no legit client should need to do zone transfers from you. They might be trying to access confidential information related to your network, or to explit vulnerabilities to certain DNS software.

While that is not something to be paranoid about it is something that you should be aware of.

share|improve this answer
    
Thanks for this. I will use iptables to lock it down to the hosts that act as secondaries (don't know why I didn't think of that before!). –  Darren Greaves Aug 11 '10 at 9:45
5  
@Darren - no, please don't. Blocking DNS on tcp/53 breaks legitimate traffic. –  Alnitak Aug 11 '10 at 14:07

TCP is not only used for zone transfers.

TCP is the default fallback used by DNS clients should your DNS server ever send back a truncated (TC=1) UDP response. This would happen if you are serving any data that exceeds 512 bytes in a single packet.

If you're running a DNS server then it should accept TCP connections from DNS clients, and there's no inherent security risk in doing so. There's a very slight risk of DoS attacks against the DNS server, but that's true of any public facing service.

See draft-ietf-dnsext-dns-tcp-requirements which should be published as an RFC within the next month.

See RFC 5966 for more details.

Ob disclaimer - I wrote that RFC.

share|improve this answer
    
As far as I know my DNS is not sending large packets - although I'd love to be able to test it to be sure. The thing is, I've been DENYing these requests all along - with no known problems - all I'm proposing doing now is changing that DENY to an iptables rule that drops the packet. –  Darren Greaves Aug 12 '10 at 6:27
1  
there's no risk from these packets, but if you insist on not answering them you'll get less network load if you REJECT rather than DROP the inbound connections. –  Alnitak Aug 12 '10 at 14:00
1  
Now that's what I call an authoritative answer. –  the-wabbit Jul 5 '12 at 23:17

The only things which should be using your host as a DNS server are

  • localhost
  • machines on your network that you set that host as the DNS server for

The simplest way to block "everything else" is to disable the service from listening on that address. If your own devices are outside "your network", use firewall rules (iptables or whatever) to only accept connections from your external network address(es). If they aren't fixed, you may need a VPN or other secure tunnel to bring the external hosts "inside your network".

Keep in mind that arbitrary DNS queries against your internal name server can potentially map out your entire network to an outside party and either present an attack vector or give away information that you'd rather not have the rest if the world having access to. "Random ADSL connection" could easily be zombie botnet machines being used to plan something nasty against you.

share|improve this answer
    
I already have dnscache listening on localhost only as a caching DNS server. I have tinydns and axfrdns listening on the public interface as I publish DNS for the domains on that machine and I need to allow zone transfers. –  Darren Greaves Aug 11 '10 at 9:51

There are many security risks by opening incomming TCP to the nameserver - anyone who does not claim this are not sane. Just look at the root compromise history - Most of is done by using TCP in combination with UDP. The old MUST and SHOULD RFC was crafted by folks who know about security. If you have DNS zones not using the TC=1 bit (or exeeding 512 bytes) - Dont enable incomming TCP, let the morons do that in the future.

share|improve this answer
    
Huh? Can you clarify what vulnerabilities you're talking about? –  Shane Madden Jul 5 '12 at 1:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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