|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Change to .com/.net behavior
> > > ... shouldn't they get to decide this for themselves? > > Returning NXDOMAIN when a domain does not exist is a basic > > requirement. Failure to do so creates security problems. It is > > reasonable to require your customers to fix known breakage that > > creates security problems. > that sounds pretty thin. i think you stretched your reasoning too far. Feel free to point out the step that's stretching too far. There definitely do exist security validation schemes that rely upon domain existence that are fooled by Verisign's bogus reply. > > VeriSign has a public trust to provide accurate domain > > information for the COM and NET zones. They have decided to put their > > financial interest in obscuring this information ahead of their public > > trust. > i'm not sure how many people inside verisign, us-DoC, and icann agree > that COM and NET are a public trust, or that verisign is just a caretaker. > but, given that this is in some dispute, it again seems that your > customers > should decide for themselves which side of the dispute they weigh in on. Then who does ICANN represent? Doesn't ICANN operate under the authority of the DOC? Doesn't Verisign operate pursuant to a contract with ICANN? Aren't we all intended third party beneficiaries of those contracts? Is this really in dispute? > > Microsoft, for example, specifically designed IE to behave in a > > particular way when an unregistered domain was entered. Verisigns > > wildcard record is explicitly intended to break this detection. The > > wildcard only works if software does not treat it as if the domain > > wasn't registered even though it is not. > then microsoft should act. and if it matters to you then you should act. I would hope that Microsoft would respond with a lawsuit rather than a patch. Otherwise, Verisign will respond with a 'technical solution' and we'll be in a war with the people we have to trust. > but this is not sufficient justification to warrant a demand by > you of your > customers that they install a patch (what if they don't run bind?) or that > they configure delegation-only for particular tld's (which ones > and why not > others?) It really depends upon the specifics of the contractual situation. What if one of your customer's customers lets through some spam because Verisign broke their validation check? And what if that person is sued? Now, where does that leave you, aware of the problem and having not taken actions to correct it that you could have taken? > > Verisign has created a business out of fooling software through > > failure to return a 'no such domain' indication when there is no such > > domain, in breach of their public trust. As much as Verisign was > > obligated not to do this, others are obligated not to propogate the > > breakage. ISPs operate DNS servers for their customers just as > > Verisign operates the COM and NET domains for the public. > the obligations you're speaking of are much less clear than > you're saying. Yes, oviously they are much less clear to Verisign. I want to hear from IANA how they feel about a.net being pointed to Verisign. Simply put, Verisign is telling me that 'a.net' has address '64.90.110.11' and it does not. DS
|