Skip to Content.
Sympa Menu

discuss - Re: [opennic-discuss] Tier2 naming scheme...

discuss AT

Subject: Discuss mailing list

List archive

Re: [opennic-discuss] Tier2 naming scheme...

Chronological Thread 
  • From: Zach Gibbens <infocop411 AT>
  • To: discuss AT
  • Subject: Re: [opennic-discuss] Tier2 naming scheme...
  • Date: Sat, 29 Jan 2011 07:02:16 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=Q/hS9fJx3GQERPTF1YeGok1JcO3KhDlAw4Qlf4uogUlSMLpo1z23XxDglyVkbcWi0l do6oabLrU3iA2xA9xYBcPoQ/3V/FHAev0i/Ko3q9I52K3wD19Ck9Ughp0q7cSzNuHhI6 O/Nu+igynUpRphADzQvb7Okv3KoVE+xOrTpY8=
  • List-archive: <>
  • List-id: <>

I carried on that "mistake" at first just cause it's how we did it, and
asked some of this myself, but actually there is two good side effects,
first of which, at least once since I took over, an ipv6 route became
unavailable, due to a routing issue, which meant we temporally removed
it, as part of the temporary outage procedure, same box also served as a
tier 2 with ipv4 on a slightly differing route, benefit one was we were
more selective in identifying the outage, his server still received
queries and still resolved them, for ipv4.

the second benefit is due to how we spotted the error, it was
immediately clear that the issue lied in the routing of ipv6, not bind9
(or another daemon)

both of these points aided in reducing downtime for a server, by giving
accurate reports of the issue, with as much detail as could be gathered.

given the current setup, this does wind up having some benifits, for
little if any downside (a larger zone file at worst)

I do like your idea of ns{n}.ipv{n}.{CC}.dns.opennic.glue, I'd be
willing to implement that if nobody's opposed (if I may make a
suggestion on it, how about just nsX.{CC}.dns.opennic.glue, unless the
same server has a dual stack, then nsX.ipv4 and nsX.ipv6, that should
help keep them paired, a little more visual aid)

so idk if that was a mistake, as Jeff suggested, it may have been, but
it's proven to be a useful one in diagnosing an issue at least once, and
as ipv6 continues to build up steam, might be all the more reason to

Just my two pence

On 01/28/2011 11:47 PM, Jeff Taylor wrote:
> I know I've been asked this question countless times, and I know I've
> mentioned it on IRC, but for the life of me, I can't recall any
> explanation other than "that's just the way we've always done it"...
> If this is so, it makes me wonder if the first IPv6 address was given a
> new hostname simply because the person adding it didn't realize that
> both types of records can point to the same hostname. We've got a lot
> of folks setting up tunnels in the past couple years, and I expect that
> in the next couple years we will see a move towards ISPs providing
> native IPv6 addressing, so this is something that really should be
> resolved now, so we can get a policy posted to answer further questions...
> On 01/28/2011 06:35 PM, NovaKing wrote:
>> I've noticed that each new T2 gets a unique fqdn, but I also notice
>> that a
>> server which has both IPv4 and IPv6 each get a different fqdn, is this
>> required?
>> If you want each IP to get a unique fqdn maybe a nicer approach would be
>> something like ns{n}{.ipv6}.{tld}.dns.opennic.glue
>> Example:
>> =
>> = 2a01:298:3:100::14
>> at least this way the numbering system doesn't just increment so quickly
>> with servers with both IPv4/IPv6.
>> But realistically should simply have both A
>> and AAAA
>> records assigned to it.
>> _______________________________________________
>> discuss mailing list
>> discuss AT
> _______________________________________________
> discuss mailing list
> discuss AT

Attachment: signature.asc
Description: OpenPGP digital signature

Archive powered by MHonArc 2.6.19.

Top of Page