Discuss mailing list

[Jeff Taylor <shdwdrgn AT sourpuss.net>]

I do like the idea of pairing up the names some how.  It would certainly make it easier, at a glance, to see if two outages are actually a single server not responding on either interface.  On the other hand, for troubleshooting purposes, there's no reason why you can't tell dig to specifically pull ipv4 or ipv6 queries.


On 01/29/2011 05:02 AM, Zach Gibbens wrote:

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
continue.

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:

ns1.se.dns.opennic.glue = 192.121.121.14
ns1.ipv6.se.dns.opennic.glue = 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 ns1.se.dns.opennic.glue should simply have both A
and AAAA
records assigned to it.


_______________________________________________
discuss mailing list
discuss AT lists.opennicproject.org
http://lists.darkdna.net/mailman/listinfo/discuss

_______________________________________________
discuss mailing list
discuss AT lists.opennicproject.org
http://lists.darkdna.net/mailman/listinfo/discuss

_______________________________________________
discuss mailing list
discuss AT lists.opennicproject.org
http://lists.darkdna.net/mailman/listinfo/discuss