Balance DNS server not RFC 1035/7766 compliant?

Product Discussion Peplink Balance
1

Hi,

I am seeing a critical DNS issue and I am hoping someone here can point me in the right direction.

I am running Pi-hole for DNS security, and it appears that when a DNS response is truncated (which seems fairly common), Pi-hole retries the query over TCP port 53. I originally thought this was unusual, but from what I am reading it is normal DNS behavior.

The problem is that when Pi-hole tries TCP/53 against a Peplink Balance router, it fails with:

2026-01-11 01:31:49.538 TCP connection failed: Connection refused

Which would make sense as I’ve never seen a Peplink respond to DNS queries inside the LAN on TCP53

Normally I would assume this is Pi-holes fault for doing it in a weird way, but in this case it looks more like the Peplink may be the issue.

From what I understand, proper DNS behavior requires the resolver to support both UDP and TCP on port 53 (TCP is commonly used as a fallback when responses are truncated). If the Balance is refusing TCP/53 on the LAN side, that seems non-compliant with the international standards of DNS operation.

The key standards are:

RFC 1035 (Domain Names, implementation and specification)
Defines DNS over both UDP and TCP. It also describes the truncation mechanism: if a UDP response is too large and the server sets the TC (truncated) bit, the client is expected to retry using TCP.

RFC 7766 (DNS Transport over TCP, implementation requirements)
This is the modern, explicit requirement document for TCP. It states that DNS servers are expected to support DNS over TCP and that DNS clients should retry over TCP in truncation and other cases. (This RFC updates earlier guidance.)

RFC 5966 (DNS Transport over TCP, implementation requirements)
Older version of the same topic. It is largely superseded by RFC 7766, but it is useful background because it also makes the “TCP is required” point very directly.

Also worth noting:

Zone transfers require TCP (authoritative DNS operations): AXFR/IXFR are defined to run over TCP. See RFC 5936 (AXFR) and RFC 1995 (IXFR).

Given how fundamental this feature is to the correct operation of proper DNS, I find it hard to believe that an oversight this big made it through the balance guys QA (which usually puts milspec to shame), so I am assuming I screwed up during the config or I am missing a setting somewhere.

Is there a way to enable DNS over TCP (TCP/53) on Peplink Balance devices? I do not see an option for it in the UI, so I am wondering if it is located elsewhere or named differently.

Any help or guidance would be greatly appreciated.

2

@Rick-DC /cough… mr Pi-Hole king… any ideas :rofl:

3

Can you open up a ticket so I can check? The link is here

4

Sure thing. Heading there now.

I bypassed the Peplink and pointed directly to a different DNS server, and the errors and weird behavior immediately went away. So it definitely looks like TCP port 53 being closed. has something to do with it.

What’s interesting is that I’ve seen odd DNS behavior across multiple installs for years and never really understood why. It was never bad enough to be unusable, just inconsistent. For example, some websites would randomly take two tries to load, or a request would hang and then work fine after hitting refresh. We always assumed it was the local carriers and it happens very sporadically and randomly.

After installing Pi-hole, those issues noticeably decreased, which makes me wonder if the Peplink not supporting TCP 53 might have been the root cause all along. We’ve always pointed DNS to the router so we can use local DNS records, so this could explain a lot.

5

Hey Alvaro. Near the end of last year we took almost all PiHoles for which we were responsible out of service. While they “worked” well and were cost effective, the downsides were way too much maintenance needed and “non computer types” had difficulties being admins. We switched to NextDNS for those installations requiring such services.

6

@Alvaro_Cortes do you have DNS caching enabled on the peplink?

Port 53 being blocked reminds me a lot of this issue I have been fighting: Outbound Policy + VLAN bug in 8.5 and 8.4.1 - #16 by soylentgreen

7

What I’ve seen doesn’t look like that issue.

I was surprised that TCP was now required, I had always thought it was optional like RFC 7766 notes. So I sent a connection to one of my units on TCP/53, and it was rejected. I used a command like:

nc -router- 53

The packet trace show the SYN packet going out, and immediately a RST coming back. That’s a classic, no one’s hooked anything up to that port. (Though possibly a firewall banning it.)

The traceroute in the linked bug shows an ICMP response of port unreachable. That seems to be a weird response I wouldn’t expect from the target unit, but from an intermediate router.

Messing with the DNS settings on the targeted unit doesn’t make the issue go away like it does in the linked bug.

1 Like