Best way to check if freebsd server is running a nameserver service/daemon

[Yuka]

Hi everyone,

I recently was assigned a project that requires me to fix up a FreeBSD webserver. I'm new to FreeBSD in general.

One of the issues with the webserver is a very broad DNS issue.

The domains that the client owns all point back to the webserver for their nameserver. As far as I can tell, it isn't running one, but I'm not 100% sure on this. To complicate matters worse, the admin that came before me had no clue what he was doing, so even if the server is running a nameserver... it cannot be trusted.

What's the best way for me figure out if the server is in fact running a nameserver daemon? I have root access to the server via SSH.

Thanks for all of your help.

[TerryP]

Check if the program 'named' is running and listening. I don't know off the top of my head if /etc/rc.d/named supports the status command or not (rc(8)), but finding out if it is running the hardway is still easy.


I'm not familiar with any of the dns/ apps in ports, so I can't say what name they would run under; but I'm sure someone here would point it out.


---

 
$ ps xa | grep named
   ... is named running?
$ cat /var/run/named/pid
   ... does the pid file exist?
$ netstat -n -p udp | grep 53
   ... is anything listening on the usual port?

-> Assuming that the standard issue name server was used, you may want to check named.conf first, in case the settings were changed. On FreeBSD I believe this is etc/namedb/named.conf.

[Yuka]

Actually that was what I was looking for. Thanks so much.

Now I have to fix this godforsaken install of named. Lots of work to be done.

[J65nko]

A nameserver will LISTEN on both UDP and TCP.

$ ssh j65nko@192.168.222.10 'netstat -an -f inet'
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
ip         0      0  *.*                    *.*                    1
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp        0      0  192.168.222.10.22      192.168.222.20.3160    ESTABLISHED
tcp        0      0  192.168.222.10.53      *.*                    LISTEN
tcp        0      0  127.0.0.1.587          *.*                    LISTEN
tcp        0      0  127.0.0.1.25           *.*                    LISTEN
tcp        0      0  *.22                   *.*                    LISTEN
tcp        0      0  127.0.0.1.8021         *.*                    LISTEN
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
udp        0      0  10.0.0.200.30510       213.206.97.167.123    
udp        0      0  10.0.0.200.14501       80.101.175.193.123    
udp        0      0  192.168.222.10.123     *.*           
udp        0      0  192.168.222.10.53      *.* 
udp        0      0  *.514                  *.*

UDP is mainly used. If the answer of a nameserver doesn't fit into the 512 byte long UDP packet, the server will set the truncated bit. This is an indication for the client to redo the query, but this time using TCP for a complete, not truncated answer.

[Yuka]

j65nko, thanks for that. It definitely helps.

Now I have to deal with domains that aren't resolving and a nameserver that is not being slaved to properly by the rest of the world. Joy!

[bsddaemon]

I would not monitor the service internally. If it is mission critical server, think about situations when the box itself is down, local connection problem, firewall misconfiguration...

To get a fairly accurate result, the services should be monitored with cron from more than 2 remote servers. You can buy hosting package with SSH access, otherwise, there are some websites that offer cron service without any charge.

If you wanna get a best result from monitoring, consider the following aspects when writting monitoring script:

- It is running and status is ok, but is the result returned correct?
- Does it take long to response?
...

[Yuka]

Originally Posted by bsddaemon

I would not monitor the service internally. If it is mission critical server, think about situations when the box itself is down, local connection problem, firewall misconfiguration...

To get a fairly accurate result, the services should be monitored with cron from more than 2 remote servers. You can buy hosting package with SSH access, otherwise, there are some websites that offer cron service without any charge.

If you wanna get a best result from monitoring, consider the following aspects when writting monitoring script:

- It is running and status is ok, but is the result returned correct?
- Does it take long to response?
...

I hear you on this. My company just won a contract to fix up this server and well... the guy who set up the server initially for the client did a really bad job. I'm cleaning up after him.

We'll probably use the namservers at the datacenter that the website is hosted in (nac.net).

[J65nko]

DNS master<->slave communication is the other case where TCP is being used. In case you run a packet filter, make sure that you allow both UDP and TCP.

Many problems relating to nameserver configuration issues are caused by the fact that the most popular nameserver BIND is a single monolithic program, that implements two totally different types of nameservers

1. An authoritative name server.
   
   This type of name server only can answer queries for which it is authoritative. It retrieves it's answers from the DNS zone file, as prepared by the DNS administrator. It has no knowledge of any other zone or domain.
   
   The IP address of an authoritative name server should never be entered as a nameserver in a /etc/resolv.conf file.
   
2. A caching recursive resolver
   
   Such a name server could be compared with a private detective, who has a network of informants (authoritative nameservers).
   
   The client of this private detective can ask questions about many different domains. The 'private eye" will then use his informants to answer those questions.
   
   The IP address of a caching recursive resolver is suitable for entering as nameserver in a /etc/resolv.conf file.

It is a recommended practice to separate these two roles even if you are using BIND. See http://www.isc.org/pubs/tn/isc-tn-2002-2.html

On my local network I am using DJBDNS, which has two separate programs for these two roles: tinydns is the authoritative one, dnscache is the caching recursive resolver.

They both run on a single box where the NIC has two IP addresses. dnscache listens on 192.168.222.10, while tinydns binds to 192.168.222.11. So I can directly query tinydns, which is the authoritative nameserver for my local domain utp.xnet.

An example query

$ dig +norecurse -t mx utp.xnet @192.168.222.11

; <<>> DiG 9.3.4 <<>> +norecurse -t mx utp.xnet @192.168.222.11
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21326
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; QUESTION SECTION:
;utp.xnet.                      IN      MX

;; ANSWER SECTION:
utp.xnet.               604800  IN      MX      0 mail.utp.xnet.

;; AUTHORITY SECTION:
utp.xnet.               259200  IN      NS      ns1.utp.xnet.

;; ADDITIONAL SECTION:
mail.utp.xnet.          604800  IN      A       192.168.222.10
ns1.utp.xnet.           259200  IN      A       192.168.222.11

;; Query time: 2 msec
;; SERVER: 192.168.222.11#53(192.168.222.11)
;; WHEN: Thu Nov  6 02:15:34 2008
;; MSG SIZE  rcvd: 97

Note that the aa flag for Authoritative Answer is being set.

In your case I would recommend to follow http://www.isc.org/pubs/tn/isc-tn-2002-2.html. That way you can easily first debug your authoritative nameservers and the master-slave stuff.

Second step would be to do either a manual recursive trace starting from the DNS root servers, or even easier by using http://www.squish.net/dnscheck/

his will check whether caching recursive resolvers get the proper referral to your authoritative nameserver(s).