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.
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.
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. 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?)
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.
... 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
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" <davids@webmaster.com> To: "Paul Vixie" <paul@vix.com>; <nanog@merit.edu> 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
On 9/17/2003 1:55 PM Paul Vixie noted that:
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?)
I was with you up to this point. Behaviorally speaking, what Dave is doing is no different, in my mind, than what Verisign did when they rolled out their required upgrade this week. At least Dave's customers have the option of applying his "required upgrade" whereas those that don't are forced into Verisign's worldview. It all works both ways - or should at least. This, as you pointed out in your "expectations" post is a big part of the "problem" we are trying to sort out. -- -rwr
Paul Vixie wrote:
... shouldn't they get to decide this for themselves?
<snip>
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.
In my eyes that is the whole issue. I believe that Verisign is holding the zones for the public internet and that they do have obligations to the public. Verisign does not. Without the "for the public" justification, there is absolutely no moral ground for IANA,ICANN and Verisign to maintain this three way stranglehold on the contents/structure of the DNS system for the entire world population.
On Wed, 17 Sep 2003 17:55:32 -0000, Paul Vixie <paul@vix.com> said:
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.
If there's a disagreement on this concept, we have *BIGGER* problems than just DNS b0rkage.
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.
If there's a disagreement on this concept, we have *BIGGER* problems than just DNS b0rkage.
yes. i'm sorry, i thought you knew that. well, come to san diego for usenix next month and i'll tell you all about it in my invited talk there.
participants (6)
-
David Schwartz -
Joe Maimon -
John Palmer -
Paul Vixie -
Ross Wm. Rader -
Valdis.Kletnieks＠vt.edu