|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Change to .com/.net behavior
It may be unclear who they are supposed to represent, but they do the bidding of their funders. I'm going to go out on a limb here and postulate that their decisions, therefore, are not always in the best interests of the Internet Community. ----- Original Message ----- From: "David Schwartz" <[email protected]> To: "Paul Vixie" <[email protected]>; <[email protected]> Sent: Wednesday, September 17, 2003 14:30 Subject: 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 > > > >
|