bind and firewall opinion is needed

Sergey Nikolaev

unread,

Apr 24, 2001, 11:56:03 AM4/24/01

to

Hi,

In the case when the master is behind firewall (hidden from the internet) and
the secondary is in front of firewall (exposed to the internet), to facilitate
zone transfers
FW rules are required that allow bidirectional udp port 53 and unidirectional
tcp port 53
from secondary to primary.

While this configuration has some security advantages, it has drawbacks too.
If the secondary is compromised, there is the open incoming hole to the primary,
tcp and udp port 53 .

Is there a workaround? Other ways to transfer zones? Maybe, outgoing master to
secondary transfer is possible?

Thanks in advance,

Sergey

Kevin Darcy

unread,

Apr 24, 2001, 5:56:06 PM4/24/01

to

Sergey Nikolaev wrote:

> Hi,
>
> In the case when the master is behind firewall (hidden from the internet) and
> the secondary is in front of firewall (exposed to the internet), to facilitate
> zone transfers
> FW rules are required that allow bidirectional udp port 53 and unidirectional
> tcp port 53
> from secondary to primary.

I assume when you say "unidirectional" you mean that connections can only be
*initiated* in one direction, right? The packets still need to flow in
*both* directions in order for a TCP connection to be established and pass data.

> While this configuration has some security advantages, it has drawbacks too.
> If the secondary is compromised, there is the open incoming hole to the primary,
> tcp and udp port 53 .
>
> Is there a workaround? Other ways to transfer zones? Maybe, outgoing master to
> secondary transfer is possible?

There is no IETF standard for a "push"-based method of DNS zone transfer.

If you're really that paranoid, consider another method of master/slave
replication. Dan Bernstein recommends rsync-over-ssh, although I've never tried
that myself. When using an alternative replication method, you would define all of
the servers as "master" in named.conf and issue a reload after each transfer so
that each "slave" will pick up the changes.

And, if you are that paranoid, you are already a) running unprivileged, b) running
chroot()'ed, and c) keeping your BIND software faithfully up-to-date,
right?
- Kevin

Me

unread,

Apr 24, 2001, 6:33:07 PM4/24/01

to

Put them both behind the firewall and open up UDP from the Internet to
the secondary only. Use a disk imaging program, such as Powerquest's
Drive Image Pro v4 to create a disaster recovery backup (assuming you're
running on an Intel processor or could install the hard drive
temporarily in an Intel box). Don't allow either the master or secondary
to have domain accounts so they are the only things that could get
compromised. If they are, just restore the backup image and the current
backup of the zone files.

Ray

Sergey Nikolaev

unread,

Apr 25, 2001, 3:35:41 PM4/25/01

to

The main idea of the scenario I described, or rather of a would be scenario, is
that
only secondary can be compromised. And if it is compromised, it should not lead
to
compromising any internal hosts. The way DNS zone transfers work doesn't seem to
offer a complete
secure solution, does it?

In the scenario you suggested not only the secondary
can be compomised but whole internal network can be compromised once the
secondary is compromised.

Regards,

Sergey

"Me" <re...@here.only> on 04/24/2001 04:58:35 PM

Please respond to "Me" <re...@here.only>

To: comp-protoc...@moderators.isc.org
cc: (bcc: Sergey Nikolaev/SIAC)
Subject: Re: bind and firewall opinion is needed

Ray

-- Binary/unsupported file stripped by Listar --
-- Type: application/octet-stream
-- File: att1.eml