1

I run a "hidden primary master" DNS setup on BIND, so only secondaries are visible to the outside world. The firewall currently permits traffic from the Internet to both udp/53 and tcp/53 on the secondaries and everything seems to work fine.

Each day however, I see a load of "refused notify from non-master" log entries from external addresses that have nothing to do with me. I understand what the log entries are telling me there, but I'd rather not have all this "noise" in my logs.

As only the secondaries are Internet-facing, can I safely deny tcp/53 traffic from the Internet to prevent the "refused notify from non-master" entries, or is there a good reason to allow tcp/53 traffic to the secondaries? The master is behind the same firewall and would not be affected by the this firewall change.

Improve this question
0

4 Answers 4

Reset to default
3

TCP is also used if the answer is exceeding 512 bytes, not only for zone transfers.
I wouldn't block this on your firewall.

Improve this answer
1
  • 2
    Also, the IIS SMTP proxy uses TCP for all its DNS resolution. This caused quite a bit of trouble.
    – Stephane
    Commented May 18, 2012 at 11:12
2

The standard mechanism is that dns server truncates response is it is larger than 512 bytes. DNS client should re-send query using TCP to get full response. IPv6 AAAA and DNSSEC queries response can easily fall out of 512-byte limit. CNAME queries with long hostname can also be over this limit.

You can block tcp/53 port on your firewall if you are sure that your CNAME's are not too long and you do not plan using DNSSEC and IPv6 resolution.

You should also check why are you getting notifies from outside. It means that your IP is listed in NS records of some domain. Sniff this notifies, if possible - it may indicate that your dns configuration is different with what you think.

Improve this answer
2
  • Your point about why I'm receiving them is a good one. I see the "refused notify from non-master" entries for all of the domains we host. Upon closer inspection I can see that all the notifies are coming from just three addresses (I don't recognise any of them). Next step is to find out what they are and why they're doing this, I guess - thanks for the suggestion.
    – Jamie MacIsaac
    Commented May 18, 2012 at 11:11
  • Just for info - found out what the source of the "refused notify from non-master" messages was. One of the other secondaries (operated by a third party) is actually an anycast cluster. Some of the nodes in this cluster appear to be misconfigured and are attempting to talk to my secondaries using one of their own unicast addresses rather than the multicast address. These unicast addresses are the "external addresses that have nothing to do with me".
    – Jamie MacIsaac
    Commented Dec 20, 2013 at 14:27
1

I assume the (unstated) logic that you're applying in this instance is assuming that DNS only uses TCP for zone transfers, and since you're not doing zone transfers to the Internet, you feel that it ought to be safe to cut off TCP port 53 traffic from the Internet to your secondaries.

To formulate an answer, you first need to understand why DNS uses both UDP and TCP, and when it uses one or the other.

The original DNS spec states that the maximum size for a UDP DNS packet is 512 bytes. If an answer would exceed this, the server asks the client to resend the request using TCP, and the server provides the answer over TCP. Note this isn't just for zone transfer, but for any large answer. A typical DNS answer packet would generally be small enough to fit within the limit, but the bottom line is that you must allow TCP to your DNS servers as well, even if you're not doing zone transfers to the Internet.

Improve this answer
1

See RFC 5966. Strictly speaking that RFC applies to DNS software implementors, but it explains why operators of DNS servers should permit TCP too.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .