.ORG registrar - IPv6 Glue - One record only?

[snarked]

I have a .org domain that has a multihomed IPv6 host, yet only ONE of the glue addresses shows up when the .ORG TLD servers are queried.  Both addresses were input at the registration service (along with an IPv4 address).  This doesn't happen for my .NET, .INFO, or .NAME domains.

Does anyone else see the same thing (for your own domain(s))?   Does .ORG limit IPv6 glue to one address?

[jimb]

Presumed you've tried this from multiple locations, restarted named to get rid of any cache issues, etc.  I also presume you've noted that it was the same IPv6 showing up every time and not alternating.

My guess is that something broke between the ORG TLD opers and your registrar.  May want to try resubmitting the host records to see if it pushes through?

[NewtonNet]

I agree. I have a .org domain with multiple glue IPv6 glue records.

Chances are your issue is a consequence that IPv6 support at many registrars is very much a 'bolt on' supplement to their existing setup and sometimes they appear to be not very robust when it comes to sanity checking etc.

As Jim suggests, try resubmitting your delegation/glue from scratch.

Mathew

[snarked]

RE - Reply #1:  I tried that before posting.  My registrar shows both IPv6 addresses assigned to the glue host.  I've also tried rearranging the order the addresses and resubmitting; no effect.  The registrar shows all three of the host's IPv6 addresses.

RE - Reply #2:  I can't tell by your response if you understood my question.  It's not a matter of multiple glue records.  It's a matter of multiple AAAA records for the SAME glue host (i.e. one NS-RR and multiple AAAA-RR's defined, but only one AAAA-RR showing in the parent zone).

Caching is not the issue, especially when I "dig @a2.org.afilias-nst.info ..." (e.g.).  Such bypasses my local DNS server (and its cache).

I messed with it several times, adding and removing various addresses, and it looks as if it finally worked.  I guess that something got lost.

One thing that I noticed:  The .ORG registry doesn't like IPv6-only glue hosts.  It complained when I randomly (and temporarily) tried to remove the IPv4 address from the glue host.

[NewtonNet]

RE - Reply #2:  I can't tell by your response if you understood my question.  It's not a matter of multiple glue records.  It's a matter of multiple AAAA records for the SAME glue host (i.e. one NS-RR and multiple AAAA-RR's defined, but only one AAAA-RR showing in the parent zone).

You're right - I misread the question. Fully understand now.

Good to hear you've got it sorted. Registrar control panels, and the backend interfaces to the registries, have always been a bit flaky on occasion and bolting IPv6 on to the side seems to have made this worse for many.

Thinking aloud for a moment, is it normal to have multiple records for the same glue host? This implies your nameserver has multiple addresses so how do you ensure the response to queries goes out from the same address the query came in on? Or does BIND et al handle that by default?

Mathew

[jimb]

The DNS server should respond with the IPv6 address it received the query on, since that will be what's in the socket structure that the packet came in on which it'd use for the reply.

Having multiple IPs per DNS server, especially if the routes to each interface take a different path and use a different LAN, would make it more robust.  Not as robust as having separate physical servers of course, but better than a single IP.

[NewtonNet]

The DNS server should respond with the IPv6 address it received the query on, since that will be what's in the socket structure that the packet came in on which it'd use for the reply.

Oh okay - I didn't know that. Presumably by 'should' that's something you're aware of rather than assuming in a theoretical sense?   

Having multiple IPs per DNS server, especially if the routes to each interface take a different path and use a different LAN, would make it more robust.

Sure, and in the case of multiple IPv6 tunnels from different providers it is very common to have multiple delegation/glue records for what is the same host. However, I've never seen the same name with multiple addresses to the same nameserver before.

To clarify, this is quite common:

Code:

example.com IN NS ns1.example.com
            IN NS ns2.example.com
            IN NS ns3.example.com

ns1.example.com IN AAAA 2001:DB8::1
ns2.example.com IN AAAA 2001:DB8::2
ns3.example.com IN AAAA 2001:DB8::3

...where 2001:DB8::1 and 2001:DB8::2 are actually the same server (with routes via different tunnels).

whereas I have never seen this before:

Code:

example.com IN NS ns1.example.com
            IN NS ns3.example.com

ns1.example.com IN AAAA 2001:DB8::1
                IN AAAA 2001:DB8::2
ns3.example.com IN AAAA 2001:DB8::3

Thinking about it, I suppose it makes little difference either way to my initial query re source address determination... but I'm sure there must be an effective difference between the two configurations, no?

Mathew

[Edit: Scrap my 'never seen it before' position - I've just seen one on an old NANOG thread here! (The thread strays ambiguously to other matters) The configuration has since changed but I think it'd be unfair to read anything into that!]

[jimb]

The DNS server should respond with the IPv6 address it received the query on, since that will be what's in the socket structure that the packet came in on which it'd use for the reply.

Oh okay - I didn't know that. Presumably by 'should' that's something you're aware of rather than assuming in a theoretical sense?   

I say should be cause a piece of software can still screw it up.  But one doesn't have to do anything special to respond using the same IP address on which you received the packet.

For this specific example, in BIND, it's definitely true, and can be easily demonstrated.  I just added a 2nd IPv6 to my NIC and restarted bind, queried both addresses:

dig @2001:db8:1234::1 gts.ipv6.example.com any

; <<>> DiG 9.4.3-P3 <<>> @2001:db8:1234::1 gts.ipv6.example.com any
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22485
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;gts.ipv6.example.com.              IN      ANY

;; ANSWER SECTION:
gts.ipv6.example.com.       86400   IN      AAAA    2001:db8:1234:0:201:2ff:fe6d:5aa4

;; AUTHORITY SECTION:
ipv6.example.com.           86400   IN      NS      ipv6.example.com.

;; ADDITIONAL SECTION:
ipv6.example.com.           86400   IN      AAAA    2001:db8:1234::1

;; Query time: 4 msec
;; SERVER: 2001:db8:1234::1#53(2001:db8:1234::1)
;; WHEN: Sat Feb 27 00:59:02 2010
;; MSG SIZE  rcvd: 104

dig @2001:db8:1234::1234 www.ipv6.example.com any

; <<>> DiG 9.4.3-P3 <<>> @2001:db8:1234::1234 www.ipv6.example.com any
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6434
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;www.ipv6.example.com.              IN      ANY

;; ANSWER SECTION:
www.ipv6.example.com.       86400   IN      AAAA    2001:db8:1234:0:201:2ff:fe6d:5aa4

;; AUTHORITY SECTION:
ipv6.example.com.           86400   IN      NS      ipv6.example.com.

;; ADDITIONAL SECTION:
ipv6.example.com.           86400   IN      AAAA    2001:db8:1234::1

;; Query time: 3 msec
;; SERVER: 2001:db8:1234::1234#53(2001:db8:1234::1234)
;; WHEN: Sat Feb 27 00:59:15 2010
;; MSG SIZE  rcvd: 104

Having multiple IPs per DNS server, especially if the routes to each interface take a different path and use a different LAN, would make it more robust.

Sure, and in the case of multiple IPv6 tunnels from different providers it is very common to have multiple delegation/glue records for what is the same host. However, I've never seen the same name with multiple addresses to the same nameserver before.

To clarify, this is quite common:

Code:

example.com IN NS ns1.example.com
            IN NS ns2.example.com
            IN NS ns3.example.com

ns1.example.com IN AAAA 2001:DB8::1
ns2.example.com IN AAAA 2001:DB8::2
ns3.example.com IN AAAA 2001:DB8::3

...where 2001:DB8::1 and 2001:DB8::2 are actually the same server (with routes via different tunnels).

whereas I have never seen this before:

Code:

example.com IN NS ns1.example.com
            IN NS ns3.example.com

ns1.example.com IN AAAA 2001:DB8::1
                IN AAAA 2001:DB8::2
ns3.example.com IN AAAA 2001:DB8::3

Thinking about it, I suppose it makes little difference either way to my initial query re source address determination... but I'm sure there must be an effective difference between the two configurations, no?

Mathew

[Edit: Scrap my 'never seen it before' position - I've just seen one on an old NANOG thread here! (The thread strays ambiguously to other matters) The configuration has since changed but I think it'd be unfair to read anything into that!]

I've seen both.

[NewtonNet]

Thanks for that Jim - conclusive proof as you say.

Mathew

[snarked]

RE Reply #4 - Your question:  The DNS related RFCs address your question.  There is no doubt as to what the correct behavior is.

What annoyed me is that it worked without problem with my other domains under other TLDs (with the same registrar), but with .ORG, although I had 2 addresses specified at the registrar, only one was showing in the parent zone before the problem corrected itself.  It must hae been something pecular with that registrar and .ORG.