Recursive queries fail if query source port is not fixed

Wed Aug 13 23:40:47 UTC 2008

* Jeff Lightner <jlightner at water.com> [2008-08-13]:
> 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.   

Thx for replying. As stated in the e-mail iptables does nothing[1]
and the Cisco router has no rules that limits traffic to port 53.
I just tested with "query-source port 40053;" and it worked without
any problems. (I even used tcpdump to verify that Bind used 40053
and not 53.) So the problem remains - recursive queries fails if the
query source port isn't fixed. (Any allowed fixed port number is OK.)

Hans

[1] iptables only contains a filter for port 22.

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