Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jul 2008 14:49:57 -0700
From:      Jeremy Chadwick <koitsu@FreeBSD.org>
To:        Doug Barton <dougb@FreeBSD.org>
Cc:        stable@freebsd.org, Eugene Grosbein <eugen@kuzbass.ru>
Subject:   Re: named.conf: query-source address
Message-ID:  <20080716214957.GA26869@eos.sc1.parodius.com>
In-Reply-To: <487E66D0.1050000@FreeBSD.org>
References:  <20080716162042.GA27666@svzserv.kemerovo.su> <20080716205705.GA25198@eos.sc1.parodius.com> <487E66D0.1050000@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 16, 2008 at 02:23:28PM -0700, Doug Barton wrote:
> Jeremy Chadwick wrote:
>> On Thu, Jul 17, 2008 at 12:20:42AM +0800, Eugene Grosbein wrote:
>>> I fully understand and second efforts on educating people
>>> how to configure BIND to be stong to attacks and keep them from using
>>> "query-source address" with "port" option but how about
>>> binding named to particular IP address when host has many of them?
>>
>> We do such on our authoritative nameservers.  The options we use:
>>
>>         listen-on       { 127.0.0.1; 72.20.106.4; };
>> 	query-source address 72.20.106.4;
>> 	transfer-source 72.20.106.4;
>> 	notify-source 72.20.106.4;
>>         interface-interval 0;
>>         use-alt-transfer-source no;
>
> Have you found those -source options to be necessary in practice? In  
> general named should be smart enough not to try reaching the outside  
> world on the loopback address.

It's not loopback I'm worried about.

The config parms we use are necessary.  Removing them will break DNS for
us breaks horribly (AXFRs failing due to ACLs on master servers,
recursive queries being made from the wrong src, NOTIFYs being sent from
the wrong src).

BIND will usually pick the first non-aliased IP to perform things from,
unless queries or other things come across a different network route, in
which case it'll respond with whatever IP it deems appropriate (based on
the routing table, I presume).  Showing our ifconfig will probably speak
for itself:

bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=1b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING>
        inet 72.20.106.2 netmask 0xffffff80 broadcast 72.20.106.127
        inet 72.20.106.3 netmask 0xffffffff broadcast 72.20.106.3
        inet 72.20.106.4 netmask 0xffffffff broadcast 72.20.106.4
        inet 72.20.106.5 netmask 0xffffffff broadcast 72.20.106.5
        inet 72.20.106.7 netmask 0xffffffff broadcast 72.20.106.7
        inet 72.20.106.8 netmask 0xffffffff broadcast 72.20.106.8
        inet 72.20.106.40 netmask 0xffffffff broadcast 72.20.106.40
        inet 72.20.106.41 netmask 0xffffffff broadcast 72.20.106.41
        ether 00:30:48:81:fc:8a
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active

The "interface-interval 0" option can be safely removed, but I do not see
the point in having BIND continually look for new IPs on an interface
when we want it only using a specific IP (that will never get removed
or changed on the fly).

"use-alt-transfer-source no" is an absolute must.  BIND tries to be
cute/smart about cycling through all IPs to attempt an AXFR, which is
behaviour that (IMHO) should be question in the first place.  The
comment I have in our named.conf explaining why we use it:

        # Do not attempt to use an alternative IP address for zone
        # transfers.  This keeps named from trying to use the main
        # IP address of the box if an xfer via transfer-source fails.

> Also, I'm guessing that you have more than one public IP address  
> configured on that box? Otherwise none of those options should be  
> necessary.

Correct -- and that's what Eugene was asking about.  :-)

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080716214957.GA26869>