On 6/15/2011 7:41 PM, M. Meadows wrote:
The DNS admins at thehartford.com seem to feel that this nameserver
mismatch is working as expected. Here's some of the feedback we
received from them when we questioned the setup:
~~~~~~~~~~~~~~~~~~~~~
We use load balancers for the majority of our internet facing URLs. We
have multiple datacenters. We typically have our URLs defined in
multiple datacenters. Each datacenter has a pair of redundant load
balancers. Typically each URL we have is defined in each datacenter
with its own address. The active load balancer in a particular
datacenter 'owns' one of the NS servers you see when you lookup our
authoritative name servers, ie: ns1 or ns2.thehartford.com. There is
a 'floating' address shared between the active and failover load
balancers that is associated with ns1 or ns2.thehartford.com.
hfdns3, hfdns4, simns3, simns4 are the addresses for the specific bind
processes running on the actual physical devices.
NS1.thehartford.com will be shared between hfdns3 and hfdns4.
NS2.thehartford.com between the simns3 and simns4 name servers.
~~~~~~~~~~~~~~~~~~~~~
So I'm just wondering if anyone still feels that the nameserver
mismatch seen with the digs in earlier parts of this email thread may
present a problem to servers requesting name resolution for address
records in the "thehartford.com" domain.
Do they understand that the in-zone NS records *override* the delegation
NS records (see RFC 2181) when seen, so they're forcing the rest of the
Internet to refresh all 8 records (4 NSes and 4 As) potentially as often
as every 120 seconds? That seems rather inconsiderate.
Also, what's the point of having load-balancer VIPs in your delegation
records, if they're just going to be overwritten, in cache, with the
real IPs of the BIND processes anyway? Are they really getting their
money's worth from those load-balancers, which aren't used most of the
time for this particular function?
Load-balancer or no load-balancer, I think the Best Practice of "Under
normal circumstances, your delegation records should match your in-zone
records" still applies here. The only exception to that general rule is
when you're migrating from one set of nameservers to another.
- Kevin
From: sun-g...@live.com
To: mich...@rancid.berkeley.edu
Subject: RE: question about thehartford.com domain
Date: Wed, 15 Jun 2011 12:59:32 -0400
CC: bind-users@lists.isc.org
Just wanted to say thanks to everyone for the quick feedback!
We appreciate your assistance on this.
Marty
> Date: Wed, 15 Jun 2011 08:25:00 -0700
> From: mich...@rancid.berkeley.edu
> To: sun-g...@live.com
> CC: bind-users@lists.isc.org
> Subject: Re: question about thehartford.com domain
>
>
>
> On Wed, 15 Jun 2011, M. Meadows wrote:
>
> > Question : our check of whois indicates that ns1.thehartford.com
and ns2.thehartford.com are
> > the authoritative nameservers for thehartford.com. A dig with a
+trace for
> > eftc.thehartford.com seems to indicate that they are indeed the
auth nameservers. It?s
> > interesting, though, that an
http://www.kloth.net/services/nslookup.php lookup for
> > thehartford.com query for NS records shows a non-authoritative
answer of
> > hfdns3.thehartford.com, hfdns4.thehartford.com,
simns3.thehartford.com, simns3.thehartford.com
> > and simns4.thehartford.com. We?re unsure what?s going on with that.
>
> Instead of doing 'dig +trace eftc.thehartford.com', do 'dig +trace ns
> thehartford.com', and you'll see the problem.
>
> This is a classic authority mismatch, as others have pointed out.
>
> michael
>
_______________________________________________ bind-users mailing
list bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
