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

Reply via email to