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

5 posts / 0 new
Last post
#1 Wed, 12/13/2017 - 10:19
Gamall

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

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

Wed, 12/13/2017 - 16:01
scotwnw

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-ru...

And I'm no expert either.

Thu, 12/14/2017 - 14:25
Gamall

I'll look into that "ctstate" thing, thanks.

Fri, 12/15/2017 - 08:59
Gamall

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 )

Sun, 12/31/2017 - 07:53 (Reply to #4)
Gamall

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.

Topic locked