Understanding Dual Stack

I'm soon launching my blog/cms hosting platform and I want it to be truly dual stack.

I have a garbage domain from a dead project (Linux from Scratch packaged in RPM) that I will use for the name server. I currently use the domain for images and few documents for php classes I wrote, but it will have ns1 and ns2 www as sub domains. Main domain and www sub domain will be on my current linode, NS1 and NS2 will be on my former linode which has two IP's - and that will be all it does.

domain.tld www.domain.tld ns1.domain.tld ns2.domain.tld

Those four will remain in Linode's domain manager for A records. Since I can not (at this point anyway) directly enter AAAA records I will need to configure NSD to use reverse DNS to feed to the linode servers.


Looks to be excellent instructions, but will I really need a tunnel?

It looks to me like tunnels are primarily used for people who want an IPv6 network to connect through an ISP that only provides IPv4.

I'm expecting that I won't need to set up any kind of tunneling on my linodes (Dallas Center), that IPv6 network is in place there and I can just enjoy the ride. Am I correct?

Once I get those domains properly set up so that ns1 and ns2 can be found in an IPv6 dns lookup, then I can use NSD as authoritative DNS for all my other domains for both IPv4 and IPv6, and will not need to maintain reverse DNS zones for anything except the above mentioned domain.tld - correct?

Someone running IPv6 looking for demos.reallycool.tld - their nameserver will see that ns1.domain.tld is the authoritative DNS, will be able to reach it via IPv6, get the IPv6 address it seeks, and the client will connect, correct?

Yes, I know, running a single DNS is not fault tolerant. Once business picks up, i'll get a second linode set up to act as a slave, probably also in the Dallas facility, I think it will be quite some time before things are profitable enough to justify cost of multi-facility fault tolerance.

I've known about IPv6 for about a decade yet only now am I really starting to look into it. It looks like it has a ton of advantages, full blown adoption should happen sooner rather than later.

Once all the IPv6 stuff is set up and working for my linodes, then I may look into setting up my home network as IPv6 - where I probably will need a tunnel, but an article on my ISP's homepage has stated they are already starting to do live customer tests in some area, and have a list of IPv6 routers people in those areas can buy if they want to participate (I think the routers they mention automate a tunnel). But my area isn't one they presently are testing in, so I'll probably have to use a service like the one mentioned in the article.

Thank for comments and suggestions.

9 Replies

Just a comment - one of the things that excites me about a world without IPv4 is IP based virtual hosting.

With name based virtual hosting, because of the way Apache works, you can't have signed certificates for multiple different domains - but you can with IP based virtual hosting.

Since packet sniffing is so easily automated these days, any site that has a login really should do the login over https, IPv6 will make it a lot easier to do that on servers with hundreds of domains.

I think you might be confused about a few things. There is no need to run your own nameservers: Linode's nameservers are fully IPv6-ready (where native IPv6 service is available, of course). Completely disregard the wiki page, which pre-dates native IPv6.

To add an AAAA record, enter an IPv6 address instead of an IPv4 address when adding an A/AAAA record to the DNS Manager. To add reverse DNS, enter a hostname with an appropriate AAAA record into the Reverse DNS configurator on the Remote Access tab.

rtucker@witte:~$ dig +short rocwiki.org ns
rtucker@witte:~$ dig +short rocwiki.org a
rtucker@witte:~$ dig +short rocwiki.org aaaa
rtucker@witte:~$ dig +short -x 2600:3c03::13:3585

No fuss, no muss.

And yup, my new SSL policy is "SNI, IPv6, or GTFO". If your browser doesn't support SNI and your network doesn't have IPv6, then you better fill out one of these and make sure you show off your computer at a nearby cruise night at least once a week during the summer months.

Actually there is a need to run my own nameserver, I would be doing it if I was only interested in IPv4

Some of my client accounts will be sub domains, I can use the wildcard option in NDS to have them instantly available once client signs up.

Secondly, when client wants their own domain, I can script the setup of that as well and have it available very quickly and automatically.

Thanks for the info on adding an AAAA record.

Linode's DNS servers support wildcards, and can be fully scripted with the API:


Thanks for the api reference! I didn't seem to see it when I looked through the docs. That's definitely the preferred way to go.

Again I would like to say thank you to everyone.

Between people here and the he.net ipv6 program/forum I am finally getting a good handle on it.


With name based virtual hosting, because of the way Apache works, you can't have signed certificates for multiple different domains - but you can with IP based virtual hosting.

Yes, yes you can.

Doesn't work with IE on Windows XP.

Don't know about Vista or 7.

A large portion of everyday users are still on XP using IE.


Doesn't work with IE on Windows XP.

Don't know about Vista or 7.

A large portion of everyday users are still on XP using IE.

SNI is supported by IE7 and up on Vista and Win7. SNI is not supported by IE at all on WinXP, even with IE8.

WinXP users can, however, get SNI support on WinXP through Firefox, Chrome, or Opera. That only helps if they need SNI support, though. Because IE 6/7/8 on XP don't support it, SNI is currently entirely unusable for the real world.


Please enter an answer

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct