Welcome to part nine of my multipart series on IPv6. In this post I’ll cover how to configure the ISC BIND daemon to serve an authoritative DNS domain over IPv6. The host is running FreeBSD 8.2, but this should apply equally well to any system running the ISC named daemon.
Just having connectivity over IPv6 isn’t enough; you also have to tell the rest of the world that it can reach you over IPv6. In this post I’ll cover the basics of configuring your domain for IPv6, on the assumption that your name servers and your web servers have IPv6 connectivity. If your name servers do not, Hurricane Electric will host your DNS on IPv6 enabled systems for free.
The first step is actually administrative in nature. You need to figure out if you can get your IPv6 addresses into the whois record for your domain at your registrar. In my case my registrar did not have support for adding IPv6 glue records in their admin interface, but they were happy to do it manually through a support ticket. They also said they were in the process of adding IPv6 support to their admin interface, so I hopefully I won’t have to bother the support department next time I need to update a record with them. Here’s an example of my whois record:
[cc]
$ whois mmacleod.ca
Domain name: mmacleod.ca
Domain status: registered
Creation date: 2009/04/06
Expiry date: 2012/04/06
Updated date: 2011/06/17
Registrar:
Name: DomainsAtCost Corp.
Number: 45
Name servers:
ns1.nullpointer.ca 199.48.133.238 2607:fc50:1000:8b00::2
ns2.nullpointer.ca 208.86.255.157 2001:0470:001d:0619::2
[/cc]
As you can see, I have glue records for both IPv4 and IPv6 for my name servers. With that out the way, it’s time to make sure that those nameservers actually serve the zones properly.
I’m using FreeBSD, but this should apply equally well to any system running BIND, just change the paths to the various configuration files to suit your environment. First, we need to edit /etc/namedb/named.conf:
[cc]
$ cat named.conf
options {
directory “/etc/namedb/working”;
pid-file “/var/run/named/pid”;
dump-file “/var/dump/named_dump.db”;
statistics-file “/var/stats/named.stats”;
recursion no;
allow-query { any; };
version “0”;
listen-on { 203.0.113.238; };
listen-on-v6 { 2001:0DB8:1000:8b00::2; };
};
include “/etc/namedb/dnsadmin.key”;
controls {
inet 127.0.0.1 allow { 127.0.0.1; } keys { “dnsadmin”;};
inet ::1 allow { ::1; } keys { “dnsadmin”; };
};
zone “example.com” {
type master;
file “../master/example.com”;
};
[/cc]
This is a very basic named.conf to highlight the few options necessary to get BIND to listen to requests over IPv6 (which is really just the listen-on-v6 option). You are encouraged to read up on BIND administration, as BIND has been associated with a number of attacks over the years, and proper administration of it is very important.
Next is the configuration of the zone itself. Our example domain will use Google for Domains for email, and host a few of services. Open up /etc/namedb/master/example.com:
[cc]
$ cat example.com
$TTL 1200
example.com. IN SOA ns1.example.com. [email protected]. (
2011062702 ; Serial
1200 ; Refresh
1200 ; Retry
2419200 ; Expire
3600 ) ; Negative Cache TTL
;
IN AAAA 2001:0DB8:1000:8b00:0000:0000:0000:0002
IN A 203.0.113.238
IN NS ns1.example.com.
IN NS ns2.example.com.
IN MX 10 ASPMX.L.GOOGLE.COM.
IN MX 20 ALT1.ASPMX.L.GOOGLE.COM.
IN MX 20 ALT2.ASPMX.L.GOOGLE.COM.
IN MX 30 ASPMX2.GOOGLEMAIL.COM.
IN MX 30 ASPMX3.GOOGLEMAIL.COM.
IN MX 30 ASPMX4.GOOGLEMAIL.COM.
IN MX 30 ASPMX5.GOOGLEMAIL.COM.
$ORIGIN example.com.
; A Records
ns1 IN A 203.0.113.238
ns2 IN A 203.0.113.157
www IN A 203.0.113.238
appsrv-02 IN A 203.0.113.157
appsrv-03 IN A 203.0.113.158
; AAAA Records
ns1 IN AAAA 2001:0DB8:1000:8b00:0000:0000:0000:0002
ns2 IN AAAA 2001:0DB8:001d:0619:0000:0000:0000:0002
www IN AAAA 2001:0DB8:1000:8b00:0000:0000:0000:0002
appsrv-02 IN AAAA 2001:0DB8:001d:0619:0000:0000:0000:0002
appsrv-03 IN AAAA 2001:0DB8:001d:0619:0000:0000:0000:0003
; SRV Records
_sip._tcp IN SRV 1 0 5060 appsrv-03
_sip._udp IN SRV 1 0 5060 appsrv-03
; CNAME Records
sip IN CNAME appsrv-03.example.com.
mail IN CNAME ghs.google.com.
calendar IN CNAME ghs.google.com.
docs IN CNAME ghs.google.com.
sites IN CNAME ghs.google.com.
[/cc]
As you can see, the only real difference between this and an IPv4-only domain is the addition of some AAAA records. It’s worth noting that the SRV and CNAME records are IPv4/IPv6 agnostic, since they just point to another hostname. It’s then up to your operating system whether it wants to find an A or AAAA record for that hostname.
That’s all there really is to configuring an authoritative domain for IPv6.
Sorry, the comment form is closed at this time.