AAAA on various websites, but they all forgot to enable them on their nameservers....

It is really nice that folks where able to put AAAA records on their
websites for only 24 hours, but they forgot to put in the glue on their
nameservers.

As such, for the folks testing IPv6-only, a lot of sites will fail
unless they use a recursor that does the IPv4 for them.

The root is there, .com does it mostly too (well, a+b have IPv6), but
most sites don't. Thus maybe that can be done next year on the next IPv6
day? :slight_smile:

At least one step closer, now lets hope that sites also keep that IPv6
address there.

Greets,
Jeroen

agreed, but still better than juniper.net at the moment, glue seems to
be completely gone at ultradns :stuck_out_tongue:

   --Daniel.

Ah...I saw the same thing at 6:01 Central. Lost DNS resolution of
ipv6.juniper.net, and couldn't get A or NS records of juniper.net. Had to
flush the cache on my DNS servers.

Frank

:: It is really nice that folks where able to put AAAA records on their
:: websites for only 24 hours, but they forgot to put in the glue on their
:: nameservers.
::
:: As such, for the folks testing IPv6-only, a lot of sites will fail
:: unless they use a recursor that does the IPv4 for them.

Speaking strictly for myself, we didn't "forget". First of all,
that's not what World IPv6 Day was supposed to be about -- it's not about
ipv6-only users, it's about dual-stacking content (if your ISP doesn't
have enough ip's to dual-stack their recursive resolvers, you have
bigger problems right now :slight_smile: )..

Also, and more importantly, our data shows that 0.5% of the users can't
resolve hostnames if we enabled AAAA glue on all resolvers... And, before
somebody asks, I don't have any data on what happends if you enable
v6-glue to only 1 of your NS's though :slight_smile:

-igor

In fact. Although a website of mine worked flawlessly in a dual-stack
but it did NOT in an IPv6-only environment. Unfortunately, the problem
has to be fixed in the DNS provider, which though supporting AAAA
records was enough to "support IPv6".

dig -6 +trace is our friend here.

Octavio Alvarez wrote:

In fact. Although a website of mine worked flawlessly in a dual-stack
but it did NOT in an IPv6-only environment. Unfortunately, the problem
has to be fixed in the DNS provider, which though supporting AAAA
records was enough to "support IPv6".

Why not run your own nameserver if it is your website assuming you own the domain?

Out of curiosity, what are the options you need to use to properly enable bind for IPv6? To me it appears there isn't that much to it, it almost works out of the box with 1 or 2 things turned on. Then you just add the appropriate zone files or records. Am I missing something blatantly obvious that will break it?

dig -6 +trace is our friend here.

How would you apply this command to determine correct IPv6 resolving?

Thanks,
Jeroen

listen-on-v6 { any; };

Simple as that. Indicate individual addresses, if preferred. Or switch
to a DNS provider that has made this monumental configuration effort.

~Seth

Seth Mattinen wrote:

listen-on-v6 { any; };

Yeah that's what I did. But I keep reading about how these big name companies messed it up in some subtle or not so subtle way and I keep thinking I must have missed something. Because surely those big companies can't find it that difficult, can they? :slight_smile:

Simple as that. Indicate individual addresses, if preferred. Or switch
to a DNS provider that has made this monumental configuration effort.

I'd rather have the fuzzy warm feeling of accomplishment of IPv6 enabling my own nameserver.

Thanks,
Jeroen

I can send you a copy of my config offlist if you'd like; there's really
nothing to it and it's been going along fine for as long as I can
remember. In the simple case of answering on a v6 address I can't see
how that could go wrong unless the network it was on had other IPv6
failings.

~Seth

In a message written on Wed, Jun 15, 2011 at 12:32:09PM -0700, Jeroen van Aart wrote:

Seth Mattinen wrote:
>listen-on-v6 { any; };

Yeah that's what I did. But I keep reading about how these big name
companies messed it up in some subtle or not so subtle way and I keep
thinking I must have missed something. Because surely those big
companies can't find it that difficult, can they? :slight_smile:

But you see, those big companies didn't have a place in the Excel
spreadsheet for DNS changes to indicate an IPv6 address, so the DNS
team couldn't submit the right information to the Firewall team,
but it all doesn't matter because the network team hadn't actually
made IPv6 work yet as there was no business case.

No, I'm not cynical. :slight_smile:

Leo Bicknell wrote:

but it all doesn't matter because the network team hadn't actually
made IPv6 work yet as there was no business case.

Ahhh, ok, well at least I know I did it right the first time.

No, I'm not cynical. :slight_smile:

It probably reflects daily practice for many big organisations, sadly. Luckily I can configure dns, firewall/routing and (ipv6) networking myself, so no need of passing along spreadsheets (besides I really hate spreadsheets).

Seth Mattinen wrote:
> I can send you a copy of my config offlist if you'd like; there's really
> nothing to it and it's been going along fine for as long as I can

That won't be necessary, thanks. I think I have configured it correctly and created the correct IPv6 records. Just wanted to make sure.

Greetings,
Jeroen

You tell named to listen on IPv6 (listen-on-v6). It already uses IPv6
to make queries unless you turned it off on the command line with "named -4".
To go IPv6 only on a dual stack machine use "named -6".
You add AAAA records to the zones for the nameservers.
You update your glue records in the parent zone to include AAAA records
as well as A records.
You add IPv6 address to resolv.conf or equivalent (DHCPv6, the new RA option).

You can mark non-local ula's as bogus and your one local ulas as good in
named.conf.

servers fc00::/7 {
  bogus yes;
};
servers fdxx:xxxx:xxxx::/48 {
  bogus no;
};

If you are only using IPv6 internally

servers ::/0 {
  bogus yes;
};
servers <internal-range> {
  bogus no;
};

You should also be doing this at the routing level.

And you check all your ACLs and TSIG server definitions etc. because
suddenly zone transfers, DNS UPDATEs and other stuff (rndc!) might
magically use IPv6 and don't match your ACLs etc. anymore.

Best regards,
Daniel

Well... You may also need to put IPv6 glue records into the upstream DNS servers, depending
on whether your nameservers live within the same zone or not.

Owen