Newly installed; domain/NS not resolving globally, only locally + with hosts file mod

ieh

Verified User
Joined
Aug 5, 2019
Messages
13
Location
Williamsburg, VA
Just installed DirectAdmin yesterday on CentOS 7 64bit. I registered the domain isaac.solutions so I could get things running and do my testing with a fresh domain. At the registrar, I have set up custom NS for ns1/2.isaac.solutions pointing to the server's IP address and set that domain (along with ieh.im) to use ns1/2.isaac.solutions for nameservers.

Nothing is resolving.

I've edited my local hosts file and I can see isaac.solutions running on the server, so the site is responding to http requests if they make it to the server.

When I `dig isaac.solutions` on the server, it returns the proper A record, along with the proper NS records. When I dig from any other server, including @8.8.8.8 (Google), I get no A record. Also: https://dnschecker.org/#A/isaac.solutions shows nothing resolving.

nmap shows port 53 is open, and named appears to be running.

I do have A records for ns1/2.isaac.solutions in the isaac.solution zones, as well as NS records for same.

Should say - the single IP on the server is 54.39.132.52

What am I missing?

Disclaimer: I'm one of the recent converts to DirectAdmin coming from 20 years of cPAnel experience, so I know some things well, and am still learning other things. You know how it is. It feels like this is a dumb question, but I don't often have to peek under the belly of the beast, so I apologize in advance if I'm missing something simple.

Also, while I'm here, just want to say that I really like how DirectAdmin is set up so far. Already there are some really nice things I prefer over cPanel - logging into users and such is so much easier for a lazy admin! lol
 
Hello,

DNS service on the server is not accessible from outside:

Code:
# dig SOA isaac.solution  @54.39.132.52

; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.2 <<>> SOA isaac.solution @54.39.132.52
;; global options: +cmd
;; connection timed out; no servers could be reached

and it's confirmed by https://intodns.com/isaac.solutions and https://dnschecker.org/#A/isaac.solutions

make sure to stop/adjust firewall on your server and/or open ports at an OVH dashboard (they offer firewall too).
 
Thank you for that, that's a great start!

Okay, in OVH, for my server, looks like I don't have a firewall (nor the capability to order one), so seemingly I'm clear there.

I've done some googling - it looks to me like the two most probable I have are iptables or firewalld.

I do have an /etc/firewalld/zones/public.xml, but "which firewalld" doesn't return any results.

I do have iptables installed, `which` found it; but when I do `systemctl status iptables`, no service is found.

From my googling so far, and from what I know about services... it seems to me I'm not running either.

I apologize for being a noob on this - coming from cPanel using CSF, so this is a place I need to learn more.

Can you gently point me in a direction to figure out maybe what firewall I might be running on the server? Or how to interact with iptables? (Since as far as I can tell, that service is not running....)
 
Sorry, don't see where to edit my above post. I had googled before replying, but have continued to google trying to figure it out myself! Finally found something else that may be leading me in the right direction. I think I'm using iptables, so I'm testing that now. So please ignore my above reply for now. (I haven't solved it, but I'm no longer stumped for now)
 
I don't think I have any iptables rules?

$ iptables -S

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
 
$ iptables-save

# Generated by iptables-save v1.4.21 on Tue Aug 6 22:40:25 2019
*raw
:pREROUTING ACCEPT [231291:33464424]
:OUTPUT ACCEPT [198985:32747403]
COMMIT
# Completed on Tue Aug 6 22:40:25 2019
# Generated by iptables-save v1.4.21 on Tue Aug 6 22:40:25 2019
*nat
:pREROUTING ACCEPT [155516:9688536]
:INPUT ACCEPT [155516:9688536]
:OUTPUT ACCEPT [10951:770852]
:pOSTROUTING ACCEPT [10951:770852]
COMMIT
# Completed on Tue Aug 6 22:40:25 2019
# Generated by iptables-save v1.4.21 on Tue Aug 6 22:40:25 2019
*mangle
:pREROUTING ACCEPT [231291:33464424]
:INPUT ACCEPT [231291:33464424]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [198987:32747891]
:pOSTROUTING ACCEPT [198987:32747891]
COMMIT
# Completed on Tue Aug 6 22:40:25 2019
# Generated by iptables-save v1.4.21 on Tue Aug 6 22:40:25 2019
*filter
:INPUT ACCEPT [231291:33464424]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [198990:32748319]
COMMIT
# Completed on Tue Aug 6 22:40:25 2019
 
If the firewall is not the case, then named/bind9 is probably stopped:

Code:
$ telnet 54.39.132.52 53
Trying 54.39.132.52...
telnet: connect to address 54.39.132.52: Connection refused

The port 53 is either closed, or no service is running on it.

I can still connect to 80 port on your server:

Code:
$ telnet 54.39.132.52 80
Trying 54.39.132.52...
Connected to 54.39.132.52.
Escape character is '^]'.
^]
telnet>

So make sure named is running.
 
Named is definitely running. I successfully restarted it just now for fun:

$ systemctl status named

● named.service - Berkeley Internet Name Domain (DNS)
Loaded: loaded (/etc/systemd/system/named.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2019-08-07 01:11:45 EDT; 16s ago

Later on, it notes the PID is 7406, which matches with:

$ netstat -pnltu | grep 53
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 7406/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 7406/named
tcp6 0 0 ::1:953 :::* LISTEN 7406/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 7406/named

So this seems to imply that I either have a firewall I'm not aware of, or there's something at the datacenter.

I guess my next step, in addition to any other ideas you or others might have, is to open a ticket with OVH just to make sure I'm not missing something there.

I'm learning a few little tricks, though, so I really do appreciate the help. :)
 
The named is bind to 127.0.0.1 interface only. You need to set it to the public interface.
 
[solved]

BINGO!

Oh my goodness, all I had to do was update /etc/named.conf from "listen-on { 127.0.0.1; }" to "listen-on { any; }"

You are a LIFESAVER. And by that, I mean a little minty piece of candy with a hole in it. lol.

Seriously, I can't thank you enough. And yay, I've learned something else to look for.
 
Oh my goodness, all I had to do was update /etc/named.conf from "listen-on { 127.0.0.1; }" to "listen-on { any; }"
Did you change anyting then? Because after a DA isntallation this line in named.conf contains two dashes in front of it, so it won't be read.
This way the default is used. Normally it looks like this after DA installation:
Code:
options {
        //listen-on port 53 { 127.0.0.1; };
        //listen-on-v6 port 53 { ::1; };
So it's odd that it was enabled in your case.
 
This was all from the default OVH CentOS7 template and whatever DirectAdmin installed:

options {
//listen-on port 53 { 127.0.0.1; };
//listen-on-v6 port 53 { ::1; };
listen-on { 127.0.0.1; };
allow-recursion { 127.0.0.1; ::1; };

changed to

options {
//listen-on port 53 { 127.0.0.1; };
//listen-on-v6 port 53 { ::1; };
listen-on { any; };
allow-recursion { 127.0.0.1; ::1; };
 
I confirm, same problem on a server OVH (Centos 7) and I could fix the problem by reading the thread.
@ieh, thanks for posting the solution.
 
Sorry to bump just to say this, but thank you for saying that. I know I've seen all the jokes about people ending up saying things like "Oh, nevermind, solved!" and years later people finding that ONLY THREAD that describes their problem. Like the infamous xkcd: https://xkcd.com/979/

Glad this thread not only solved my problem but was helpful to someone else. :)
 
Well with OVH one needs to be very careful, their default templates are mot very good. Whenever a default template is used on metal-bare servers, they set 10-20Gb to the root partition, and all other Gbs/Tbs to /home/. Guess what issues will an user face?!
 
This was all from the default OVH CentOS7 template and whatever DirectAdmin installed:
That's strange, in all my default installations I can't remember ever seeing a second "listen-on statement and no 127.0.0.1 except for the first line. But I'm glad it's figured out now.

OVH? Bad service. We'll never be renting servers there again ever.
 
Back
Top