Re: What *are* they smoking? (fwd)
Mea culpa, sorry. [EMAIL PROTECTED] wrote: On Tue, 16 Sep 2003 01:27:09 EDT, Yakov Shafranovich said: The SMTP server is fake, take a look at this transaction: Actually, that was my point.
Re: Stupid DNS tricks
Adam Roach; Because this is probably a community of interest for the topic of DNS, I thought it would be worthwhile mentioning that Verisign has apparently unilaterally put in place wildcard DNS records for *.com and *.net. All unregistered domains in .com and .net now resolve to 64.94.110.11, which runs a Verisign-operated web search engine on port 80. A very interesting stupidity. However, as I checked whois database of verisign for *.com and *.net, the answers are negative No match for *.COM. No match for *.NET. that, according to verysign, they are not registered domain names. So, I tried to get the names by myself, for obvious reasons :-), through www.verisign.com. :-) But, my request was denied as Please use only letters, numbers or dashes [-]. Do not enter spaces, periods [.] or other punctuation. that they are, according to verisign, not domain names open for registration. So, the remaining question is whether the stupidity is interesting enough to make verisign not to be qualified to be a gtld registry anymore or not. Masataka Ohta
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
Because noone can stop them doing it, apparently... On Tue, Sep 16, 2003 at 12:43:35AM -0400, Keith Moore wrote: so now verisign is deliberately misrepresenting DNS results. why are these people allowed to live?
Re: Stupid DNS tricks
Adam Roach [EMAIL PROTECTED] writes: Because this is probably a community of interest for the topic of DNS, I thought it would be worthwhile mentioning that Verisign has apparently unilaterally put in place wildcard DNS records for *.com and *.net. All unregistered domains in .com and .net now resolve to 64.94.110.11, which runs a Verisign-operated web search engine on port 80. And SMTP on 25/TCP. The current setup breaks setups like example.com 86400 IN MX 10 mail1.xeample.com example.com 86400 IN MX 20 mail2.example.com Previously, MTAs could not resolve xeample.com and would therefore use the secondary. Now, they can, and get a 550 error on RCPT TO:. Granted, the setup has always been erroneous and risky, but breaking this without proper notice is still extremely annoying.
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
Today VeriSign is adding a wildcard A record to the .com and .net zones. This is, as already noted, very dangerous. We in the IETF must work to put a stop to this attempt to turn the DNS into a directory service, and quickly. I suggest the following courses of action, to be taken in parallel and immediately: 0. Urgently publish an RFC (Wildcards in GTLDs Considered Harmful, or DNS Is Not A Directory) to provide a clear statement of the problem and to unambiguously prohibit the practice. 1. Via ICANN, instruct Verisign to remove the wildcard. 2. Some of us with sufficiently studly facilities should mirror the COM and NET zones, filtering out the wildcards. Then the root zone can be modified to point at these filtered COM and NET nameservers. 3. Instruct ICANN to seek another organisation to permanently take over COM and NET registry services, in the event that Verisign do not comply with instructions to remove the wildcard. I believe that the direct action I suggest in point 2 is necessary, because we have previously seen the failure of the proper channels in this matter, when Verisign added a wildcard for non-ASCII domain names. Verisign have shown a disregard for the technical requirements of their job, as well as displaying gross technical incompetence (particularly in the wildcard SMTP server). I believe Verisign have forfeit any moral right to a grace period in which to rectify the situation. -zefram -- Andrew Main (Zefram) [EMAIL PROTECTED]
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
Zefram [EMAIL PROTECTED] writes: 1. Via ICANN, instruct Verisign to remove the wildcard. By the way, what about .museum?
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
On Tue, 16 Sep 2003, Zefram wrote: ... I suggest the following courses of action, to be taken in parallel and immediately: 1. Via ICANN, instruct Verisign to remove the wildcard. It isn't clear that this power is vested in ICANN. There is a complicated arrangement of Cooperative Agreements, MOUs, CRADAs, and Purchase Orders that exist between various agencies of the US Department of Commerce (including NTIA, NIST, and others) and ICANN and Verisign/NSI. This web of agreements is sufficiently complicated that often really isn't exactly clear who can compel Verisign/NSI on any particular point. In fact it may well be that the power may not exist. Or it may take a lot of legal dollars and time to press the issue. To make the situation even less clear, there is, I believe, no statement in the relevant Internet Standards docucuments that clearly rules out this kind of wildcarding. (Yes, I think we can all agree that this particular use of wildcarding *is* a bad thing, I'm simply pointing out that to those who are not technically grounded in DNS matters, that without a clear prohibition in the Internet Standards, the matter isn't so obvious.) By-the-way, Neulevel (.us and .biz) did an experiment along these lines back in May of this year. It was short lived. At the time I thought it was a bad thing, and I still do. And at the time I wrote and sent to the ICANN board an evaluation of the risks of that experiment. --karl--
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
On dinsdag, sep 16, 2003, at 12:25 Europe/Amsterdam, Karl Auerbach wrote: 1. Via ICANN, instruct Verisign to remove the wildcard. It isn't clear that this power is vested in ICANN. There is a complicated arrangement of Cooperative Agreements, MOUs, CRADAs, and Purchase Orders that exist between various agencies of the US Department of Commerce (including NTIA, NIST, and others) and ICANN and Verisign/NSI. This web of agreements is sufficiently complicated that often really isn't exactly clear who can compel Verisign/NSI on any particular point. In fact it may well be that the power may not exist. Or it may take a lot of legal dollars and time to press the issue. I think the ICANN has no choice and has to show its teeth here, or just roll over and die because there no longer is a reason for its existence. On a related note: so far I have never bothered to move my domains to a competing registrar before, but now seems a good time to do it. Can anyone recommend a procedure for select a good quality registrar? (Off-list if this is more appropriate.)
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
By-the-way, Neulevel (.us and .biz) did an experiment along these lines back in May of this year. It was short lived. At the time I thought it was a bad thing, and I still do. And at the time I wrote and sent to the ICANN board an evaluation of the risks of that experiment. .nu have been doing this for a long time AFAIK. - kurtis -
Re: Solving the right problems ...
Randall, RRSh Now of course if the application wants to be aware, it can subscribe to RRSh events that let it know that it happened. That sounds remarkably like a presence service. RRSh No, what it is is a socket call you make that subscribes do address RRSh events on the socket. oh. ok. I thought you were referring to a protocol issue, not a local programming issue. I suppose it is interesting that the language you used in your previous statement could have either meaning. Not sure _how_ it is interesting, though... d/ -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
Re: Solving the right problems ...
Now of course if the application wants to be aware, it can subscribe to events that let it know that it happened. That sounds remarkably like a presence service. No, what it is is a socket call you make that subscribes do address events on the socket. Thus when a peer adds and deletes an address you get a notification message up the socket buffer telling you that an address was added and one was deleted. Both are needed. That is, you need a way for the host IP stack to know that a peer has moved to a different locator, and you need timely notification that this has happened. This is a lot like a presence service, but it needs to operate at layer 3, and it needs to act in response to sending IP packets to the old locators (polling a presence server is either too slow or - if you do it often enough - too wasteful). And yes, you probably also need a socket call that the app can use to ask that it be notified of changes in peers' locations, because location changes can also result in changes in the level of service available to the app. though hopefully most apps won't need to use it. Keith
Re: Developing software for IETF/IRTF groups
Yakov, there is a currently rather quiet list - [EMAIL PROTECTED] - which was supposed to discuss, among other things, software tools to support WG activities. You might want to ask your question there. I've heard of people using various sorts of document repositories, including CVS and WEBDAV, but have not heard of stuff developed specifically for IETF WGs. Harald
[Fwd: [Asrg] 7. Best Practices - Service Providers MTA Authors (was: Fwd: Verisign's New Change and Outdate RBL's)]
Forwarding from the ASRG list, more anti-spam tools being broken by Verisign. Original Message Subject: [Asrg] 7. Best Practices - Service Providers MTA Authors (was: Fwd: Verisign's New Change and Outdate RBL's) Date: Tue, 16 Sep 2003 11:43:03 +0200 From: Brad Knowles [EMAIL PROTECTED] To: IRTF ASRG [EMAIL PROTECTED] Folks, Just saw this on NANOG as well. Looks like outdated anti-spam configurations will now be turned into reject everything servers, courtesy of Verisign/NetSOL. Date: Tue, 16 Sep 2003 00:39:14 -0400 From: Patrick Muldoon [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Verisign's New Change and Outdate RBL's Was playing with a test box here at home. Installed SpamAssassian from a newely cvsup'd ports tree on a FreeBSD box, and was surprised to see messages getting marked as received in blacklists that no longer exist. Most noteably ORBS. Since this was a fresh Install I hadn't gone through and removed the dead RBL's from 20_head_tests.cf yet. Since dorkslayers doesn't exist. any queries for it are returning that infamous sitefinder address. [EMAIL PROTECTED] doon]$ host 34.131.246.64.orbs.dorkslayers.com 34.131.246.64.orbs.dorkslayers.com has address 64.94.110.11 So anybody that hasn't update their SpamAssassian config, now has the added benefit of all ip's being tagged as an open relay. Just an FYI -Patrick
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
Is it any worse than IE taking you to msn search when a domain doesn't resolve? Or worse than Mozilla taking you to Netscape, duplicating a Google search, and opening a sidebar (and a netscape search) you didn't want? I think it isn't. And people shouldn't be using Reverse DNS for spam checks, either. This has been hashed out on both DNSOP and Namedroppers. People have known not to do this for a long time, but some still insist on it. For that reason alone, this is a good idea. --Dean On Tue, 16 Sep 2003, Keith Moore wrote: so now verisign is deliberately misrepresenting DNS results. why are these people allowed to live?
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
Dean Anderson wrote: Is it any worse than IE taking you to msn search when a domain doesn't resolve? Or worse than Mozilla taking you to Netscape, duplicating a Google search, and opening a sidebar (and a netscape search) you didn't want? Yes, it is worse. Much worse. There is a fundamental difference between this defaulting happening in the DNS and happening in a client program. It is necessary that the wire protocols distinguish between existence and non-existence of resources in a standard manner (NXDOMAIN in this case) in order to give the client the choice of how to handle non-existence. If IE wishes to default to doing a web search under those circumstances, that is silly but harms no one else. What Verisign has done pre-empts that choice for everyone. -zefram -- Andrew Main (Zefram) [EMAIL PROTECTED]
Re: Spoofing and SCTP ADD-IP (was Re: Solving the right problems ...)
Pekka Nikander wrote: vinton g. cerf wrote: We would also want to look very carefully at the potential spoofing opportunity that rebinding would likely introduce. Randall R. Stewart (home) wrote: This is one of the reasons the authors of ADD-IP have NOT pushed to get it done.. some more work needs to be done on this area... http://www.ietf.org/internet-drafts/draft-nikander-mobileip-v6-ro-sec-01.txt is a background document, produced by the MIPv6 route optimization security design team, that tries to explain the security desing in MIPv6 RO. I think that most of the threats and much of the solution model would most probably apply also to SCTP ADD-IP and, of course, also other multi-address multi-homing solutions. --Pekka Nikander IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 Pekka: Interesting reading.. I had heard of the RR check from someone but had not researched it in detail.. nice document : Now as to the applicability in SCTP and ADD-IP... There is a difference with mobile-ip in that an SCTP association is already established. Each node CN and MN have connection state. There has been a 64bit random value exchanged and the ADD-IP which is equivialant of the BU can be verified with this random state that the ends are maintaining. The real issue shows up in that if you are worried about an ease-dropper that can see the initial INIT/INIT-ACK exchange between the two peers. In that case it would then have the 64bits of randomness and could inject the false ADD/DEL that would hi-jack the association. Of course it could do other things too like knock down your assocation as well by sending a false ABORT chunk It is good to see that the routing infrastructure is believed to be non-compromised in MIP case. If we can make the same assumption then with one minor tweak we can add a mechanism to SCTP to authenticate the ADD-IP with private-public key pairs shared in the INIT/INIT-ACK. The obvious problem with this would be if the infrastructure was compromised and you had a true man in the middle who could intercept the INIT/INIT-ACK packets and change the keys... but that goes away if we make the same assumption MIP did : Michael Tuexen and I were working on a seperate draft for this.. and were also somewhat concerned about the compromised routing structure too. If we don't have to worry about that our job just got easier : Thanks R -- Randall R. Stewart [EMAIL PROTECTED] 815-342-5222 (cell phone)
Re: Spoofing and SCTP ADD-IP (was Re: Solving the right problems ...)
Randall R. Stewart (home) wrote: Now as to the applicability in SCTP and ADD-IP... There is a difference with mobile-ip in that an SCTP association is already established. Each node CN and MN have connection state. There has been a 64bit random value exchanged and the ADD-IP which is equivialant of the BU can be verified with this random state that the ends are maintaining. The real issue shows up in that if you are worried about an ease-dropper that can see the initial INIT/INIT-ACK exchange between the two peers. In that case it would then have the 64bits of randomness and could inject the false ADD/DEL that would hi-jack the association. Of course it could do other things too like knock down your assocation as well by sending a false ABORT chunk Yes. Unless you are encrypting the whole session, on-path attackers can already do almost anything. They can start a session for you. They can abort a session for you. They can hijack a session from you. They can modify a session. It is good to see that the routing infrastructure is believed to be non-compromised in MIP case. If we can make the same assumption then with one minor tweak we can add a mechanism to SCTP to authenticate the ADD-IP with private-public key pairs shared in the INIT/INIT-ACK. The obvious problem with this would be if the infrastructure was compromised and you had a true man in the middle who could intercept the INIT/INIT-ACK packets and change the keys... but that goes away if we make the same assumption MIP did : The question you have to ask is: What is the difference between the Internet as is and Internet with ADD-IP (or MIP). You can do the analysis case by case, such as for plaintext communications and for cryptographically protected communications and with or without the compromised infrastructure. For instance, assuming plaintext SCTP packets, presumably in the current Internet all on-path attackers will be able launch the attacks I listed above. But I hope that not everyone in the whole Internet will be able to e.g. disconnect SCTP sessions from a given host. The same properties should stay if you add a feature such as ADD-IP. On the other hand, if we assume that the routing infrastructure is compromised, then even in the current Internet I can go and intercept your plain sessions and cause all kinds of interesting problems. I would allow this to happen even with ADD-IP, as long as it does not make the problem worse. With cryptographic protection (e.g. IPsec) on the SCTP packets, you should be safe even from on-path attackers. Again, if you add ADD-IP feature the same property should stay. Note that there are some DoS attacks that remain regardless of cryptographic protection. For instance, by interfering with ARP/ND you could block the flow of packets. --Jari
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
Is it any worse than IE taking you to msn search when a domain doesn't resolve? yes. if an app that interfaces to humans masks the difference between an invalid domain and a valid one, it only affects people who use that particluar app. however for other apps the difference between an invalid domain and a valid one is significant. verisign is masking the difference between a valid domain and NXDOMAIN for all protocols, all users, and all software.
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
I agree with Zefram here, for at least a couple of reasons: - there's a difference between doing this in infrastructure and doing this in a client program - there's a difference between doing this in a scenario where there probably really IS a human in the loop (IE) and a scenario where there's no reason to think that a human is involved (trivially, an FTP running from cron on a Unix box) - there's a difference between doing this in a component that can be replaced (IE) and one that is very difficult to replace in a meaningful way (DNS) Not that I think IE's redirection is a GREAT example of the Internet at its finest... Spencer - Original Message - From: Zefram [EMAIL PROTECTED] To: Dean Anderson [EMAIL PROTECTED] Cc: Keith Moore [EMAIL PROTECTED]; Yakov Shafranovich [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 8:18 AM Subject: Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us] Dean Anderson wrote: Is it any worse than IE taking you to msn search when a domain doesn't resolve? Or worse than Mozilla taking you to Netscape, duplicating a Google search, and opening a sidebar (and a netscape search) you didn't want? Yes, it is worse. Much worse. There is a fundamental difference between this defaulting happening in the DNS and happening in a client program. It is necessary that the wire protocols distinguish between existence and non-existence of resources in a standard manner (NXDOMAIN in this case) in order to give the client the choice of how to handle non-existence. If IE wishes to default to doing a web search under those circumstances, that is silly but harms no one else. What Verisign has done pre-empts that choice for everyone. -zefram -- Andrew Main (Zefram) [EMAIL PROTECTED] ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Raffaele D'Albenzio.
Re: [Fwd: [Asrg] Verisign: All Your ...
At 14:18 +0100 9/16/03, Zefram wrote: Yes, it is worse. Much worse. There is a fundamental difference between this defaulting happening in the DNS and happening in a client program. It is necessary that the wire protocols distinguish between existence and non-existence of resources in a standard manner (NXDOMAIN in this case) in order to give the client the choice of how to handle non-existence. Here we go with DNS, wild card synthesis and existence again... ;) I think there are a few separate issues here. One is understanding the role of 'name errors' (the original name of NXDOMAIN) and wild card synthesis in DNS. The other is understanding the difference between DNS and registry contents. The operational issue is the conditions under which the change was made. As someone whose spent a lot of time studying DNS and currently is editing a DNSEXT WG document on the topic of wild cards, what is going on here is well within the protocol design of DNS. I can't see an operational issue here either. Having experience as the co-chair of PROVREG WG, I'd like to make a case that the DNS isn't the best means to determine if an object (even if it is a domain name) is registered - it's a first order guess but not the last word. There are names registered that may not have working servers (hence suspended from the DNS to prevent lame delegations) or are otherwise reserved or suspended. There are plenty of network address objects in use - in routing tables - that are not in the reverse DNS map. So, to those who were relying on DNS for existence or legitimacy, perhaps they need to consider an alternate method. (Namely something like whois or crisp.) Operationally, at least the change was made on a Monday. But given that there are other operational systems relying on the existing conditions, advance notice would have been a good idea. In defense of not giving the advance notice, it's sometimes not clear who is impacted by a change because of the open nature of the Internet. As someone who doesn't run spam tools (others do it for me), it wasn't obvious to me until reading the threads of the impact of the change on spam defenses. I can understand how someone in the spam trenches would see the obvious impact, but be patient with others that are not in the trenches with you. PS - With DNSSEC, you'll be able to distinguish between synthesized (wild card) answers and straight answers. If you want to see DNSSEC because of this, get active in the the DNSEXT WG and help the effort along. PPS - Maybe this will raise the need for the CRISP WG to develop a protocol. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Fwd: Verisign attempt to take all unpaid addresses
Forwarded with Vittorio Bertola's permission. I received a similar response from Izumi Aizu. Gene Gaines [EMAIL PROTECTED] Sterling, Virginia USA This is a forwarded message From: Vittorio Bertola [EMAIL PROTECTED] To:Gene Gaines [EMAIL PROTECTED] Date: Tuesday, September 16, 2003, 9:17:46 AM Subject: Verisign attempt to take all unpaid addresses =Original message text=== Hello, we've been working on this since the first rumours started to come up, see http://forum.icann.org/mail-archive/alac/msg00385.html and following thread. We will release a statement shortly. Thanks for your support :-) Regards, On Tue, 16 Sep 2003 08:48:26 -0400, you wrote: To: ICANN Interim At-Large Advisory Committee: Erick Iriarte Ahon, Peru, Computer Law Specialist, [EMAIL PROTECTED] Izumi Aizu, Asia Network Research Researcher, [EMAIL PROTECTED] Vittorio Bertola, Italy, Technical manager, [EMAIL PROTECTED] Pierre Dandjinou. BENIN, ICT Policy Advisor, SURF/UNDP [EMAIL PROTECTED] Esther Dyson, USA, publisher/writer/IT investor/small business owner, [EMAIL PROTECTED] Clement Dzidonu. GHANA, Dept Computer Science, Valley View Univ., [EMAIL PROTECTED] Xue Hong. Prof., Faculty of Law, U. Hong Kong, Prof., Foreign Affairs Coll., [EMAIL PROTECTED] I have a request of you, and I politely request individual answers from each of you. There are many many emails denouncing the new move by VeriSign to hijack all unregistered addresses in the spaces they manage. All unregistered domains in .com and .net now resolve to 64.94.110.11, a Verisign-operated web search engine on port 80 which reports advertiser-paid results. If ICANN will not move immediately and aggressively here, then it is a clear sign that organization is of no value, and is in fact what ICANN is what Karl Auerbach has long suspected the organization to be. I ask that you immediately and publicly denounce this move by VeriSign. I ask that you issue statements both as an individual and as a member of ICANN. If you do not issue such statements, I intend publicize widely your failure to do so. It is time for you to take a stand. Either you support the Internet as it exists today, are you elect to be part of the interests that are moving to destroy it. I would like to know. Gene Gaines [EMAIL PROTECTED] Sterling, Virginia USA +1 703-433-2081 On Tuesday, September 16, 2003, 6:02:59 AM, Zefram wrote: Today VeriSign is adding a wildcard A record to the .com and .net zones. This is, as already noted, very dangerous. We in the IETF must work to put a stop to this attempt to turn the DNS into a directory service, and quickly. I suggest the following courses of action, to be taken in parallel and immediately: 0. Urgently publish an RFC (Wildcards in GTLDs Considered Harmful, or DNS Is Not A Directory) to provide a clear statement of the problem and to unambiguously prohibit the practice. 1. Via ICANN, instruct Verisign to remove the wildcard. 2. Some of us with sufficiently studly facilities should mirror the COM and NET zones, filtering out the wildcards. Then the root zone can be modified to point at these filtered COM and NET nameservers. 3. Instruct ICANN to seek another organisation to permanently take over COM and NET registry services, in the event that Verisign do not comply with instructions to remove the wildcard. I believe that the direct action I suggest in point 2 is necessary, because we have previously seen the failure of the proper channels in this matter, when Verisign added a wildcard for non-ASCII domain names. Verisign have shown a disregard for the technical requirements of their job, as well as displaying gross technical incompetence (particularly in the wildcard SMTP server). I believe Verisign have forfeit any moral right to a grace period in which to rectify the situation. -zefram -- vb. [Vittorio Bertola - v.bertola [a] bertola.eu.org]-- http://bertola.eu.org/ - Archivio FAQ e molto altro... ==End of original message text=== -- Gene [EMAIL PROTECTED]
Re: [Fwd: [Asrg] Verisign: All Your ...
On Tue, 16 Sep 2003, Edward Lewis wrote: At 14:18 +0100 9/16/03, Zefram wrote: It is necessary that the wire protocols distinguish between existence and non-existence of resources in a standard manner (NXDOMAIN in this case) in order to give the client the choice of how to handle non-existence. [ on dns not the best choice for authoritative non-existence ] are not in the reverse DNS map. So, to those who were relying on DNS for existence or legitimacy, perhaps they need to consider an alternate method. (Namely something like whois or crisp.) I'm not sure whether thats a good idea. The main fuss at the moment, apart from Verisign acting without consultation, is that a lot of automated software makes the assumption that 'NXDOMAIN' means 'Does Not Exist'. Adding the wildcard removes this assumption, and removes DNS as a useful stateless low-overhead method of existence-verification. For these items of software to change from using a stateless method of existence-verification with low overhead, to using a semi-stateless method of existence-verification with high overhead, is something akin to the Y2K bug in scope, albeit without all the hype. Operationally, having one's not-low-overhead whois server being hit by automated queries solely for existence-verification is a terrible state of affairs. PPS - Maybe this will raise the need for the CRISP WG to develop a protocol. I can see a lot of people requesting a low-overhead stateless subset of crisp/whois. -- Bruce Campbell I speak for myself.
Re: [Fwd: [Asrg] 7. Best Practices - Service Providers MTA Authors (was: Fwd: Verisign's New Change and Outdate RBL's)]
The ORBS lookup is a problem with configuring invalid domains in spam tools. Someone else could have re-registered orbs.org, and taken control of your email system. This is just irresponsible configuration. --Dean
Re: Careful with those spamtools.....
See, I get feedback from anti-spammers Last night, I got a bunch of these... Someone in australia is trying to get my address blacklisted by spamming out emails forging my address. I wonder who that could be? --Dean Received: from 61.88.124.155 ([210.124.48.16]) by exchange2.the-leading-edge.com.au with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Sep 2003 20:53:25 +1000 from:mbc Subject: -- Content-Type:text/html Content-Transfer-Encoding:7bit Bcc: Return-Path: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] X-OriginalArrivalTime: 16 Sep 2003 10:53:25.0933 (UTC) FILETIME=[C14D5DD0:01C37C40] Date: 16 Sep 2003 20:53:25 +1000
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
On Tue, 16 Sep 2003 09:24:27 EDT, Keith Moore said: verisign is masking the difference between a valid domain and NXDOMAIN for all protocols, all users, and all software. Out of curiosity, where did Verisign get the right to have the advertising monopoly for all the eyeballs they'll attract with this? pgp0.pgp Description: PGP signature
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
Valdis writes: Out of curiosity, where did Verisign get the right to have the advertising monopoly for all the eyeballs they'll attract with this? They didn't. And there's even a way for individuals to stop it: Type an incorrect spelling for a famous trademark. When Verisign puts up its own page for the nonexistent domain, copy it and send it to the trademark owner, asking if he intends to defend his trademark, or if he is releasing it to the public domain. In the former case, he'll have to take action against Verisign. The latter case is unlikely unless he truly doesn't want the trademark, because undefended trademarks are easily diluted and slip rapidly into the public domain. After Verisign has a few thousand lawsuits on its hands, it will change its policy.
Re: [Fwd: [Asrg] Verisign: All Your ...
inline On Tue, 16 Sep 2003, Bruce Campbell wrote: On Tue, 16 Sep 2003, Edward Lewis wrote: At 14:18 +0100 9/16/03, Zefram wrote: It is necessary that the wire protocols distinguish between existence and non-existence of resources in a standard manner (NXDOMAIN in this case) in order to give the client the choice of how to handle non-existence. [ on dns not the best choice for authoritative non-existence ] are not in the reverse DNS map. So, to those who were relying on DNS for existence or legitimacy, perhaps they need to consider an alternate method. (Namely something like whois or crisp.) I'm not sure whether thats a good idea. The main fuss at the moment, apart from Verisign acting without consultation, is that a lot of automated software makes the assumption that 'NXDOMAIN' means 'Does Not Exist'. Adding the wildcard removes this assumption, and removes DNS as a useful stateless low-overhead method of existence-verification. Err, actually, its the opposite that they are assuming. They assume that lack of an NXDOMAIN means the domain does exist. That is an invalid assumption. For these items of software to change from using a stateless method of existence-verification with low overhead, to using a semi-stateless method of existence-verification with high overhead, is something akin to the Y2K bug in scope, albeit without all the hype. The correct way to check for domain existance for email is to lookup an MX record. Operationally, having one's not-low-overhead whois server being hit by automated queries solely for existence-verification is a terrible state of affairs. One shouldn't be doing whois queries. One just wants to know if the domain of the sender can receive email, back. --Dean
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
From: [EMAIL PROTECTED] Out of curiosity, where did Verisign get the right to have the advertising monopoly for all the eyeballs they'll attract with this? What eyeballs? I doubt I'm among the first 1,000,000 people to adjust junk pop-op or other defenses to treat sitefinder.verisign.com and 64.94.110.0/24 like any other noxious web site. If AOL and a lot of other outfits haven't adjusted their proxies within a few hours, I'll be surprised. If AOL and Microsoft don't immediately make releases of IE and Netscape that treat 64.94.110.11 the same as they treated an NXDOMAIN (and included an update mechanism), it will only be because Verisign has given up or they're gettting piece of Verisign's action. Vernon Schryver[EMAIL PROTECTED]
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
On Tue, 16 Sep 2003, Keith Moore wrote: their mistake is in assuming that they can respond appropriately for all ports - particularly when the association of applications with known ports is only advisory, and many ports are open for arbitrary use. Agreed but this is overstating the issue since interoperability demands we know which port is doing what and when. What we needed was time to either stop this before it happened or to deal with the implications. in fact, a 550 response in SMTP is a different condition from NXDOMAIN, and sometimes the difference is important - as the spam filter folks have discovered. Yes and this could be fixed with a new well-defined error code, which brings us back to needing time to make an adjustment (or to have stopped it from ever happening). Would have been nice to get some advance notice even if there are other TLDs that have been doing this for some time. nice is not a word that seems to apply to forcing the entire net to have to patch its applications and libraries just because verisign decided to make inappropriate assertions about unregistered domains. that's like calling a mugger nice because he talks to you politely while he takes your wallet at gunpoint. Agreed but let's be fair. Verisign was not first. In fact, they are almost 10th in the process. Someone earlier (just today, sorry for not looking back for the name) asked about .museum, which I've seen references elsewhere to suggest it has in its contract with ICANN to have this wildcard. I have not confirmed this but undoubtedly someone out there will know and provide a reference. And there is the matter of the other TLDs that are already doing this and have been doing it for some time. None of this makes it right but let's focus on the issue not Verisign. And the issue is with ICANN and convincing it that this is bad behavior for all registries. Verisign just made us all notice. It is worth noting that if we are to pass judgement against Verisign there are at least half-dozen other TLDs that blazed the trail. We just overlooked them because of their size as compared to .NET and .COM. not only their size, but their scope also. What's the difference? Their scope matters because of their size, or vice versa. Jim
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
On Tue, 16 Sep 2003, Bill Sommerfeld wrote: IMHO it was irresponsible of them to do this without several months advance notice to allow authors of automated systems which depended on NXDOMAIN queries to notice this and without a stable documented way to reconstitute the NXDOMAIN they're suppressing. Agreed although some might argue we had several months notice, albeit quietly. Verisign was far from being first at this. It's just that their size/scope made us all notice. Jim
TLD Managers and Wildcard Ethics
Verisign's recent inclusion of wildcard RR's for the .net and .com TLD's does not violate any standards in the DNS that I can find, although it has raised some interesting questions with regard to the ethical behavior or TLD managers. I think that managers of the TLD's should not be allow to use wild card RR's in this manner. I think there is a vast difference between a second level domain name holder using a wildcard and a TLD manager using a wildcard. That differnce being that the TLD managers are custodians of second level domain names and as such the public trusts that they will manage that domain name space in a fair and equitable manner. TLD managers charge the public for the right to use second level domains. They should not be allow to profit from the use of unused second level domains. I believe that TLD managers should have to choose between profiting from their registration services and profiting from the use of the domain name space they are trusted to manage. I am not saying that TLD manager's should not be allow to profit from second level domains they register for themselves. They should be free to register any second level domain name they can legally register and use it for whatever purpose they wish. They should be specifically prohibited from using all unregistered second level domains by virtue of the fact that they can synthisise any second level domain name on the fly due to their technical position in the resolution path. David Botham
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
James M Galvin wrote: On Tue, 16 Sep 2003, Keith Moore wrote: verisign is masking the difference between a valid domain and NXDOMAIN for all protocols, all users, and all software. If you read the Verisign documentation (which is quite excellent by the way) on what they did and what they recommend you will see that they thought about this. In fact, the purpose of the Stubby SMTP daemon is to return a 550 for non-existent recipient domains. It is left as an exercise to the reader as to which is more efficient: DNS NXDOMAIN or SMTP 550. People, have you been reading the posts? The stubby SMTP daemon is not an SMTP server, it is simply a program that returns the following set of responses TO ANYTHING THAT IS PASSED TO IT. --snip- 220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready blah 250 OK blah 250 OK blah 550 User domain does not exist. blh 250 OK blah 221 snubby2-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel --snip- That means that if the SMTP sender issues a RSET command after HELO, they will not get a 550 error code for the RCPT TO command, but rather for the MAIL FROM command as follows: --snip- 220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready EHLO someone.com 250 OK RSET 250 OK MAIL FROM:[EMAIL PROTECTED] 550 User domain does not exist. RCPT TO:[EMAIL PROTECTED] 250 OK DATA 221 snubby4-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel --snip-
Re: TLD Managers and Wildcard Ethics
Hi David - An interesting point, but probably one better made to ICANN. Try [EMAIL PROTECTED] Since its not a standards or protocol issue its probably not an IETF issue. Thanks - Mike At 11:59 9/16/2003, [EMAIL PROTECTED] wrote: Verisign's recent inclusion of wildcard RR's for the .net and .com TLD's does not violate any standards in the DNS that I can find, although it has raised some interesting questions with regard to the ethical behavior or TLD managers. I think that managers of the TLD's should not be allow to use wild card RR's in this manner. I think there is a vast difference between a second level domain name holder using a wildcard and a TLD manager using a wildcard. That differnce being that the TLD managers are custodians of second level domain names and as such the public trusts that they will manage that domain name space in a fair and equitable manner. TLD managers charge the public for the right to use second level domains. They should not be allow to profit from the use of unused second level domains. I believe that TLD managers should have to choose between profiting from their registration services and profiting from the use of the domain name space they are trusted to manage. I am not saying that TLD manager's should not be allow to profit from second level domains they register for themselves. They should be free to register any second level domain name they can legally register and use it for whatever purpose they wish. They should be specifically prohibited from using all unregistered second level domains by virtue of the fact that they can synthisise any second level domain name on the fly due to their technical position in the resolution path. David Botham
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
their mistake is in assuming that they can respond appropriately for all ports - particularly when the association of applications with known ports is only advisory, and many ports are open for arbitrary use. Agreed but this is overstating the issue since interoperability demands we know which port is doing what and when. only the app (not the entire network) needs to know which port to use, and this doesn't require that every port be assigned to a specific app. What we needed was time to either stop this before it happened or to deal with the implications. what we need is a way to punish people who abuse the Internet. personally I think drawing and quartering would be appropriate... in fact, a 550 response in SMTP is a different condition from NXDOMAIN, and sometimes the difference is important - as the spam filter folks have discovered. Yes and this could be fixed with a new well-defined error code NO Jim. VERISIGN DOES NOT HAVE THE RIGHT TO IMPOSE DISRUPTIVE CHANGE ON THE INTERNET, not even with advance notice. None of this makes it right but let's focus on the issue not Verisign. Yes, let's focus on the issue. But let's not ignore who is doing it either. What's wrong for VeriSign is wrong for the other TLD operators also. But Verisign causes much more harm by screwing COM and NET than the operators of ccTLDs do.
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
Just to follow up on this - I just spoke to an engineer at Verisign and he informed me that the SMTP daemon is being replaced in a few hours with an RFC-compliant one. As for not giving a warning - this came from a higher policy level at Verisign and he is just an engineer. Yakov Yakov Shafranovich wrote: James M Galvin wrote: On Tue, 16 Sep 2003, Keith Moore wrote: verisign is masking the difference between a valid domain and NXDOMAIN for all protocols, all users, and all software. If you read the Verisign documentation (which is quite excellent by the way) on what they did and what they recommend you will see that they thought about this. In fact, the purpose of the Stubby SMTP daemon is to return a 550 for non-existent recipient domains. It is left as an exercise to the reader as to which is more efficient: DNS NXDOMAIN or SMTP 550. People, have you been reading the posts? The stubby SMTP daemon is not an SMTP server, it is simply a program that returns the following set of responses TO ANYTHING THAT IS PASSED TO IT. --snip- 220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready blah 250 OK blah 250 OK blah 550 User domain does not exist. blh 250 OK blah 221 snubby2-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel --snip- That means that if the SMTP sender issues a RSET command after HELO, they will not get a 550 error code for the RCPT TO command, but rather for the MAIL FROM command as follows: --snip- 220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready EHLO someone.com 250 OK RSET 250 OK MAIL FROM:[EMAIL PROTECTED] 550 User domain does not exist. RCPT TO:[EMAIL PROTECTED] 250 OK DATA 221 snubby4-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel --snip-
Re: TLD Managers and Wildcard Ethics
An interesting point, but probably one better made to ICANN. Try [EMAIL PROTECTED] Since its not a standards or protocol issue its probably not an IETF issue. I disagree that this is not a protocol issue, as it certainly affects operation of protocols. There are probably issues for the DNS protocols also - if nothing else it may be that some claification of the specification is needed. It can be quite reasonable to make wildcard assertions about RRs that are all within the same administrative domain, but arguably this condition is not met for the COM or NET zones.
Re: [Fwd: [Asrg] Verisign: All Your ...
It is necessary that the wire protocols distinguish between existence and non-existence of resources in a standard manner (NXDOMAIN in this case) in order to give the client the choice of how to handle non-existence. [ on dns not the best choice for authoritative non-existence ] it's hard to imagine that there's a better oracle than DNS to ask about the (non-) existence of a DNS name. now to assume that the DNS name is bound to anything in particular, like a host, or a particular business concern, that would be a stretch.
Re: [Fwd: [Asrg] Verisign: All Your ...
Having experience as the co-chair of PROVREG WG, I'd like to make a case that the DNS isn't the best means to determine if an object (even if it is a domain name) is registered - it's a first order guess but not the last word. I strongly disagree. The DNS is the ultimate authority on whether a domain exists, since the way you create a domain is by making an entry in the DNS.Making existence of a domain depend on a separate registry makes no sense and is inconsistent with longstanding practice. What's happening here is that the COM and NET zones were supposed to reflect their respective registries, but Verisign is adding records to the DNS that are not in the registry. This is fraud. There are plenty of network address objects in use - in routing tables - that are not in the reverse DNS map. that's not the same thing at all. DNS is not the authority for whether a device is connected to the net. DNS is the authority on whether a DNS name exists.
Re: [Fwd: [Asrg] Verisign: All Your ...
On Tue, 16 Sep 2003, Bruce Campbell wrote: Operationally, having one's not-low-overhead whois server being hit by automated queries solely for existence-verification is a terrible state of affairs. Has anyone tried Verisign's whois server ... at least their 'web' interface which is impractical to automate access to because of a fuzzy image which a human or similar of visual discernment must read?
Re: [Fwd: [Asrg] Verisign: All Your ...
At 13:12 -0400 9/16/03, Keith Moore wrote: I strongly disagree. The DNS is the ultimate authority on whether a domain exists, since the way you create a domain is by making an entry in the DNS.Making existence of a domain depend on a separate registry makes no sense and is inconsistent with longstanding practice. DNS is the ultimate authority on whether there is an DNS answer to a DNS query, but that's about it. What a DNS server answers is based on what is in the registry it represents. To quote what I wrote on the provreg list in http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00164.html: DNS names [...] are limited to 255 octets, which is about 2K bits, and 2^2k possibilities minus special cases. Boom - all names exist. The point is, before saying that DNS makes any statement about existence you need to define exists for what purpose. In the message above, it was exists so that I can't register it. In the wcard clarify draft in DNSEXT, it's exists for the purposes of ruling out synthesis of the answer. that's not the same thing at all. DNS is not the authority for whether a device is connected to the net. DNS is the authority on whether a DNS name exists. In engineering the DNS, com. has been and still is a peculiar case and there has been the temptation to tailor the DNS protocol to accommodate it. The community has said time and again not to do so - not to treat that zone (and the others growing like it) as special cases. I think turnabout is fair play - that we not restrict com. and the others from using what's in DNS protocol. I'm neither endorsing nor criticizing what has been added to com. and net. Let's just be fair, accurate, and on-topic (like, protocols) in the discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Re: [Fwd: [Asrg] Verisign: All Your ...
At 11:01 -0400 9/16/03, Dean Anderson wrote in response to Bruce Campbell: Err, actually, its the opposite that they are assuming. They assume that lack of an NXDOMAIN means the domain does exist. That is an invalid assumption. Using DNS to determine existence is a decent heuristic, but it isn't exact. That's my point, in summary. (IOW - we agree.) One shouldn't be doing whois queries. One just wants to know if the domain of the sender can receive email, back. I was assuming that the check was done to see if the mail could be traced back - from claimed source address to domain name to registrant. Of course, with spoofing, nothing can be trusted, but if it is legit, you should be able to check it out. If the case is just to see if mail can go back, then yeah, there oughta be an MX. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Re: TLD Managers and Wildcard Ethics
Hi Keith - At 12:56 9/16/2003, Keith Moore wrote: An interesting point, but probably one better made to ICANN. Try [EMAIL PROTECTED] Since its not a standards or protocol issue its probably not an IETF issue. I disagree that this is not a protocol issue, as it certainly affects operation of protocols. There are probably issues for the DNS protocols also - if nothing else it may be that some claification of the specification is needed. I agree that there may be protocol issues, but the email specifically went: I think that managers of the TLD's should not be allow to use wild card RR's in this manner. The remainder of the email was in the same vein. That's an operational or policy issue best addressed elsewhere - and when resolved we should take a whack at the protocol implications. E.g. how do we get the protocol to enforce the policy or does the policy break the robustness principle, etc.. It can be quite reasonable to make wildcard assertions about RRs that are all within the same administrative domain, but arguably this condition is not met for the COM or NET zones. Agreed - but again, unless it breaks the protocol or has an adverse impact on robustness, (and not just some number of bottom lines) its probably better to resolve the policy issue before putting fingers on the protocol. If someone wants to bang on DNS absent policy discussions - this may be the right place to start, with a very quick trip to namedroppers once the relevance was established. My $.02... Mike
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
On Tue, 16 Sep 2003, Keith Moore wrote: their mistake is in assuming that they can respond appropriately for all ports - particularly when the association of applications with known ports is only advisory, and many ports are open for arbitrary use. Agreed but this is overstating the issue since interoperability demands we know which port is doing what and when. only the app (not the entire network) needs to know which port to use, and this doesn't require that every port be assigned to a specific app. You can't have it both ways. Either the app is so widespread that the port in use is at least a de facto standard or it is a de jure standard. Either way it is possible to respond appropriately. And there aren't that many apps that fall into this category. But I do agree that in the general case there are a lot of ports to worry about. I just don't think the general case is a practical concern. So perhaps we just disagree? in fact, a 550 response in SMTP is a different condition from NXDOMAIN, and sometimes the difference is important - as the spam filter folks have discovered. Yes and this could be fixed with a new well-defined error code NO Jim. VERISIGN DOES NOT HAVE THE RIGHT TO IMPOSE DISRUPTIVE CHANGE ON THE INTERNET, not even with advance notice. I'm not so sure. Others on this list and other lists, some more qualified than I, have been asserting there are no rules -- technical or otherwise -- to prevent Verisign and others from doing what they've done. Oh we can certainly debate philosophical positions like do not harm, but what exactly is the disruption here? Correct me if I'm wrong, the principle disruption -- and I want to emphasize disruption here -- I've seen is that a particular spam indicator no longer works as expected. Is there more to this than that? Okay, yes, there may be technical DNS issues but it is still not disruptive to the Internet infrastructure in general as far as I can tell. There seems to be no shortage of reasons to dislike the behavior but what exactly has been disrupted? None of this makes it right but let's focus on the issue not Verisign. Yes, let's focus on the issue. But let's not ignore who is doing it either. Ignore, no. But let's not start Verisign bashing either. What's wrong for VeriSign is wrong for the other TLD operators also. But Verisign causes much more harm by screwing COM and NET than the operators of ccTLDs do. But what exactly is the screw here? Jim
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
From: James M Galvin [EMAIL PROTECTED] ... Correct me if I'm wrong, the principle disruption -- and I want to emphasize disruption here -- I've seen is that a particular spam indicator no longer works as expected. Is there more to this than that? ... The list I've seen is: - failing to reject spam based on NXDOMAIN for the envelope sender. (What you term the principle disruption) - rejecting legitimate mail because some long dead DNS-based blacklists are suddenly resolving - HTTP spiders will fetch Verisign's robots.txt a lot as they find bogus domains (e.g. typos in HREFs) resolving. - HTTP users see a stalled screen instead of an error message as their browsers wait for Verisign's overloaded HTTP server to deliver its advertising. Vernon Schryver[EMAIL PROTECTED]
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
On Tue, 16 Sep 2003 15:19:47 EDT, James M Galvin said: But what exactly is the screw here? Verisign was (as far as I knew) given *stewardship* of the .com and .net zones as a public trust. I don't see anywhere they were given the right to use their stewardship to try to make money selling typo eyeballs. (And note that unless you do something *really* ugly like round-robin the wildcards, only one organization can do this per TLD - so they're essentially abusing their monopoly). So the question boils down to: Are they owners of .com, or merely caretakers? pgp0.pgp Description: PGP signature
Re: TLD Managers and Wildcard Ethics
It can be quite reasonable to make wildcard assertions about RRs that are all within the same administrative domain, but arguably this condition is not met for the COM or NET zones. Agreed - but again, unless it breaks the protocol or has an adverse impact on robustness, (and not just some number of bottom lines) its probably better to resolve the policy issue before putting fingers on the protocol. As convenient as it might be to find an excuse to keep IETF out of this I don't think we can meaningfully separate discussions about the DNS protocol from discussions about DNS semantics. That, and we've put up with too much abuse from VeriSign for too long.
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
Jim writes: Correct me if I'm wrong, the principle disruption -- and I want to emphasize disruption here -- I've seen is that a particular spam indicator no longer works as expected. Is there more to this than that? You could make many random DNS requests of a DNS server and flush the cache, producing a partial denial of service (or at least a drop in performance). If every single request for a domain produces an address, existent or not, it takes up more continuing resources than a request that produces an error. No?
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
only the app (not the entire network) needs to know which port to use, and this doesn't require that every port be assigned to a specific app. You can't have it both ways. Either the app is so widespread that the port in use is at least a de facto standard or it is a de jure standard. False. Many ports have neither a de factor nor a de jure assignment. Either way it is possible to respond appropriately. False. As I pointed out earlier, there is no SMTP respose which is equivalent to this domain does not exist. Furthermore there are failure modes associated with the wildcard MX record that do not exist if the server returns NXDOMAIN. For instance, if their SMTP server is down or unreachable (as it might be from time to time), the sender will keep retrying to send the message when it should have failed immediately with NXDOMAIN. Frankly, your apologies for Verisign's abuse aren't very credible. The only appropriate response to this situation is to punish Verisign. But I do agree that in the general case there are a lot of ports to worry about. I just don't think the general case is a practical concern. So perhaps we just disagree? Perhaps. I actually care about preserving the Internet's ability to support a wide variety of applications. So arguments of the form it works for the web and email, therefore the practical concerns are taken care of don't wash. Particularly when it doesn't even do the right thing for either the web or email. Hint: just because the protocol is HTTP doesn't mean that the client has a human typing URLs in and looking at the output. in fact, a 550 response in SMTP is a different condition from NXDOMAIN, and sometimes the difference is important - as the spam filter folks have discovered. Yes and this could be fixed with a new well-defined error code NO Jim. VERISIGN DOES NOT HAVE THE RIGHT TO IMPOSE DISRUPTIVE CHANGE ON THE INTERNET, not even with advance notice. I'm not so sure. Others on this list and other lists, some more qualified than I, have been asserting there are no rules -- technical or otherwise -- to prevent Verisign and others from doing what they've done. Nothing gives VeriSign the right to misrepresent the contents of the registry. If it's wrong for businesses to register individual misspelled domain names in the hopes of getting misspelled queries redirected to their sites, it is surely wrong for VeriSign to do the same thing for ALL unregistered domains within COM and NET. Oh we can certainly debate philosophical positions like do not harm, but what exactly is the disruption here? Have you not been paying attention? When you try to download a web page that doesn't exist, you don't get a host does not exist error, you get a redirect to a web page. That's fraud. When you try to verify that a domain is valid, you don't get NXDOMAIN, you get an A record. That's also fraud. When you try to talk to another port, you get connection refused, so instead of getting the error that corresponds to no such host you'll probably think it is a temporary error (say, the server is down) and try again later. It is a gross protocol violation to take an explicit error indication that has a very specific meaning and instead map it to what in some cases looks like valid output, and in other cases looks like a very different kind of error. Correct me if I'm wrong, the principle disruption -- and I want to emphasize disruption here -- I've seen is that a particular spam indicator no longer works as expected. You are wrong. Okay, yes, there may be technical DNS issues but it is still not disruptive to the Internet infrastructure in general as far as I can tell. It's broken the ability to detect misspelled domains for every application and every protocol, for every name under .COM or .NET. Yes, let's focus on the issue. But let's not ignore who is doing it either. Ignore, no. But let's not start Verisign bashing either. It's not bashing them to speak the truth about what they are doing. Keith
Re: [Fwd: [Asrg] Verisign: All Your ...
At 13:12 -0400 9/16/03, Keith Moore wrote: I strongly disagree. The DNS is the ultimate authority on whether a domain exists, since the way you create a domain is by making an entry in the DNS.Making existence of a domain depend on a separate registry makes no sense and is inconsistent with longstanding practice. DNS is the ultimate authority on whether there is an DNS answer to a DNS query, but that's about it. What a DNS server answers is based on what is in the registry it represents. What a DNS server answers is based on what is in the zone it represents. Not all zones have registries. To quote what I wrote on the provreg list in http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00164.html: DNS names [...] are limited to 255 octets, which is about 2K bits, and 2^2k possibilities minus special cases. Boom - all names exist. You didn't actually cite any support for your statement. And the existence of the NXDOMAIN response code contradicts that statement. The point is, before saying that DNS makes any statement about existence you need to define exists for what purpose. That's beside the point. NXDOMAIN is still a meaningful condition even though you can't tell what a domain means if it does exist. that's not the same thing at all. DNS is not the authority for whether a device is connected to the net. DNS is the authority on whether a DNS name exists. In engineering the DNS, com. has been and still is a peculiar case and there has been the temptation to tailor the DNS protocol to accommodate it. The community has said time and again not to do so - not to treat that zone (and the others growing like it) as special cases. I think turnabout is fair play - that we not restrict com. and the others from using what's in DNS protocol. It is never appropriate to make wildcard assertions about names within a zone if those assertions are not true. If all of the names in foo.example.com zone will always be associated with address a.b.c.d, it's reasonable to set up a wildcard A record for that zone. Otherwise it is not reasonable. This is no less true for com or net than for foo.example.com COM and NET are supposed to reflect their respective registries - this isn't itself a DNS protocol issue but part of the arrangement for managing those zones. VeriSign is making assertions about names that don't exist in the registries. (It also happens that those assertions are disruptive to the operation of protocols when those protocols use names in those zones, and that *is* a protocol issue) Keith
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
By the way, what about .museum? .museum does not delegate all of its subdomains. not all tld's are delegation-only. -- Paul Vixie
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
On Tue, 16 Sep 2003 [EMAIL PROTECTED] wrote: But what exactly is the screw here? Verisign was (as far as I knew) given *stewardship* of the .com and .net zones as a public trust. I don't see anywhere they were given the right to use their stewardship to try to make money selling typo eyeballs. (And note that unless you do something *really* ugly like round-robin the wildcards, only one organization can do this per TLD - so they're essentially abusing their monopoly). So the question boils down to: Are they owners of .com, or merely caretakers? An excellent question! But that is a discussion that belongs with ICANN, not the IETF. Jim
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
On Tue, 16 Sep 2003, Vernon Schryver wrote: From: James M Galvin [EMAIL PROTECTED] ... Correct me if I'm wrong, the principle disruption -- and I want to emphasize disruption here -- I've seen is that a particular spam indicator no longer works as expected. Is there more to this than that? ... The list I've seen is: One more I've seen mentioned today ... an incorrect MX record which refers to a non-existant domain will/may no longer properly fail over to an alternate lower priority MX entry. - failing to reject spam based on NXDOMAIN for the envelope sender. (What you term the principle disruption) - rejecting legitimate mail because some long dead DNS-based blacklists are suddenly resolving - HTTP spiders will fetch Verisign's robots.txt a lot as they find bogus domains (e.g. typos in HREFs) resolving. - HTTP users see a stalled screen instead of an error message as their browsers wait for Verisign's overloaded HTTP server to deliver its advertising.
ICANN At-Large Advisory Committee response to Verisign SiteFinder
This is a forwarded message From: Vittorio Bertola [EMAIL PROTECTED] To:Gene Gaines [EMAIL PROTECTED] Date: Tuesday, September 16, 2003, 2:06:02 PM Subject: Verisign attempt to take all unpaid addresses =Original message text=== = The At-Large Advisory Committee would like to bring to ICANN's attention concerns about Verisign's surprising roll-out of the SiteFinder service for .com and .net. SiteFinder works by re-directing queries for non-existing domain names to the IP address of a search service that is being run by Verisign. This practice raises grave technical concerns, as it de facto removes error diagnostics from the DNS protocol, and replaces them by an error handling method that is tailored for HTTP, which is just one of the many Internet protocols that make use of the DNS. We will leave it for others to explain the details of these concerns, but note that returning resource records in a way which is countrary to the very design of the DNS certainly does not promote the stability of the Internet. These concerns are not mitigated by Verisign's efforts to work around the consequences of breaking the Internet's design on a service-by-service basis: These workarounds make specific assumptions on the conclusions that Internet software would be drawing from nonexisting domain names; these assumptions are not always appropriate. When working as intended, the service centralizes error handling decisions at the registry that are rightly made in application software run on users' computers. Users are deprived of the opportunity to chose those error handling strategies best suited for their needs, by chosing appropriate products available on a competitive marketplace. Software makers are deprived of the opportunity to compete by developing innovative tools that best match the user's needs. We urge ICANN to take whatever steps are necessary to stop this service. -- vb. [Vittorio Bertola - vb [at] bertola.eu.org]--- --- http://bertola.eu.org/ --- ==End of original message text=== --
typo wildcard I-D
I've just submitted an Internet-Draft concerning the wildcard issue. For those who can't wait for it to appear in the internet-drafts directory, http://www.fysh.org/~zefram/typo_wcard/. -zefram -- Andrew Main (Zefram) [EMAIL PROTECTED]
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
An excellent question! But that is a discussion that belongs with ICANN, not the IETF. Jim Jim, that would be true if the ICANN were functioning and this event is just proof that the ICANN does not function. the mission of ICANN (my paraphrase) is Technical Administration of Internet ?N?ames and Numbers It is ovious to anyone today, that there is no technical oversite of the DNS today. -rick
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
So the question boils down to: Are they owners of .com, or merely caretakers? An excellent question! But that is a discussion that belongs with ICANN, not the IETF. Nearly my reaction as well. Note, using the concept of ownership has/will get quite some lawyers debating. Some (rhetoric) questions: If there is a caretaker, who is the owner of what is taken care of? Under which law system? jaap
Re: Stupid DNS tricks
Any comment on the attached draft ID? Abstract This memo describes actions against broken content of a primary server of a TLD. Without waiting for an action of some, if any, central authority, distributed actions TLD server operators and ISPs can settle the issue, for a short term. Masataka Ohta --- INTERNET DRAFT M. Ohta draft-ohta-broken-tld--1.txt Tokyo Institute of Technology September 2003 Distributed Actions Against Broken TLD Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo describes actions against broken content of a primary server of a TLD. Without waiting for an action of some, if any, central authority, distributed actions TLD server operators and ISPs can settle the issue, for a short term. 1. Introduction DNS is a fully distributed database of domain names and their associated values with loose integrity. However, the primary server of a zone is a single point of failure of the zone to hold the current most copy of the zone and such a failure at TLD can cause a lot of damage to the Internet. As it may take time for a central authority, if any, take care of the problem, this memo describes distriburted actions as a short term solution to protect the Internet against broken TLD zone content. The long term solution is to let the primary server operator fix the content or to change the primary server operator, which may involve a central authority. M. OhtaExpires on March 17, 2004[Page 1] INTERNET DRAFT Broken TLD June 2003 Similar technique is applicable to root servers with broken contents. 2. Actions of TLD Server Operators A TLD server operator who have found that TLD zone content is broken should disable zone transfer and use a copy of old zone content known not to be broken. Or, if the fix for the zone content is obvious and easy, the operator may manually or automatically edit the content of the current most one without updating SOA serial number. In this case, zone transfer may not be disabled, though actions of ISPs described in section 3 may make the transfer from servers of broken content impossible. 3. Actions of ISPs ISPs should disable routes to TLD servers with broken content and/or filter packets to/from the TLD servers. ISPs should periodically check the servers, whether they still contain broken content or not. 4. Security Considerations As for security, TLD servers should never have broken content. 5. Author's Address Masataka Ohta Graduate School of Information Science and Engineering Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3299 EMail: [EMAIL PROTECTED] M. OhtaExpires on March 17, 2004[Page 2]
RE: [Fwd: [Asrg] Verisign: All Your ...
Are there just a couple of DNS server(s) per ISP? Do they run VPN's to sync up with the central DNS servers so that DNS spoofing is limited DNS synchronization encrypted? Should be an easy solution for DNS spoofing except for public IP addresses which home users get. Again, they would be registered, so spoofing them would be difficult? -- Atul P.S: The opinions are my opinion and my responsibility. -Original Message- From: Edward Lewis [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 16, 2003 11:19 AM To: [EMAIL PROTECTED] Cc: Edward Lewis Subject: Re: [Fwd: [Asrg] Verisign: All Your ... At 13:12 -0400 9/16/03, Keith Moore wrote: I strongly disagree. The DNS is the ultimate authority on whether a domain exists, since the way you create a domain is by making an entry in the DNS.Making existence of a domain depend on a separate registry makes no sense and is inconsistent with longstanding practice. DNS is the ultimate authority on whether there is an DNS answer to a DNS query, but that's about it. What a DNS server answers is based on what is in the registry it represents. To quote what I wrote on the provreg list in http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00164.html: DNS names [...] are limited to 255 octets, which is about 2K bits, and 2^2k possibilities minus special cases. Boom - all names exist. The point is, before saying that DNS makes any statement about existence you need to define exists for what purpose. In the message above, it was exists so that I can't register it. In the wcard clarify draft in DNSEXT, it's exists for the purposes of ruling out synthesis of the answer. that's not the same thing at all. DNS is not the authority for whether a device is connected to the net. DNS is the authority on whether a DNS name exists. In engineering the DNS, com. has been and still is a peculiar case and there has been the temptation to tailor the DNS protocol to accommodate it. The community has said time and again not to do so - not to treat that zone (and the others growing like it) as special cases. I think turnabout is fair play - that we not restrict com. and the others from using what's in DNS protocol. I'm neither endorsing nor criticizing what has been added to com. and net. Let's just be fair, accurate, and on-topic (like, protocols) in the discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-703-227-9854 ARIN Research Engineer Sponge Bob Square Pants? I'm still trying to figure out the Macarena.
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
interesting point. if we created a new gTLD and announced that it would be wildcarded from day one, it wouldn't be used in the same way as the other gTLDs. then again, do we really want different ways of reporting errors for different zones in the DNS? would apps then want to special-case certain zones to interpret their results differently than the others? Keith when people started beating on my phone ringer about wildcards yesterday evening, and screaming for patches to bind to somehow make it all better, i asked but other tld's do this, what's the big deal? as near as i can figure it, the problem is one of expectation. if someone signs up for .nu they know there'll be a wildcard there before they sign, and they can take appropriate precautions (like only using it for web or e-mail, and not naming hosts under that tld). the expectations for .com and .net to not have wildcards were all set many years ago, and it's the violation of those expectations that's got people angry enough to publish patchware about it.
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
% Blech. % % If it's Tuesday, this must be .belgium? % % A non-starter. *MAYBE* if it were a different RR with different semantics. This may be exactly what we get w/ a patch from ISC. If BIND is offically tweeked so that some zone cuts are allowed to exercise legal protocol options while others are not... changes based on mob rule... not good. as bill must surely know, we would never do that. BIND begins to lose its reputation as a reference implementation of open standards. i certainly hope not.
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
% On Wed, 17 Sep 2003 00:00:14 EDT, Keith Moore said: % % then again, do we really want different ways of reporting errors for % different zones in the DNS? would apps then want to special-case % certain zones to interpret their results differently than the others? % % Blech. % % If it's Tuesday, this must be .belgium? % % A non-starter. *MAYBE* if it were a different RR with different semantics. % This may be exactly what we get w/ a patch from ISC. If BIND is offically tweeked so that some zone cuts are allowed to exercise legal protocol options while others are not... changes based on mob rule... not good. BIND begins to lose its reputation as a reference implementation of open standards. Ick. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
