<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'><div dir='ltr'>
Once again. Thanks to everyone for the feedback!<br>Marty<br><br><br><br><div>> To: dsparro@gmail.com<br>> From: marka@isc.org<br>> Subject: Re: question about thehartford.com domain<br>> Date: Fri, 17 Jun 2011 10:40:10 +1000<br>> CC: dnsadmin@THEHARTFORD.COM; nstld@verisign-grs.com; bind-users@isc.org<br>> <br>> <br>> In message <4DFA62CA.7060507@gmail.com>, David Sparro writes:<br>> > On 6/15/2011 7:41 PM, M. Meadows wrote:<br>> > ><br>> > > The DNS admins at thehartford.com seem to feel that this nameserver<br>> > > mismatch is working as expected.<br>> > ><br>> > > So I'm just wondering if anyone still feels that the nameserver mismatch<br>> > > seen with the digs in earlier parts of this email thread may present a<br>> > > problem to servers requesting name resolution for address records in the<br>> > > "thehartford.com" domain.<br>> > ><br>> > <br>> > It will be fine as long as nothing goes wrong. It may not be as robust <br>> > as they think it is because it means that depending on the state of my <br>> > cache, I may need to be able to get an answer from one of NS1 or NS2 <br>> > *AND* one of hfdns3, hfdns4, simns3, or simns4 simultaneously.<br>> > This creates an additional potential point of failure.<br>> <br>> The last sentence of this paragraph from RFC 1034 was not written<br>> for no reason. Registries and registrants need to obey it. It is<br>> not optional and failure to do so causes operational problems.<br>> <br>> As the last installation step, the delegation NS RRs and<br>> glue RRs necessary to make the delegation effective should<br>> be added to the parent zone. The administrators of both<br>> zones should insure that the NS and glue RRs which mark<br>> both sides of the cut are consistent and remain so.<br>> <br>> COM is being negligent by not ensuring that these checks get performed<br>> and mis-matches get corrected. The current COM operators took over<br>> operations well after RFC 1034 was written. They have no excuse for<br>> not doing this regardless of the costs. We shouldn't have to pay for<br>> their lack of due diligence.<br>> <br>> Mark<br>> <br>> > -- <br>> > Dave<br>> > _______________________________________________<br>> > bind-users mailing list<br>> > bind-users@lists.isc.org<br>> > https://lists.isc.org/mailman/listinfo/bind-users<br>> -- <br>> Mark Andrews, ISC<br>> 1 Seymour St., Dundas Valley, NSW 2117, Australia<br>> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org<br>> _______________________________________________<br>> bind-users mailing list<br>> bind-users@lists.isc.org<br>> https://lists.isc.org/mailman/listinfo/bind-users<br></div> </div></body>
</html>