Recursive queries fail if query source port is not fixed

[Jeff Lightner]

My guess is you have a firewall that is only allowing port 53 outbound.

Are you running iptables?  If so does turning it off temporarily resolve
the issue?  Is there a firewall/switch upstream from your server that
needs to be adjusted?

We're running RHEL 5 with 9.3.4-P1 and it works fine here without the
query port specified.   

-----Original Message-----
From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
Behalf Of Hans F. Nordhaug
Sent: Wednesday, August 13, 2008 3:36 AM
To: bind-users at isc.org
Subject: Recursive queries fail if query source port is not fixed

(Posted to the news group earlier, but reposting to the mailing list
since moderation of group seems to be slow.)

In the quest for securing the name servers in a company I try to help,
I have gotten into to trouble. The company is running CentOS 5.0 and I
have updated their Bind to 9.3.4_P1. In addition, I planned to remove
the "query-source port 53;" from /etc/named.conf so the servers aren't 
vulnerable to cache poisoning.

The problem is that recursive queries fails if I remove 
"query-source port 53;". I have check iptables on the servers and the 
rules on the Cisco ASA and there isn't anything limiting the traffic
to port 53 - which I think the dumps below (from tcpdump) confirms.

(I have tested with a lookup on for the A record for www.uib.no.)

Output from tcpdump when query-source = 53:

16:02:22.263932 IP g4.tibe.no.domain > i.root-servers.net.domain:  50269
[1au] A? www.uib.no. (39)
16:02:22.263988 IP g4.tibe.no.domain > i.root-servers.net.domain:  46377
[1au] NS? . (28)
16:02:22.279513 IP i.root-servers.net.domain > g4.tibe.no.domain:
50269- 0/6/7 (246)
16:02:22.280013 IP i.root-servers.net.domain > g4.tibe.no.domain:
46377*- 13/0/20 NS G.ROOT-SERVERS.NET.,[|domain]
16:02:22.281367 IP g4.tibe.no.domain > x.nic.no.domain:  49597 [1au] A?
www.uib.no. (39)
16:02:22.297003 IP x.nic.no.domain > g4.tibe.no.domain:  49597- 0/4/5
(189)
16:02:22.297889 IP g4.tibe.no.domain > nn.uninett.no.domain:  62217
[1au] A? www.uib.no. (39)
16:02:22.320987 IP nn.uninett.no.domain > g4.tibe.no.domain:  62217*-
2/5/5 CNAME webber.uib.no., (247)
16:02:22.322167 IP g4.tibe.no.domain > alf.uib.no.domain:  23507 [1au]
A? webber.uib.no. (42)
16:02:22.343475 IP alf.uib.no.domain > g4.tibe.no.domain:  23507*- 1/5/5
A webber.uib.no (229)

Output from tcpdump when query-source != 53:

16:00:54.387047 IP g4.tibe.no.53099 > i.root-servers.net.domain:  13547
[1au] A? www.uib.no. (39)
16:00:54.402614 IP i.root-servers.net.domain > g4.tibe.no.53099:  13547-
0/6/7 (246)
16:00:54.403877 IP g4.tibe.no.58817 > njet.norid.no.domain:  13667 [1au]
A? www.uib.no. (39)
16:00:54.524293 IP njet.norid.no.domain > g4.tibe.no.58817:  13667-
0/4/5 (189)

(What's going on?)

I have also turned on debugging in Bind for a failed query. From 
/var/named/data/named.run:

client 213.161.248.67#42873: UDP request
client 213.161.248.67#42873: view external: using view 'external'
client 213.161.248.67#42873: view external: request is not signed
client 213.161.248.67#42873: view external: recursion available
client 213.161.248.67#42873: view external: query
client 213.161.248.67#42873: view external: query (cache) 'uib.no/A/IN'
approved
client 213.161.248.67#42873: view external: replace
clientmgr @0x8655330: createclients
clientmgr @0x8655330: recycle
client @0x87b1a18: udprecv
createfetch: uib.no A
fctx 0xb420a110(uib.no/A'): create
fctx 0xb420a110(uib.no/A'): join
fetch 0xb4215928 (fctx 0xb420a110(uib.no/A)): created
fctx 0xb420a110(uib.no/A'): start
fctx 0xb420a110(uib.no/A'): try
fctx 0xb420a110(uib.no/A'): cancelqueries
fctx 0xb420a110(uib.no/A'): getaddresses
fctx 0xb420a110(uib.no/A'): query
fctx 0xb420a110(uib.no/A'): done
fctx 0xb420a110(uib.no/A'): stopeverything
fctx 0xb420a110(uib.no/A'): cancelqueries
dns_adb_destroyfind on find 0xb42146e8
dns_adb_destroyfind on find 0xb4213e98
dns_adb_destroyfind on find 0x86a94a0
dns_adb_destroyfind on find 0xb4210dc8
dns_adb_destroyfind on find 0xb4201038
dns_adb_destroyfind on find 0xb4203c78
dns_adb_destroyfind on find 0xb4215310
dns_adb_destroyfind on find 0x86a8b10
dns_adb_destroyfind on find 0xb420de68
dns_adb_destroyfind on find 0x872d7e0
dns_adb_destroyfind on find 0x87b7d60
dns_adb_destroyfind on find 0xb42157e8
dns_adb_destroyfind on find 0x8733570
fctx 0xb420a110(uib.no/A'): sendevents
fetch 0xb4215928 (fctx 0xb420a110(uib.no/A)): destroyfetch
fctx 0xb420a110(uib.no/A'): shutdown
fctx 0xb420a110(uib.no/A'): doshutdown
fctx 0xb420a110(uib.no/A'): stopeverything
fctx 0xb420a110(uib.no/A'): cancelqueries
client 213.161.248.67#42873: view external: error
<----------------------------
fctx 0xb420a110(uib.no/A'): destroy
client 213.161.248.67#42873: view external: send
client 213.161.248.67#42873: view external: sendto
client 213.161.248.67#42873: view external: senddone
client 213.161.248.67#42873: view external: next
client 213.161.248.67#42873: view external: endrequest

It's clear that recursion is available. I guess the "view external:
error" might mean something, but I'm lost. If you need more info, want
me to test against our DNS server and so on - jusr let mer know.

I have tried Googling (the web and this group/mailing list), but found
it very hard to narrow the search down to something useful.

Regards,
Hans Nordhaug
----------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------