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.
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
Code:
$ 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).
