Port 53 (DNS) seems blocked on fairly fresh install [SOLVED but mysterious cause]

Help! (Home for newbies)
1

Hello,

My old server was dying, so I backed everything up, bought a new server, installed a fresh Virtualmin*, and restored the backups (the old server was Virtualmin too). I touched little else apart from Webmin / Servers / BIND DNS / Update records to change every record from the old IP to the new, and rsyncing archive files – not config files.

Almost everything seems to work as expected – eg apache works, the virtualmin interface on 10000, ssh of course, etc – but, while the DNS server answers correctly when the query is run inside the server (server# dig @localhost mydomain), it does not seem accessible from the outside: other_machine# dig @myserver mydomain times out, from any other domain. In fact, the results are the same with a simple telnet on port 53: it works from inside, but not from outside. (telnet: Unable to connect to remote host: Connection refused). Including when the outside is another server by the same provider (OVH, France).

This suggests to me that port 53 is blocked somehow. I don’t see it there:

#iptables -nL | grep 53
ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 ctstate NEW
ACCEPT udp – 0.0.0.0/0 0.0.0.0/0 udp dpt:53 ctstate NEW

Nor do I see why restoring backups might have blocked it.

I’m at a loss here. I wonder if the DNS server was blocked before I restored my backups, but the only way to be sure would be to reformat, and I really would like to avoid that. (And at best it’d tell me whether the backups are responsible, not what’s wrong, so that I can fix it).

Keeping in mind that I’m not knowledgeable at all about that web stuff, is there something obvious that I have missed ?

Best regards,
G.

Operating system Debian Linux 9
Webmin version 1.870 Usermin version 1.720
Virtualmin version 6.02 Theme version Authentic Theme 19.04

2

My firewall handled by CSF and shows nothing about cstate NEW.

ACCEPT udp – 0.0.0.0/0 0.0.0.0/0 udp dpt:53
ACCEPT tcp – 0.0.0.0/0 0.0.0.0/0 tcp dpt:53

To test, Get ride of cstate NEW or add other lines with --state RELATED,ESTABLISHED. With just cstate NEW, only the first connection is allowed to 53 from said IP/connection. All others are blocked unless there is also a RELATED,ESTABLISHED line. So same connection couldn’t dig@ more than once.

Here’s some great info on NEW, Established, Related firewall lines. I may be changing my lines above based on the following.
https://serverfault.com/questions/578730/when-using-iptables-firewall-rules-why-assert-new-state-on-all-allowed-ports

And I’m no expert either.

3

I’ll look into that “ctstate” thing, thanks.

4

Strange;

my old server has no special firewall rules:

root@ks200697 { ~ }$ iptables -nL Chain INPUT (policy ACCEPT) target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

(my old server is: Operating system Debian Linux 6.0.10
Webmin version 1.851
Usermin version 1.720
Virtualmin version 6.00 )

5

Ok, I found the cause, and I would like to understand WHY it got that way:

In named.conf.options: I had

listen-on { 127.0.0.1; };
allow-recursion { 127.0.0.1; ::1; };

I replaced with
//listen-on { 127.0.0.1; };
listen-on port 53 {
any;
};
listen-on-v6 port 53 {
any;
};
recursion yes;
allow-recursion { 127.0.0.1; ::1; };

And now it works.

WHY ON EARTH would Bind be configured by default to only listen locally ??? Bear in mind that this is a fresh install.