AAAA on various websites, but they all forgot to enable them on their nameservers....
![](https://secure.gravatar.com/avatar/c83002163cb7ed92287ada2f3e546772.jpg?s=120&d=mm&r=g)
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? :) At least one step closer, now lets hope that sites also keep that IPv6 address there. Greets, Jeroen -- $ dig @d.gtld-servers.net ns1.google.com aaaa ; <<>> DiG 9.7.3 <<>> @d.gtld-servers.net ns1.google.com aaaa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16030 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.google.com. IN AAAA ;; AUTHORITY SECTION: google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns1.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. ;; ADDITIONAL SECTION: ns2.google.com. 172800 IN A 216.239.34.10 ns1.google.com. 172800 IN A 216.239.32.10 ns3.google.com. 172800 IN A 216.239.36.10 ns4.google.com. 172800 IN A 216.239.38.10 ;; Query time: 123 msec ;; SERVER: 192.31.80.30#53(192.31.80.30) ;; WHEN: Wed Jun 8 11:26:35 2011 ;; MSG SIZE rcvd: 164 $ dig @d.gtld-servers.net ns1.cisco.com aaaa ; <<>> DiG 9.7.3 <<>> @d.gtld-servers.net ns1.cisco.com aaaa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55271 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.cisco.com. IN AAAA ;; AUTHORITY SECTION: cisco.com. 172800 IN NS ns1.cisco.com. cisco.com. 172800 IN NS ns2.cisco.com. ;; ADDITIONAL SECTION: ns1.cisco.com. 172800 IN A 128.107.241.185 ns2.cisco.com. 172800 IN A 64.102.255.44 ;; Query time: 126 msec ;; SERVER: 192.31.80.30#53(192.31.80.30) ;; WHEN: Wed Jun 8 11:28:14 2011 ;; MSG SIZE rcvd: 95
![](https://secure.gravatar.com/avatar/7dbbb1b63a6c1fad093e013548d956de.jpg?s=120&d=mm&r=g)
On Wed, Jun 8, 2011 at 11:28, Jeroen Massar <jeroen@unfix.org> wrote:
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.
agreed, but still better than juniper.net at the moment, glue seems to be completely gone at ultradns :P --Daniel.
![](https://secure.gravatar.com/avatar/be89f48869aae3867c355acb0d857483.jpg?s=120&d=mm&r=g)
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 -----Original Message----- From: Daniel Verlouw [mailto:daniel@shunoshu.net] Sent: Wednesday, June 08, 2011 6:10 AM To: nanog Subject: Re: AAAA on various websites, but they all forgot to enable them on their nameservers.... On Wed, Jun 8, 2011 at 11:28, Jeroen Massar <jeroen@unfix.org> wrote:
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.
agreed, but still better than juniper.net at the moment, glue seems to be completely gone at ultradns :P --Daniel.
![](https://secure.gravatar.com/avatar/66cad7bbe26916d55d6756e69e073e2e.jpg?s=120&d=mm&r=g)
On Wed, 8 Jun 2011, Jeroen Massar wrote: :: 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 :) ).. 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 :) -igor
![](https://secure.gravatar.com/avatar/f6ec2510d4d091c41614c61e131e13b2.jpg?s=120&d=mm&r=g)
On Wed, 08 Jun 2011 02:28:40 -0700, Jeroen Massar <jeroen@unfix.org> wrote:
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.
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.
![](https://secure.gravatar.com/avatar/6aeb1fb0c1cd5411f0983607bd37d901.jpg?s=120&d=mm&r=g)
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 -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
![](https://secure.gravatar.com/avatar/ccb661acbdd9a3dad8c98305cfa2df54.jpg?s=120&d=mm&r=g)
On 6/15/2011 12:14, Jeroen van Aart wrote:
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?
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
![](https://secure.gravatar.com/avatar/6aeb1fb0c1cd5411f0983607bd37d901.jpg?s=120&d=mm&r=g)
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? :-)
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 -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
![](https://secure.gravatar.com/avatar/ccb661acbdd9a3dad8c98305cfa2df54.jpg?s=120&d=mm&r=g)
On 6/15/2011 12:32, 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? :-)
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.
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
![](https://secure.gravatar.com/avatar/d029381275960df2c9ba702809aa4f49.jpg?s=120&d=mm&r=g)
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? :-)
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. :) -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
![](https://secure.gravatar.com/avatar/6aeb1fb0c1cd5411f0983607bd37d901.jpg?s=120&d=mm&r=g)
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. :)
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 -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
![](https://secure.gravatar.com/avatar/97f454d78ab404e82a44a513a2de8aa6.jpg?s=120&d=mm&r=g)
In message <4DF91AB3.6020107@mompl.net>, Jeroen van Aart writes:
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. :)
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
-- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html
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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
![](https://secure.gravatar.com/avatar/49e63ef40963554428261bd3224a633f.jpg?s=120&d=mm&r=g)
On Thu, Jun 16, 2011 at 08:05:14AM +1000, Mark Andrews wrote:
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.
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 -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
![](https://secure.gravatar.com/avatar/7ec86a63aabc42f1bf830af9c87f09ec.jpg?s=120&d=mm&r=g)
On Jun 15, 2011, at 12:32 PM, 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? :-)
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
participants (11)
-
Daniel Roesen
-
Daniel Verlouw
-
Frank Bulk
-
Igor Gashinsky
-
Jeroen Massar
-
Jeroen van Aart
-
Leo Bicknell
-
Mark Andrews
-
Octavio Alvarez
-
Owen DeLong
-
Seth Mattinen