Re: [policy] When Tech Meets Policy...
David Schwartz wrote: That doesn't make anything criminal or fraud any more than free samples. If a registrar wants to give a refund, I don't see anything wrong with that. It is certainly fraud to take an entire pile of free samples. can you cite how that law reads? Oddly enough I am in possession of 20+ fee samples that were the left overs from a hand out, and I was cleaning up the place. pretty sure I did not break any laws. I know that isn't what you meant, but it is what you said. One of the tricky parts about law is defining it. If you can't define it, it is really hard to make it illegal. Domain tasting is more like buying a plasma TV to watch the big game and then returning it to the store on Monday. Which is also like buying a TV and not being satisfied with it and making use of the sores generous return policy. pretty sure not fraud. However, when it's as blatant and obvious as it is now (more tasted domains than legitimate registrations), and no policies are made to stop it despite it being so easy to do so I don't think it is so easy. (simply limit the number of refunded domains to 10% of registrations I don't know what you mean. or charge a 20 cent fee for refunded domains), Didn't someone already shoot this down? something about consumer protection. you can argue that it's now an understood and accepted practice. don't have to. It's not fraud if both parties know it's going to happen, can easily act to stop it, and neither one chooses to. um, not fraud?
Re: [policy] When Tech Meets Policy...
At 6:45 PM -0500 8/13/07, Carl Karsten wrote: Ken Eddings wrote: At 4:32 PM -0400 8/13/07, Justin Scott wrote: Do people really not plan that far ahead, that they need brand new domain names to be active (not just reserved) within seconds? I can say from my experience working in a web development environment, yes. I can recall several cases where we needed to get a domain online quickly for one reason or another. Usually it revolves around the marketing department not being in-touch with the rest of the company and the wrong/misspelled domain name ends up in a print/radio/tv ad that is about to go to thousands of people and cannot be changed. We end up having to go get the name that is in the ad and get it active as quickly as possible. Been there. But it's rare enough in real life that I'd happily waive the right for full refund return for immediate domain publishing. Maybe marketing would learn to spell after a few costly mistakes. Any other domain registrations getting a 3 day wait before publishing can have a more lenient return policy, maybe with a small processing fee. That's not unreasonable, and has something for the registrars. And grandma would be able to correct her typo, and the regstrars would have time to check grandma's credit card, since she's so typo-prone. I am not sure if this is what you are saying, but here is what just came to mind: 2 choices, same price: 1. instant, no refund. 2. 3 day hold, not active, but refundable till the point it goes live. I also just noticed something that doesn't seem to have been brought up: by registering, wait, refund, repeat - you can sit on a name for free. (under both current and my proposed.) To prevent this we need a small processing fee. Carl K Correct. People that make mistakes can be accomodated. People that make lots of mistakes start covering the costs of lots of corrections, and legitimate rush registrations can be paid for mistakes here would cost more. I remember NetSol charging rush fees and that was before private registrations would let quick domain launches happen in a more controlled manner. -- Ken Eddings, Hostmaster, IST, [EMAIL PROTECTED], [EMAIL PROTECTED] Work:+1 408 974-4286, Cell: +1 408 425-3639, Fax: +1 408 974-3103 Apple Computer, Inc., 1 Infinite Loop, M/S 60-MS Cupertino, CA 95014 The Prudent Mariner never relies solely on any single aid to navigation.
Re: [policy] When Tech Meets Policy...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Marshall Eubanks [EMAIL PROTECTED] wrote: On Aug 14, 2007, at 12:19 AM, Paul Ferguson wrote: I was just struck by a couple of statistics: [snip] In January 2007, according to PIR five registrars deleted 1,773,910 domain names during the grace period and retained 10,862. That same month, VeriSign reported that among top ten registrars, 95% of all deleted .COM and .Net domain names were the result of domain tasting. So, if they charged a $ 1 return fee, they would either - produce revenues of several million USD per month (unlikely) or - cut domain tasting by about 2 orders of magnitude. ... or both. I think I could live with that, all things being equal. - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGwSaBq1pz9mNUZTMRAoxDAKCUZ8s/Q/tRF6NC0T7jC6SRFy1zVACgplR4 NZVluA1bG+T0JiZuZrsrVGQ= =Ey48 -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Network Inventory Tool
Guys, Does anyone known some tool for network documentation with: - inventory (cards, serial numbers, manufactor...) - documentation (configurations, software version control, etc) - topology building (L2, L3.. connections, layer control, ...) All-in-one solution and It don't need to be free. I'm just looking for some thing to control the equipments we have like routers from some sort of suppliers, etc... Marcio
RE: [policy] When Tech Meets Policy...
Maybe marketing would learn to spell after a few costly mistakes. Any policy strategy that relies on marketing people learning to spell is flawed from the outset. Domain tasting is a real problem. 1 year domain registrations are cheap. Who then does the waiting period benefit? (hint: not grandma) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Eddings Sent: Tuesday, 14 August 2007 7:46 AM To: nanog@merit.edu Subject: RE: [policy] When Tech Meets Policy... At 4:32 PM -0400 8/13/07, Justin Scott wrote: Do people really not plan that far ahead, that they need brand new domain names to be active (not just reserved) within seconds? I can say from my experience working in a web development environment, yes. I can recall several cases where we needed to get a domain online quickly for one reason or another. Usually it revolves around the marketing department not being in-touch with the rest of the company and the wrong/misspelled domain name ends up in a print/radio/tv ad that is about to go to thousands of people and cannot be changed. We end up having to go get the name that is in the ad and get it active as quickly as possible. Been there. But it's rare enough in real life that I'd happily waive the right for full refund return for immediate domain publishing. Maybe marketing would learn to spell after a few costly mistakes. Any other domain registrations getting a 3 day wait before publishing can have a more lenient return policy, maybe with a small processing fee. That's not unreasonable, and has something for the registrars. And grandma would be able to correct her typo, and the regstrars would have time to check grandma's credit card, since she's so typo-prone. Personally I'm all for things working as quickly as possible, and I'm all for being able to return a domain within a reasonable time if needed. Perhaps it would be better to allow for domain returns, but shorten the time limit to 24 hours. That should be long enough to catch a typo, but too short to be much use for traffic tasting. -Justin Scott | GravityFree Network Administrator 1960 Stickney Point Road, Suite 210 Sarasota | FL | 34231 | 800.207.4431 941.927.7674 x115 | f 941.923.5429 www.GravityFree.com -- Ken Eddings, Hostmaster, IST, [EMAIL PROTECTED], [EMAIL PROTECTED] Work:+1 408 974-4286, Cell: +1 408 425-3639, Fax: +1 408 974-3103 Apple Computer, Inc., 1 Infinite Loop, M/S 60-MS Cupertino, CA 95014 The Prudent Mariner never relies solely on any single aid to navigation.
Re: [policy] When Tech Meets Policy...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Carl Karsten [EMAIL PROTECTED] wrote: Oddly enough I am in possession of 20+ fee samples that were the left overs from a hand out, and I was cleaning up the place. pretty sure I did not break any laws. I know that isn't what you meant, but it is what you said. One of the tricky parts about law is defining it. If you can't define it, it is really hard to make it illegal. It's called gaming the system. While not expressly illegal (IANAL), it damned well should be. - - ferg p.s. I realize that closing the loop on this behavior could be result in more badness, and in fact a certain tragedy of the commons. This is where we find ourselves, apparently. -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGwUixq1pz9mNUZTMRArm8AKDPqGvx25L9ZcsypwA4rQ7uoS+hHwCeO0A7 XuP7TEUbDQWzxrPxJamK9cc= =8sf9 -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
RE: [policy] When Tech Meets Policy...
Maybe marketing would learn to spell after a few costly mistakes. Any policy strategy that relies on marketing people learning to spell is flawed from the outset. Domain tasting is a real problem. 1 year domain registrations are very cheap. Who then does the waiting period benefit? (hint: not grandma) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken Eddings Sent: Tuesday, 14 August 2007 7:46 AM To: nanog@merit.edu Subject: RE: [policy] When Tech Meets Policy... At 4:32 PM -0400 8/13/07, Justin Scott wrote: Do people really not plan that far ahead, that they need brand new domain names to be active (not just reserved) within seconds? I can say from my experience working in a web development environment, yes. I can recall several cases where we needed to get a domain online quickly for one reason or another. Usually it revolves around the marketing department not being in-touch with the rest of the company and the wrong/misspelled domain name ends up in a print/radio/tv ad that is about to go to thousands of people and cannot be changed. We end up having to go get the name that is in the ad and get it active as quickly as possible. Been there. But it's rare enough in real life that I'd happily waive the right for full refund return for immediate domain publishing. Maybe marketing would learn to spell after a few costly mistakes. Any other domain registrations getting a 3 day wait before publishing can have a more lenient return policy, maybe with a small processing fee. That's not unreasonable, and has something for the registrars. And grandma would be able to correct her typo, and the regstrars would have time to check grandma's credit card, since she's so typo-prone. Personally I'm all for things working as quickly as possible, and I'm all for being able to return a domain within a reasonable time if needed. Perhaps it would be better to allow for domain returns, but shorten the time limit to 24 hours. That should be long enough to catch a typo, but too short to be much use for traffic tasting. -Justin Scott | GravityFree Network Administrator 1960 Stickney Point Road, Suite 210 Sarasota | FL | 34231 | 800.207.4431 941.927.7674 x115 | f 941.923.5429 www.GravityFree.com -- Ken Eddings, Hostmaster, IST, [EMAIL PROTECTED], [EMAIL PROTECTED] Work:+1 408 974-4286, Cell: +1 408 425-3639, Fax: +1 408 974-3103 Apple Computer, Inc., 1 Infinite Loop, M/S 60-MS Cupertino, CA 95014 The Prudent Mariner never relies solely on any single aid to navigation.
Re: [policy] When Tech Meets Policy...
On Mon, August 13, 2007 11:27 pm, Roland Dobbins wrote: 2.People tend to be much more careful about punching numbers into a telephone than typing words on a keyboard, I think. There's also not a conceptual conflation of common typo mistakes with common telephone number transpositions, I don't think (i.e., I'm unsure there's any such thing as a common number transposition, while there certainly is with linguistic constructs such as letters). Having a home land line with the last two digits transposed from that of a local fast food establishment, I beg to differ :) Regards, Tim.
Re: [policy] When Tech Meets Policy...
On Tue, August 14, 2007 1:48 am, Douglas Otis wrote: For domains to play any role in securing email, a published MX record should become a necessary acceptance requirement. Using MX records also consolidates policy locales which mitigates some DDoS concerns. What if there's no intention to use the domain for email? I've become annoyed enough in the other direction, owning domains *only* used for email and dealing with irate people insisting I'm domain-squatting and must sell them the domain cheaply right now because there's no A record for www.what.ever. Functioning, correct and coherent DNS prior to registration, now that I support whole-heartedly. Regards, Tim.
Re: Content Delivery Networks
Chris L. Morrow [EMAIL PROTECTED] writes: that sets a lower-bar on TTL in the nscd cache - (from the manpage for nscd.con) positive-time-to-live cachename value Sets the time-to-live for positive entries (successful queries) in the specified cache. value is in integer seconds. Larger values increase cache hit rates and reduce mean response times, but increase problems with cache coherence. Note that sites that push (update) NIS maps nightly can set the value to be the equivalent of 12 hours or more with very good perfor- mance implications. This is still a client issue as, hopefully, the cache-resolvers don't funnel their business through nscd save when applications on them need lookups... (things like ping/telnet/traceroute/blah) nscd may represent a problem if the application in question is a http-proxy without it's own resolver. There's also a number of more-or-less broken http-proxies doing their own resolver caching regardless of actual TTL. Such applications represent a problem wrt any DNS-based load balancing, including CDNs, since they can serve a large number of end-users, redirecting them to the wrong address long after the TTL should have expired. Bjørn
Re: [policy] When Tech Meets Policy...
From [EMAIL PROTECTED] Mon Aug 13 20:15:50 2007 Date: Mon, 13 Aug 2007 19:37:09 -0500 From: Carl Karsten [EMAIL PROTECTED] To: nanog@merit.edu Subject: Re: [policy] When Tech Meets Policy... J Bacher wrote: Carl Karsten wrote: That is, if you extend domains on credit w/o any useful accountability of the buyer and this results in a pattern of criminality then the liability for that fraud should be shared by the seller. I am not sure tasting is criminal or fraud. You got what you ordered. You used it. You pay for it. It's that simple. That doesn't make anything criminal or fraud any more than free samples. If a registrar wants to give a refund, I don't see anything wrong with that. It is not even close to that simple, In and of itself, 'tasting' is neither criminal, nor fraudulent. *HOWEVER*, available evidence suggests that a large proportion of 'tasting' _is_ done in furtherance/support of criminal/fraudulent activities. Registry operator data indicates that less than _six-tenths of one perecent_ of 'tasted' domains are kept by the taster. Analysis of data from another registry operator suggests that that operator is now processing roughly 3.25 _million_ *unpalatable* (i.e., _will_ be returned) 'tasting' domain registrations =per=day=. IF we postulate there are 100 million registered names with that operator, then the annualized number of _returned_ 'tasting' registrations is around TEN TIMES the total number of registered domain names. _IF_ the registry operator is at least breaking even on the entire registration process -- 'real domains' plug 'tasting' -- then it would seem that the registry-operator fee for registration of a domain registration could be reduced _by_a_factor_of_ten_, if tasting was the same price as a real registration. On the other hand, if the free tasting is 'out of hand' to the point where registry operators are 'in the red' due to the 'incremental' costs thereof, *that* problem also needs to be addressed. Life could be _really_ interesting if a registry operator contract came up for renewal, and _nobody_ bid. Anybody with _reasonable_ plan ahead skills can live with a week between name registration submission, and the name going 'live' -- given that they do know, _immediately_ that the registration is successful. Those who have 'urgent' need should pay a premium for 'expidited' service -- and those who have a _legitimate_ need for such service will not balk at paying a significant premium for that service. It _IS_ worth 'big bucks' to them, because, even at that price, it is '_much_ cheaper than the alternative'. I'd suggest: 1) one week latency between registration and entry into the TLD nameservers. 2) 50% (of 1-year registration fee) 'penalty' for cancelling the registration before it hits the TLD servers. 3) $250 'surcharge' (to registrant) for 'immediate' _irrevocable_ recording in the TLD nameservers, 25% of that surcharge to be retained by the registrar, 25% to the registry operator, and 50% to IANA.
Re: [policy] When Tech Meets Policy...
John Levine wrote: I am assuming that A. a registrar would get less business being less forgiving than others. Do you know what your current registrar's refund policy is? Do you know what other registrars' policies are? Why haven't you switched to the registrar that offers the cheapest refunds? Don't care, because I don't do the kinds of transactions where it would matter. I have a lot of criteria for what makes a good registar, and in my case, which I think is not atypical, refund policy is so far down the list as to be invisible. ditto. That doesn't mean there aren't people who care: the tasters. No, I am not trying to protect them. I am looking out for the registrar. Carl K
Domain tasting; a load of hot air?
I'd suggest: 1) one week latency between registration and entry into the TLD nameservers. 2) 50% (of 1-year registration fee) 'penalty' for cancelling the registration before it hits the TLD servers. 3) $250 'surcharge' (to registrant) for 'immediate' _irrevocable_ recording in the TLD nameservers, 25% of that surcharge to be retained by the registrar, 25% to the registry operator, and 50% to IANA. Can I assume that you, and all the other people commenting on domain tasting have filed official comments with ICANN as requested at this web page? http://www.icann.org/announcements/announcement-2-10aug07.htm Or is this just a load of hot air as usual? Democracy, you either use it or lose it! --Michael Dillon
Re: [policy] When Tech Meets Policy...
On Aug 14, 2007, at 3:50 AM, Paul Ferguson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Marshall Eubanks [EMAIL PROTECTED] wrote: On Aug 14, 2007, at 12:19 AM, Paul Ferguson wrote: I was just struck by a couple of statistics: [snip] In January 2007, according to PIR five registrars deleted 1,773,910 domain names during the grace period and retained 10,862. That same month, VeriSign reported that among top ten registrars, 95% of all deleted .COM and .Net domain names were the result of domain tasting. So, if they charged a $ 1 return fee, they would either - produce revenues of several million USD per month (unlikely) or - cut domain tasting by about 2 orders of magnitude. ... or both. I think I could live with that, all things being equal. - - ferg It's not uncommon for companies to not charge good customers for minor incidental things, like fixing a typo; I think that most would reconsider that policy if they were hit with 8 million minor changes in a day, which it seems is where we are. That has to cost something. I haven't heard a good reason why not to do this. If IANA can't use the money the IETF can. Regards Marshall -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGwSaBq1pz9mNUZTMRAoxDAKCUZ8s/Q/tRF6NC0T7jC6SRFy1zVACgplR4 NZVluA1bG+T0JiZuZrsrVGQ= =Ey48 -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: [policy] When Tech Meets Policy...
Carl Karsten wrote: I am not sure tasting is criminal or fraud. You got what you ordered. You used it. You pay for it. It's that simple. That doesn't make anything criminal or fraud any more than free samples. If a registrar wants to give a refund, I don't see anything wrong with that. It is not even close to that simple, And I'm saying that it can be. Even you have already made a couple of good suggestions to that effect. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Domain tasting; a load of hot air?
On Aug 14, 2007, at 8:56 AM, [EMAIL PROTECTED] wrote: I'd suggest: 1) one week latency between registration and entry into the TLD nameservers. 2) 50% (of 1-year registration fee) 'penalty' for cancelling the registration before it hits the TLD servers. 3) $250 'surcharge' (to registrant) for 'immediate' _irrevocable_ recording in the TLD nameservers, 25% of that surcharge to be retained by the registrar, 25% to the registry operator, and 50% to IANA. Can I assume that you, and all the other people commenting on domain tasting have filed official comments with ICANN as requested at this web page? http://www.icann.org/announcements/announcement-2-10aug07.htm No, but that is an excellent reminder for which I thank you. Note To be considered by the group, information should be submitted no later than 15 September 2007 to [EMAIL PROTECTED] Comments may be viewed at http://forum.icann.org/lists/rfi-domaintasting/. Or is this just a load of hot air as usual? Democracy, you either use it or lose it! --Michael Dillon Regards Marshall
Re: Network Inventory Tool
On 13-Aug-2007, at 23:31, Wguisa71 wrote: Does anyone known some tool for network documentation with: - inventory (cards, serial numbers, manufactor...) - documentation (configurations, software version control, etc) - topology building (L2, L3.. connections, layer control, ...) All-in-one solution and It don't need to be free. I'm just looking for some thing to control the equipments we have like routers from some sort of suppliers, etc... If you don't succeed in finding an all-in-one, vendor-neutral solution which does precisely what you want straight out of the box (and don't feel bad if so, since many have failed before you) there are some clues for rolling your own here: http://www.nanog.org/mtg-0210/ppt/stephen.pdf Joe
Re: Content Delivery Networks
On Tue, 14 Aug 2007, [iso-8859-1] Bjørn Mork wrote: Chris L. Morrow [EMAIL PROTECTED] writes: This is still a client issue as, hopefully, the cache-resolvers don't funnel their business through nscd save when applications on them need lookups... (things like ping/telnet/traceroute/blah) nscd may represent a problem if the application in question is a http-proxy without it's own resolver. There's also a number of more-or-less broken http-proxies doing their own resolver caching regardless of actual TTL. that's fine, that's still a client problem, not a cache-resolver problem... These devices look 'upstream' for a cache-resolver to do their dirty work, these just add an extra layer of indirection for the CDN to figure out (my client is in SFO, my proxy is in IAD, my cache-resolver is in CHI). Such applications represent a problem wrt any DNS-based load balancing, including CDNs, since they can serve a large number of end-users, redirecting them to the wrong address long after the TTL should have expired. Yup, people should be aware of what the systems in their path are doing, or as was mentioned earlier, have lots of exceptions on the CDN side.
Re: Domain tasting; a load of hot air?
On Tue, 14 Aug 2007, Marshall Eubanks wrote: On Aug 14, 2007, at 8:56 AM, [EMAIL PROTECTED] wrote: Can I assume that you, and all the other people commenting on domain tasting have filed official comments with ICANN as requested at this web page? http://www.icann.org/announcements/announcement-2-10aug07.htm No, but that is an excellent reminder for which I thank you. Note yup, thanks Michael. To be considered by the group, information should be submitted no later than 15 September 2007 to [EMAIL PROTECTED] Comments may be viewed at http://forum.icann.org/lists/rfi-domaintasting/. Is this something where a consensus 'vote' from a larger group would help? or one of the letter writing campaigns congress loves so much?
Re: Network Inventory Tool
Excel or any opensoure version of it seems to do the job just fine for us... And you can massage the data any way you want! -Mike On 8/14/07, Joe Abley [EMAIL PROTECTED] wrote: On 13-Aug-2007, at 23:31, Wguisa71 wrote: Does anyone known some tool for network documentation with: - inventory (cards, serial numbers, manufactor...) - documentation (configurations, software version control, etc) - topology building (L2, L3.. connections, layer control, ...) All-in-one solution and It don't need to be free. I'm just looking for some thing to control the equipments we have like routers from some sort of suppliers, etc... If you don't succeed in finding an all-in-one, vendor-neutral solution which does precisely what you want straight out of the box (and don't feel bad if so, since many have failed before you) there are some clues for rolling your own here: http://www.nanog.org/mtg-0210/ppt/stephen.pdf Joe
Re: Network Inventory Tool
I have not tried it, but this looks promising. http://metanav.uninett.no/ http://en.wikipedia.org/wiki/Network_Administration_Visualized Hope this helps -- Brian Raaen Network Engineer [EMAIL PROTECTED] On Monday 13 August 2007 23:31, Wguisa71 wrote: Guys, Does anyone known some tool for network documentation with: - inventory (cards, serial numbers, manufactor...) - documentation (configurations, software version control, etc) - topology building (L2, L3.. connections, layer control, ...) All-in-one solution and It don't need to be free. I'm just looking for some thing to control the equipments we have like routers from some sort of suppliers, etc... Marcio
RE: [policy] When Tech Meets Policy...
On Mon, 13 Aug 2007, Justin Scott wrote: Perhaps it would be better to allow for domain returns, but shorten the time limit to 24 hours. That should be long enough to catch a typo, but too short to be much use for traffic tasting. Still long enough to be useful for spammers :-( Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Mzima networks
Anyone have feedback on their experiences with Mzima Networks? Looking for an Internap alternative and they were recommended to me. Just looking to see if anyone out there has any good insight into the company or actual customer feedback. Technology looks very promising just not a big enough name for me to have all the information. Thanks
Re: [policy] When Tech Meets Policy...
On 8/14/07, Tim Franklin [EMAIL PROTECTED] wrote: On Tue, August 14, 2007 1:48 am, Douglas Otis wrote: For domains to play any role in securing email, a published MX record should become a necessary acceptance requirement. Using MX records also consolidates policy locales which mitigates some DDoS concerns. What if there's no intention to use the domain for email? I've become annoyed enough in the other direction, owning domains *only* used for email and dealing with irate people insisting I'm domain-squatting and must sell them the domain cheaply right now because there's no A record for www.what.ever. I'm annoyed enough in the original direction. I, like many thousands of people, have some domains that I don't use for email, so they don't have an MX record. How do you enforce this new requirement? Who chases it down? How does it stop domain tasting? If this is ultimately to stop domain tasting abuse, why not instead stop domain tasting? It seems like this simply add rules that somebody has to figure out to who enforce, and I'm not exactly inspired to think that it'll be enforced regularly or properly. This seems like creating a requirement that people must implement mosquito nets to solve the mosquito problem, instead of focusing on removing the mosquitos. Al -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA
Re: [policy] When Tech Meets Policy...
On Tue, 14 Aug 2007, Chris L. Morrow wrote: maybe I'm just thick, but how exactly does tastinng inhibit anti-phishing efforts? Domain names are used as loookup keys in anti-phishing blacklists. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
Re: [policy] When Tech Meets Policy...
On 8/14/07, Roger Marquis [EMAIL PROTECTED] wrote: Carl Karsten wrote: I am not saying tasting is a free speech thing, but I do see it as something currently legal, and don't see a way to make it a crime without adversely effecting the rest of the system. It is perfectly legal, and no viable remedies are known other than making it illegal. Attaching a cost seemingly could add a deterrent without needing to make it illegal. Regards, Al -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA
Re: [policy] When Tech Meets Policy...
On Aug 14, 2007, at 9:29 AM, Al Iverson wrote: On 8/14/07, Tim Franklin [EMAIL PROTECTED] wrote: On Tue, August 14, 2007 1:48 am, Douglas Otis wrote: For domains to play any role in securing email, a published MX record should become a necessary acceptance requirement. Using MX records also consolidates policy locales which mitigates some DDoS concerns. What if there's no intention to use the domain for email? I've become annoyed enough in the other direction, owning domains *only* used for email and dealing with irate people insisting I'm domain-squatting and must sell them the domain cheaply right now because there's no A record for www.what.ever. I'm annoyed enough in the original direction. I, like many thousands of people, have some domains that I don't use for email, so they don't have an MX record. How do you enforce this new requirement? Who chases it down? How does it stop domain tasting? If this is ultimately to stop domain tasting abuse, why not instead stop domain tasting? It seems like this simply add rules that somebody has to figure out to who enforce, and I'm not exactly inspired to think that it'll be enforced regularly or properly. All registrations MUST incur a nominal charge applied uniformly. Remove the option permitting domain registration at little or no cost. End of problem. This seems like creating a requirement that people must implement mosquito nets to solve the mosquito problem, instead of focusing on removing the mosquitos. This comment was added as a follow-on note. Sorry for not being clear. Accepting messages from a domain lacking MX records might be risky due to the high rate of domain turnovers. Within a few weeks, more than the number of existing domains will have been added and deleted by then. Spammers take advantage of this flux. Unfortunately SMTP server discovery via A records is permitted and should be deprecated. Once MX records are adopted as an _acceptance_ requisite, domains not intended to receive or send email would be clearly denoted by the absence of MX records. SMTP policy published adjacent to MX records also eliminates a need for email policy discovery as well. Another looming problem. Don't accept a message from a domain without MX records. When there is no policy record adjacent to the MX record, there is no policy, and don't go looking. -Doug
Re: udp fragments, 1472 bytes payload
Are you sure you don't have a customer watching streaming video ? Regards Marshall On Aug 14, 2007, at 7:20 PM, Miguel Mata wrote: I'm being attacked with UDP fragments having a payload 1472 bytes. Seems like a DDoS that only likes to suck bandwidth. Anyone on the same coaster? drop me a line. -- Miguel Mata Gerente de Operaciones Intercom El Salvador [EMAIL PROTECTED] voz: ++(503) 2278-5068 fax: ++(503) 2265-7024 Intercom, sus Telecomunicaciones en buenas manos
Re: [policy] When Tech Meets Policy...
On 8/14/07, Douglas Otis [EMAIL PROTECTED] wrote: This comment was added as a follow-on note. Sorry for not being clear. Accepting messages from a domain lacking MX records might be risky due to the high rate of domain turnovers. Within a few weeks, more than the number of existing domains will have been added and deleted by then. Spammers take advantage of this flux. Unfortunately SMTP server discovery via A records is permitted and should be deprecated. Should be (perhaps) but clearly isn't. When you run it through a standards body and/or obtain broad acceptance; great! Until then, it's pipe dreaming. Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA
Re: [policy] When Tech Meets Policy...
This comment was added as a follow-on note. Sorry for not being clear. Accepting messages from a domain lacking MX records might be risky due to the high rate of domain turnovers. Within a few weeks, more than the number of existing domains will have been added and deleted by then. Spammers take advantage of this flux. Unfortunately SMTP server discovery via A records is permitted and should be deprecated. All it would require is a couple of large ISP's to adopt such a policy. MX 0 self really is not hard and benefits the remote caches. Once MX records are adopted as an _acceptance_ requisite, domains not intended to receive or send email would be clearly denoted by the absence of MX records. SMTP policy published adjacent to MX records also eliminates a need for email policy discovery as well. Another looming problem. Better yet us MX records to signal that you don't want to receive email e.g. MX 0 .. It has a additional benefits in that it is *much* smaller to cache than a negative response. It's also smaller to cache than a A record. Since all valid email domains are required to have a working postmaster you can safely drop any email from such domains. Don't accept a message from a domain without MX records. When there is no policy record adjacent to the MX record, there is no policy, and don't go looking. -Doug
inter-domain link recovery
Hi, folks I find that the link recovery is sometimes very slow when failure occures between different ASes. The outage may last hours. In such cases, it seems that the automatic recovery of BGP-like protocol fails and the repair is took over manually. We should still remember the taiwan earthquake in Dec. 2006 which damaged almost all the submarine cables. The network condition was quit terrible in the following a few days. One may need minutes to load a web page in US from Asia. However, two main cables luckly escaped damage. Furthermore, we actually have more routing paths, e.g., from Asia and Europe over the trans-Russia networks of Rostelecom and TransTeleCom. With these redundent path, the condition should not be that horrible. And here is what I'd like to disscuss with you, especially the network operators, 1. Why BGP-like protocol failed to recover the path sometimes? Is it mainly because the policy setting by the ISP and network operators? 2. What is the actions a network operator will take when such failures occures? Is it the case like that, 1)to find (a) alternative path(s); 2)negotiate with other ISP if need; 3)modify the policy and reroute the traffic. Which actions may be time consuming? 3. There may be more than one alternative paths and what is the criterion for the network operator to finally select one or some of them? 4. what infomation is required for a network operator to find the new route? Thank you. C. Hu
Re: [policy] When Tech Meets Policy...
On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote: Accepting messages from a domain lacking MX records might be risky due to the high rate of domain turnovers. Within a few weeks, more than the number of existing domains will have been added and deleted by then. Spammers take advantage of this flux. SMTP server discovery via A records is permitted and should be deprecated. All it would require is a couple of large ISP's to adopt such a policy. MX 0 self really is not hard and benefits the remote caches. Agreed. While some suggest deprecating A record discovery requires adoption by a standards body, it really only requires a few ISPs to make their intentions public. A small minority of domains lacking an MX record are likely to comply quickly. At that point, adoption by a standards body becomes possible. It is rare to find a standards body willing impose additional requirements on email, but this is a case where such a requirement is clearly necessary. That point forward, spammers would be less able to take advantage of domains in flux, and policy schemes would be far less perilous for roots or second level domains. Once MX records are adopted as an _acceptance_ requisite, domains not intended to receive or send email would be clearly denoted by the absence of MX records. SMTP policy published adjacent to MX records also eliminates a need for email policy discovery as well. Another looming problem. Better yet use MX records to signal that you don't want to receive email e.g. MX 0 .. It has a additional benefits in that it is *much* smaller to cache than a negative response. It's also smaller to cache than a A record. Since all valid email domains are required to have a working postmaster you can safely drop any email from such domains. Use of root . as a name for a target may create undesired non-cached traffic when applications unaware of this convention then attempt to resolve an address for servers named root. The use of root as a convention will complicate a general strategy identifying adoption of a protocol by publication of a discovery record. The use of root as a target name in SRV records has been problematic, although this convention was defined for SRV records at the outset. Using an MX record to mean no email is accepted by naming the target 'root' changes the meaning of the MX record. It is also not clear whether the root target would mean no email is sent as well. A clearer and safer strategy would be to insist that anyone who cares about their email delivery, publish a valid MX record. Especially when the domain is that of a government agency dealing with emergencies. At least FEMA now publishes an MX record. This requirement should have been imposed long ago. : ) -Doug
Re: inter-domain link recovery
On Aug 14, 2007, at 9:06 PM, Chengchen Hu wrote: 1. Why BGP-like protocol failed to recover the path sometimes? Is it mainly because the policy setting by the ISP and network operators? There are an infinitude of possible answers to these questions which have nothing to do with BGP, per se; those answers are very subjective in nature. Can you provide some specific examples (citing, say, publicly-available historical BGP tables available from route-views, RIPE, et. al.) of an instance in which you believe that the BGP protocol itself is the culprit, along with the supporting data which indicate that the prefixes in question should've remained globally (for some value of 'globally') reachable? Or are these questions more to do with the general provisioning of interconnection relationships, and not specific to the routing protocol(s) in question? Physical connectivity to a specific point in a geographical region does not equate to logical connectivity to all the various networks in that larger region; SP networks (and customer networks, for that matter) are interconnected and exchange routing information (and, by implication, traffic) based upon various economic/contractual, technical/operational, and policy considerations which vary greatly from one instance to the next. So, the assertion that there were multiple unaffected physical data links to/from Taiwan in the cited instance - leaving aside for the moment whether this was actually the case, or whether sufficient capacity existed in those links to service traffic to/from the prefixes in question - in and of itself has no bearing on whether or not the appropriate physical and logical connectivity was in place in the form of peering or transit relationships to allow continued global reachability of the prefixes in question. 2. What is the actions a network operator will take when such failures occures? Is it the case like that, 1)to find (a) alternative path(s); 2)negotiate with other ISP if need; 3)modify the policy and reroute the traffic. Which actions may be time consuming? All of the above, and all of the above. Again, it's very situationally dependent. 3. There may be more than one alternative paths and what is the criterion for the network operator to finally select one or some of them? Proximate physical connectivity; capacity; economic/contractual, technical/operational, and policy considerations. 4. what infomation is required for a network operator to find the new route? By 'find the new route', do you mean a new physical and logical interconnection to another SP? The following references should help shed some light on the general principles involved: http://en.wikipedia.org/wiki/Peering http://www.nanog.org/subjects.html#peering http://www.aw-bc.com/catalog/academic/product/ 0,1144,0321127005,00.html --- Roland Dobbins [EMAIL PROTECTED] // 408.527.6376 voice Culture eats strategy for breakfast. -- Ford Motor Company
Re: [policy] When Tech Meets Policy...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -- Douglas Otis [EMAIL PROTECTED] wrote: A clearer and safer strategy would be to insist that anyone who cares about their email delivery, publish a valid MX record. Especially when the domain is that of a government agency dealing with emergencies. At least FEMA now publishes an MX record. This requirement should have been imposed long ago. : ) Let's be clear here -- the fact that a particular domain does, or does not have an MX associated with it, is a separate issue from what this thread originally began: domain tasting, and the gaming of the domain registry system for bad actors. Now, while these issues may indeed be related, the whole MX record thing relates specifically to the issue of spamming -- and there are even larger issues involved here (aside from spamming). :-) Not to demean your point, but just wanted to clarify a couple of talking points. There are completely valid reason why domains can be registered which do not have associated MX records. I can think of several right off of the top-of-my-head. Gaming the domain registry system for illegitimate uses -- that's my main sticking point. Cheers, - - ferg -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.6.2 (Build 2014) wj8DBQFGwoxUq1pz9mNUZTMRAiNmAJ9M4vhP2Nh4zQbBsMiF3RAJCS8yWgCgrKjf P/FRS+0SNyE59NK2KrfcnUo= =Aegb -END PGP SIGNATURE- -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: [policy] When Tech Meets Policy...
On Tue, 14 Aug 2007, Douglas Otis wrote: That point forward, spammers would be less able to take advantage of domains in flux, and policy schemes would be far less perilous for are spammers really doing this? do they mine the domain system for changes and utilze those for their purposes? I ask because i don't see that in my data, which is small admittedly... I see lots of existing well known domains in the 'from'. Unless you have some data showing otherwise (or someone else has data to share) I think this is a specious arguement.
Re: [policy] When Tech Meets Policy...
On Wed, 2007-08-15 at 11:58 +1000, Mark Andrews wrote: Accepting messages from a domain lacking MX records might be risky due to the high rate of domain turnovers. Within a few weeks, more than the number of existing domains will have been added and deleted by then. Spammers take advantage of this flux. SMTP server discovery via A records is permitted and should be deprecated. All it would require is a couple of large ISP's to adopt such a policy. MX 0 self really is not hard and benefits the remote caches. Agreed. While some suggest deprecating A record discovery requires adoption by a standards body, it really only requires a few ISPs to make their intentions public. A small minority of domains lacking an MX record are likely to comply quickly. At that point, adoption by a standards body becomes possible. It is rare to find a standards body willing impose additional requirements on email, but this is a case where such a requirement is clearly necessary. That point forward, spammers would be less able to take advantage of domains in flux, and policy schemes would be far less perilous for roots or second level domains. Once MX records are adopted as an _acceptance_ requisite, domains not intended to receive or send email would be clearly denoted by the absence of MX records. SMTP policy published adjacent to MX records also eliminates a need for email policy discovery as well. Another looming problem. Better yet use MX records to signal that you don't want to receive email e.g. MX 0 .. It has a additional benefits in that it is *much* smaller to cache than a negative response. It's also smaller to cache than a A record. Since all valid email domains are required to have a working postmaster you can safely drop any email from such domains. Use of root . as a name for a target may create undesired non-cached traffic when applications unaware of this convention then attempt to resolve an address for servers named root. All modern iterative resolvers are required to support negative caching. The use of root as a convention will complicate a general strategy identifying adoption of a protocol by publication of a discovery record. The use of root as a target name in SRV records has been problematic, although this convention was defined for SRV records at the outset. Using an MX record to mean no email is accepted by naming the target 'root' changes the meaning of the MX record. Not really. It's entirely consistant with existing DNS usage where . is a domain name / hostname place holder. Lots of RR types use . to indicate non-existance. It is also not clear whether the root target would mean no email is sent as well. That is, I'll agree, more of a issue but no one can reasonably expect people to accept non-repliable email. A clearer and safer strategy would be to insist that anyone who cares about their email delivery, publish a valid MX record. Especially when the domain is that of a government agency dealing with emergencies. At least FEMA now publishes an MX record. This requirement should have been imposed long ago. : ) I much prefer positive data vs the absence of data to make a decision. MX 0 . is a definative response saying you don't want email. -Doug -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
Re: inter-domain link recovery
On Aug 15, 2007, at 12:06 AM, Chengchen Hu wrote: I find that the link recovery is sometimes very slow when failure occures between different ASes. The outage may last hours. In such cases, it seems that the automatic recovery of BGP-like protocol fails and the repair is took over manually. We should still remember the taiwan earthquake in Dec. 2006 which damaged almost all the submarine cables. The network condition was quit terrible in the following a few days. One may need minutes to load a web page in US from Asia. However, two main cables luckly escaped damage. Furthermore, we actually have more routing paths, e.g., from Asia and Europe over the trans-Russia networks of Rostelecom and TransTeleCom. With these redundent path, the condition should not be that horrible. And here is what I'd like to disscuss with you, especially the network operators, 1. Why BGP-like protocol failed to recover the path sometimes? Is it mainly because the policy setting by the ISP and network operators? Why do you think BGP was supposed to find the remaining path? Is it possible that the remaining fibers were not owned or leased by the networks in question? Or are you suggesting that any capacity should be available to anyone who needs it, whether they pay or not? BGP cannot find a path that the business rules forbid. -- TTFN, patrick 2. What is the actions a network operator will take when such failures occures? Is it the case like that, 1)to find (a) alternative path(s); 2)negotiate with other ISP if need; 3)modify the policy and reroute the traffic. Which actions may be time consuming? 3. There may be more than one alternative paths and what is the criterion for the network operator to finally select one or some of them? 4. what infomation is required for a network operator to find the new route? Thank you. C. Hu
