ipv4, ipV6 DNS BIND configuration and deployment

Noel Butler noel.butler at ausics.net
Mon Aug 5 02:17:38 UTC 2013

On Sun, 2013-08-04 at 13:28 -0700, Eduardo Bonsi wrote:

> Hello Everyone,
> I have some questions about ipV6 transition and DNS configuration!
> I am preparing to make my transition to a dual stack ipv4, ipv6 and I 
> have some concerns in regards to the security of the network since ipv6 
> do not have NAT. My ISP gave me a Global 
> 2602:000:000:000:000:000:000:000/64 Range and I can just turn on ipV6 on 
> the router and set the network to automatic on the computer and I am 
> connected through what they call a SLAAC ipV6 automatic conf network, 
> that runs using the machine MAC address in which I am not very happy to 
> adopt. I well know there is a way to mask the MAC address to random 
> addresses as a security measure but I am still not happy about it. 
> Beside, there are all the BIND DNS configuration that needs to be routed 
> or I am stack with a slow broke SLAAC connection that it works, but not 
> to the level of the a DNS Server that I want to achieve. Therefore, as a 
> network design after analyzing my options, I have decided to use the 
> static ipv4, ipV6 deployment approach that uses my ipV6 with the 3 last 
> bit of the ipv4 NAT addresses already in place. This static option does 
> not expose the machine MAC addresses. However the addresses are directed 
> connected through ipV6 bypassing the NAT environment. On BIND, the only 
> change I have in the named.conf file is the,
> listen-on-v6 { any; };

listen-on-v6  ::1 and your dns server ipv6 address

> Therefore, here are my questions:
> 1. I am open to ideas or anything you think is best choosing the best 
> internal network design for ipV6.

Static IP assignments on your LAN, as far as your ISP is concerned they
will just route your /64 via your routers IP. sure you can do auto
assignments, but I think if they are servers its best to do static.

> 2. Since this static ipV6 deployment lacks the non-rotatable NAT 
> environment, what are the security measures to take on BIND in regards 
> to the recursive issues on ipV6?

with ipv6, no more do you have security by accident (NAT)  if you have
a /64 your router will route for all, forget all the bad habits of the
lazy ipv4 days, now you need to configure access lists on your router,
but also play it safe and configure firewalls on each machine,
especially if they are winblows boxes

> 3. Are there any other security issues that should I considerate?

Don't be over aggressive with filtering, you do not mention the OS, but
if its linux -

ip6tables -P INPUT DROP
ip6tables -P OUTPUT ACCEPT
ip6tables -P FORWARD DROP

ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A INPUT -s fe80::/10 -j ACCEPT 
ip6tables -A INPUT -d ff00::/8 -j ACCEPT
ip6tables -A INPUT -p tcp -m tcp --dport 22 -m state --state INVALID,NEW
-j LOG
ip6tables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

... insert ACCEPT's for your lan and whatever other ipv6 addresses you
need with full access here...

ip6tables -A INPUT -p udp -d you:ipv6:dns:server:address --dport 25 -j
ip6tables -A INPUT -p tcp -d you:ipv6:dns:server:address --dport 25 -j

and.. importantly..
ip6tables -A INPUT -p icmpv6 --icmpv6-type 1 -j ACCEPT    # Destination
ip6tables -A INPUT -p icmpv6 --icmpv6-type 2 -j ACCEPT    # Packet too
ip6tables -A INPUT -p icmpv6 --icmpv6-type 3 -j ACCEPT    # Time
ip6tables -A INPUT -p icmpv6 --icmpv6-type 4 -j ACCEPT    # Parameter
ip6tables -A INPUT -s your:gateway:ip -p icmpv6 --icmpv6-type 135 -j
ip6tables -A INPUT -s your:gateway:ip -p icmpv6 --icmpv6-type 136 -j

You *will* need the above accepts regardless since your default policy
is DROP, if not, you may find ipv6 reachable problems, in fact, you may
not even be able to connect outbound without types 135/136 (neighbour

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130805/2e603f68/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130805/2e603f68/attachment.bin>

More information about the bind-users mailing list