RE: question about thehartford.com domain
Once again. Thanks to everyone for the feedback! Marty To: dspa...@gmail.com From: ma...@isc.org Subject: Re: question about thehartford.com domain Date: Fri, 17 Jun 2011 10:40:10 +1000 CC: dnsad...@thehartford.com; ns...@verisign-grs.com; bind-us...@isc.org In message 4dfa62ca.7060...@gmail.com, David Sparro writes: 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. 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. It will be fine as long as nothing goes wrong. It may not be as robust as they think it is because it means that depending on the state of my cache, I may need to be able to get an answer from one of NS1 or NS2 *AND* one of hfdns3, hfdns4, simns3, or simns4 simultaneously. This creates an additional potential point of failure. The last sentence of this paragraph from RFC 1034 was not written for no reason. Registries and registrants need to obey it. It is not optional and failure to do so causes operational problems. As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. COM is being negligent by not ensuring that these checks get performed and mis-matches get corrected. The current COM operators took over operations well after RFC 1034 was written. They have no excuse for not doing this regardless of the costs. We shouldn't have to pay for their lack of due diligence. Mark -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: question about thehartford.com domain
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. 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. It will be fine as long as nothing goes wrong. It may not be as robust as they think it is because it means that depending on the state of my cache, I may need to be able to get an answer from one of NS1 or NS2 *AND* one of hfdns3, hfdns4, simns3, or simns4 simultaneously. This creates an additional potential point of failure. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: question about thehartford.com domain
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
Re: question about thehartford.com domain
In message 4dfa62ca.7060...@gmail.com, David Sparro writes: 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. 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. It will be fine as long as nothing goes wrong. It may not be as robust as they think it is because it means that depending on the state of my cache, I may need to be able to get an answer from one of NS1 or NS2 *AND* one of hfdns3, hfdns4, simns3, or simns4 simultaneously. This creates an additional potential point of failure. The last sentence of this paragraph from RFC 1034 was not written for no reason. Registries and registrants need to obey it. It is not optional and failure to do so causes operational problems. As the last installation step, the delegation NS RRs and glue RRs necessary to make the delegation effective should be added to the parent zone. The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so. COM is being negligent by not ensuring that these checks get performed and mis-matches get corrected. The current COM operators took over operations well after RFC 1034 was written. They have no excuse for not doing this regardless of the costs. We shouldn't have to pay for their lack of due diligence. Mark -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: question about thehartford.com domain
On 6/15/2011 8:28 AM, M. Meadows wrote: Question : why does eftc as an address record in the thehartford.com zone file have a 30 second TTL? Seems … very … short. I think most nameservers won’t do less than a minute for an address record. Right? No. There is no problem with a short TTL. 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 http://www.kloth.net/services/nslookup.php%20lookup%20for%20thehartford.comquery 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. The zone is broken in that the NS records in at the gTLD don't match the NS records in the zone itself. See: http://bit.ly/jmi2Cd AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: question about thehartford.com domain
Info at the authoritative servers doesn't match the glue records. We see this all the time on our recursive resolvers. rich-goodsons-computer:~ rgoodson$ dig +norec @ns1.thehartford.com thehartford.com NS ; DiG 9.6.0-APPLE-P2 +norec @ns1.thehartford.com thehartford.com NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 43188 ;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4 ;; QUESTION SECTION: ;thehartford.com. IN NS ;; ANSWER SECTION: thehartford.com.120 IN NS hfdns4.thehartford.com. thehartford.com.120 IN NS simns3.thehartford.com. thehartford.com.120 IN NS simns4.thehartford.com. thehartford.com.120 IN NS hfdns3.thehartford.com. ;; ADDITIONAL SECTION: hfdns4.thehartford.com. 120 IN A 162.136.188.4 simns3.thehartford.com. 120 IN A 162.136.190.3 simns4.thehartford.com. 120 IN A 162.136.190.4 hfdns3.thehartford.com. 120 IN A 162.136.188.3 ;; Query time: 39 msec ;; SERVER: 162.136.188.1#53(162.136.188.1) ;; WHEN: Wed Jun 15 08:55:41 2011 ;; MSG SIZE rcvd: 181 rich-goodsons-computer:~ rgoodson$ dig +norec @f.gtld-servers.net thehartford.com NS ; DiG 9.6.0-APPLE-P2 +norec @f.gtld-servers.net thehartford.com NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 3174 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;thehartford.com. IN NS ;; AUTHORITY SECTION: thehartford.com.172800 IN NS ns1.thehartford.com. thehartford.com.172800 IN NS ns2.thehartford.com. ;; ADDITIONAL SECTION: ns1.thehartford.com.172800 IN A 162.136.188.1 ns2.thehartford.com.172800 IN A 162.136.190.1 ;; Query time: 94 msec ;; SERVER: 192.35.51.30#53(192.35.51.30) ;; WHEN: Wed Jun 15 08:55:49 2011 ;; MSG SIZE rcvd: 101 On Jun 15, 2011, at 7:28 AM, M. Meadows wrote: Good morning. We sent the following email to the dns managers at thehartford.com this morning: - Hi. We’re experiencing some issues with address record lookups for eftc.thehartford.com. We’ve got a couple questions about how this address record is set up. Question : why does eftc as an address record in the thehartford.com zone file have a 30 second TTL? Seems … very … short. I think most nameservers won’t do less than a minute for an address record. Right? 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. So we have a Microsoft set of DNS servers that seem to get confused J by this somehow. Not really clear to us what’s going on with it … but it’s sort of like there’s some negative caching going on for hfdns3, hfdns4, simns3 and simns4 … at some point … where these Microsoft DNS servers think those 4 servers are the authorities for the thehartford.com domain … and those auth nameserver names … can’t be found … resolved. Then for a period … until the Microsoft DNS servers have their cache cleared … they say … NOPE … no such servers out there. Can’t get to hfdns4, hfdns3, simns3 or simns4 at all … so we can’t resolveeftc.thehartford.com. Can you help us understand what’s going on? Thanks! - So now ... just in case we don't hear back from the dns folks at thehartford.com ... I'm wondering if any of the experts on this mailing list can help us understand this? ___ 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
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
RE: question about thehartford.com domain
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
RE: question about thehartford.com domain
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. Thanks, Marty 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
