Re: How to stop BIND from using high ports?
On Tue, Jan 28, 2003 at 11:29:28AM +0100, Mark wrote:
I am having a bit of a problem. One might say, a serious problem. :( When
other servers query my name servers, they send queries with a source port of
53; but apparently my BIND (8.3.4) is responding from a high port (seemingly
random). And this is causing some trouble. :( How can I prevent that??
In my options section I have
query-source address * port 53;
Looks right to me. You might also want to investigate:
transfer-source 81.2.69.218 port 53;
notify-source 81.2.69.218 port 53;
if you have off-site secondaries. Check that the syntax is correct
for Bind8 --- I just copied that out of my Bind9 config.
But my log is filled with entries like these:
Accept UDP 10.0.0.2:53 194.112.32.1:1024 out via rl0
Accept UDP 10.0.0.2:53 209.73.14.10:38992 out via rl0
Accept UDP 10.0.0.2:53 165.250.91.52:53 out via rl0
Accept UDP 10.0.0.2:53 209.73.14.10:38992 out via rl0
Accept UDP 10.0.0.2:53 15.243.160.33:32857 out via rl0
Accept UDP 10.0.0.2:53 194.205.246.130:42876 out via rl0
Accept UDP 10.0.0.2:53 198.49.218.20:53 out via rl0
Accept UDP 10.0.0.2:53 203.2.75.109:53 out via rl0
Accept UDP 10.0.0.2:53 146.18.16.248:53 out via rl0
Accept UDP 10.0.0.2:53 15.251.160.31:32852 out via rl0
Accept UDP 10.0.0.2:53 15.251.160.31:32852 out via rl0
Which seems to suggest that for outgoing UDP a random high port is being
used. :( And I do not understand why. :(
I assume that 10.0.0.2 is the IP number of your DNS machine. Then it
would appear to be doing exactly what it's been told to. All the
replies it sends have the source IP address of the machine and the
*source* port 53. Your nameserver is either responding to packets
from a resolver out on the internet somewhere, or querying a remote
server for DNS data on your behalf. In the second case, the
destination port must be 53 in order to contact a nameserver, but the
source port could be anything, and it's usual to use an arbitrary
high-numbered port.
Incoming packaets in the first case will have whatever source port the
remote machine felt like using, which is outside the scope of what you
can control. Your machine has to respond back to the given IP and
port number, or the other end won't be able to connect the reply it
receives with the query it sent out.
I have only four ipfw rules defined regarding DNS:
${fwcmd} add 3 allow tcp from any to any 53 out via ${outside}
${fwcmd} add 4 allow udp from any to any 53 out via ${outside}
${fwcmd} add 5 allow tcp from any 53 to any in via ${outside}
${fwcmd} add 6 allow udp from any 53 to any in via ${outside}
Hmmm... I use dynamic rules to achieve the same goal:
add 1000 allow tcp from any to 81.2.69.218 22,25,53 setup keep-state in recv de0
add 1600 allow udp from 81.2.69.218 to any 53 keep-state out xmit de0
add 1700 allow udp from any to 81.2.69.218 53 keep-state in recv de0
So 1600 matches the first packet when I try and look something up
remotely, and the generated dynamic rule permits the response to come
back in only from the machine I queried. Similarly 1700 lets remote
systems query me and the generated rule permits the response back out.
Rule 1000 permits TCP connections into my DNS (ie. generally my
secondaries doing an AXFR when my zone data gets updated) amongst
other services, and I have a generic rule that lets me do any outward
going tcp connection I want.
This works very well for a lightly loaded server --- it even copes
with the sudden flood of DNS traffic when I send messages to the
thousands of recipients on this list. If your DNS traffic is
considerably higher than mine, then you might prefer to use static
rules, but you'll have to add two extra rules corresponding to the
packets in reply to queries:
add 1600 allow udp from 81.2.69.218 to any 53 out xmit de0
add 1650 allow udp from any 53 to 81.2.69.218 in recv de0
add 1700 allow udp from any to 81.2.69.218 53 in recv de0
add 1750 allow udp from 81.2.69.218 53 to any out xmit de0
Obviously, this opens you up to rather more malicious traffic than the
stateful version, but that's a judgement you'll have to make.
TCP connections can be handled similarly, taking account of the
'setup' vs 'established' state change.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-questions in the body of the message
Re: How to stop BIND from using high ports?
- Original Message - From: Matthew Seaman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 1:52 PM Subject: Re: How to stop BIND from using high ports? On Tue, Jan 28, 2003 at 11:29:28AM +0100, Mark wrote: I am having a bit of a problem. One might say, a serious problem. :( When other servers query my name servers, they send queries with a source port of 53; but apparently my BIND (8.3.4) is responding from a high port (seemingly random). And this is causing some trouble. :( How can I prevent that?? In my options section I have query-source address * port 53; Hi Matthew, Yours was a very useful reply. :) I truly appreciate your time and effort here. And your dynamic rules were equally useful. Looks right to me. You might also want to investigate: transfer-source 81.2.69.218 port 53; notify-source 81.2.69.218 port 53; if you have off-site secondaries. Check that the syntax is correct for Bind8 --- I just copied that out of my Bind9 config. I don't think you can specify a port for transfer-source in BIND 8.x, but as I only allow XFRs from trusted parties, this should not be an issue, I think. But my log is filled with entries like these: Accept UDP 10.0.0.2:53 146.18.16.248:53 out via rl0 Accept UDP 10.0.0.2:53 15.251.160.31:32852 out via rl0 Accept UDP 10.0.0.2:53 15.251.160.31:32852 out via rl0 Which seems to suggest that for outgoing UDP a random high port is being used. :( And I do not understand why. :( I assume that 10.0.0.2 is the IP number of your DNS machine. Yes. Then it would appear to be doing exactly what it's been told to. All the replies it sends have the source IP address of the machine and the *source* port 53. You know what? You are absolutely right. :) I guess I read it wrong, in my panic (kernel is not the only one prone to panic attacks). Problem is, an ISP in Australia cannot resolve me; and, as I wrote the admin, he responded: Our name servers are configured to send queries with a source port of 53 .. but when we do so, you respond from a high port? ... I suspect that bind is throwing away your replies because they don't match the expected response ip/port combination. I tried to resolve my domain name via their name server (ns1.optusnet.com.au = 203.2.75.2), and, indeed, that fails. He gave me the following log entries, though: --[ with src port = 53 ] 15:33:03.472128 210.49.20.142.domain 194.109.160.70.domain: [udp sum ok] 6636 A? asarian-host.net. [|domain] (ttl 64, id 13043, len 62) 15:33:03.802488 194.109.160.70.34336 210.49.20.142.domain: 6636*- q: A? Here it seems my BIND is indeed replying with a source port of 34336. Very peculiar. I have no idea how this is possible. :( Again, thank you for your time and energy. If you have any more bright ideas, not meant sarcastically, be sure to tell me. :) - Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
Re: How to stop BIND from using high ports?
On Tue, Jan 28, 2003 at 04:11:51PM +0100, Mark wrote: - Original Message - From: Matthew Seaman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 1:52 PM Subject: Re: How to stop BIND from using high ports? On Tue, Jan 28, 2003 at 11:29:28AM +0100, Mark wrote: I assume that 10.0.0.2 is the IP number of your DNS machine. Yes. Then it would appear to be doing exactly what it's been told to. All the replies it sends have the source IP address of the machine and the *source* port 53. You know what? You are absolutely right. :) I guess I read it wrong, in my panic (kernel is not the only one prone to panic attacks). Problem is, an ISP in Australia cannot resolve me; and, as I wrote the admin, he responded: Our name servers are configured to send queries with a source port of 53 .. but when we do so, you respond from a high port? ... I suspect that bind is throwing away your replies because they don't match the expected response ip/port combination. I tried to resolve my domain name via their name server (ns1.optusnet.com.au = 203.2.75.2), and, indeed, that fails. He gave me the following log entries, though: --[ with src port = 53 ] 15:33:03.472128 210.49.20.142.domain 194.109.160.70.domain: [udp sum ok] 6636 A? asarian-host.net. [|domain] (ttl 64, id 13043, len 62) 15:33:03.802488 194.109.160.70.34336 210.49.20.142.domain: 6636*- q: A? Here it seems my BIND is indeed replying with a source port of 34336. Very peculiar. I have no idea how this is possible. :( Is your nameserver perhaps behind a NAT gateway? Does this option from the natd(8) man page seem relevant to you? -same_ports | -m Try to keep the same port number when altering outgoing pack- ets. With this option, protocols such as RPC will have a better chance of working. If it is not possible to maintain the port number, it will be silently changed as per normal. I've seen a similar effect with NTP passing through a NAT'ing firewall before now. NTP expects both source and destination ports to be 123, and it got perplexed by packets sent to port 123 apparently from some high numbered port. The -same_ports option will mostly work, but the only completely effective answer is to provide nameservice from an internet registered address. As it seems that ns1.asarian-host.net and ns2.asarian-host.net are both the same machine (or at least, are sharing the same IP address) which is therefore your one and only registered IP number and probably your NAT gateway, I think your best bet is to find someone on a different part of the net to 2ary for you. If your ISP won't do it or is too expensive, look at eg. http://www.gradwell.com/services/sec_dns.cfm?cfid=258474cftoken=21163252 (Which, I happen to know, is hosted on FreeBSD boxes) You can always set up your machine as domain master (so you control the content), but register the domain using a couple of well connected secondary NS's (which will get all the traffic). Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK msg17003/pgp0.pgp Description: PGP signature
SOLVED! (was: Re: How to stop BIND from using high ports?)
- Original Message - From: Matthew Seaman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 28, 2003 5:31 PM Subject: Re: How to stop BIND from using high ports? On Tue, Jan 28, 2003 at 04:11:51PM +0100, Mark wrote: --[ with src port = 53 ] 15:33:03.472128 210.49.20.142.domain 194.109.160.70.domain: [udp sum ok] 6636 A? asarian-host.net. [|domain] (ttl 64, id 13043, len 62) 15:33:03.802488 194.109.160.70.34336 210.49.20.142.domain: 6636*- q: A? Here it seems my BIND is indeed replying with a source port of 34336. Very peculiar. I have no idea how this is possible. :( Is your nameserver perhaps behind a NAT gateway? Does this option from the natd(8) man page seem relevant to you? -same_ports | -m Try to keep the same port number when altering outgoing packets. With this option, protocols such as RPC will have a better chance of working. If it is not possible to maintain the port number, it will be silently changed as per normal. Matthew, you're a genius!! :) Although I do not have the NAT daemon running, I suddenly realized my hardware router does NAT too. You were so right! Even though the hardware NAT has no redirection defined for outgoing ports, this is, in fact, exactly what happened, just as you predicted. :) I disabled it altogether (I just used it for incoming port-redirection to several machines on my LAN, but I now solved that otherwise), and lo and behold, all problems are immediately gone and everything resolves again. :)) I'm impressed! Matthew, you're the man! :) - Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
