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

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.

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.

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.

__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

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

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

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.

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.

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.