question about thehartford.com domain

[Kevin Darcy]

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-guru at live.com
> To: michael at rancid.berkeley.edu
> Subject: RE: question about thehartford.com domain
> Date: Wed, 15 Jun 2011 12:59:32 -0400
> CC: bind-users at 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: michael at rancid.berkeley.edu
> > To: sun-guru at live.com
> > CC: bind-users at 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 at lists.isc.org 
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110616/e168e3bc/attachment.html>