Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
At 10:32 PM -0400 2005-07-04, Jay R. Ashworth wrote: But the whole there's a non-ICANN root: the sky is falling thing is an argument cooked up to scare the unwashed; us old wallas don't buy it. That's because you understand the underlying technology, and you understand how to deal with the problem (including understanding that you may just have to live with it). Most people don't understand the underlying technology or the true nature of the problem, nor are they capable of doing so. All they know is that their e-mail doesn't work, or they can't get to the web pages they want. And for them, this is a very real problem. Since there's a lot more of them than there are of us, and we're the ones who are likely to be operating the systems and networks where these people are our customers, when they have a problem, that creates a problem for us. Moreover, most of them are unlikely to be willing to just live with the problem, if no other suitable technical solution can be found. Instead, they'll believe the sales pitch of someone else who says that they can fix the problem, even if that's not technically possible. Okay, the sky may not be falling. Maybe it's just the Cyclorama, or the fly grid. But when the actors are on stage and one of these things falls, there's not much practical difference. And us techies are the ones that have to pick up the pieces and try to put them back together again. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: Enable BIND cache server to resolve chinese domain name?
Remember the paraphrase from Voltaire: I disapprove of what you say, but I will defend to the death your right to say it I have said that before on many occasions. However, in this case, I do not defend your right to say it. In my opinion, your doing so undermines the most fundamental basis of the Internet. Sorry comrades, I can no longer participate in this discussion. It seems that I have been declared to be an enemy of the people. --Michael Dillon
Re: Enable BIND cache server to resolve chinese domain name?
[EMAIL PROTECTED] wrote: Remember the paraphrase from Voltaire: I disapprove of what you say, but I will defend to the death your right to say it I have said that before on many occasions. However, in this case, I do not defend your right to say it. In my opinion, your doing so undermines the most fundamental basis of the Internet. Sorry comrades, I can no longer participate in this discussion. It seems that I have been declared to be an enemy of the people. Michael stay with us. If anybody is trying to make a fool out of himself it is me or Brad. Look in the bible - an old one if you have. There in three places at least it says: Thou maye not have another Root in front of me so BESIDE is definitley allowed. Roman Catholics tend to translate that in the wrong way - if at all. Sorry if my english is a bit teutonic or canucked :) Yes I know - seeing there is more than one root is a bit of a shock - much as the existence of America (I mean back in 1512) Kind regards, Peter and Karin Dambier --Michael Dillon -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) +1-360-448-1275 (VoIP: freeworldialup.com) +1-360-226-6583-9563 (INAIC) mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Tue, Jul 05, 2005 at 01:14:08AM -0400, [EMAIL PROTECTED] wrote: On Mon, 04 Jul 2005 22:32:52 EDT, Jay R. Ashworth said: Well, Steve; that reply is a *little* disingenuous: all of the alternative root zones and root server clusters that *I'm* aware of track the ICANN root, except in the rare instances where there are TLD collisions. And *that* is just a tad disingenuous itself. If you have 1 alternate root that tracks ICANN's dozen-ish TLDs and the country-code TLDs, and then adds 2-3 dozen of its own, there's little room for amusement. If however, you have a Turkish root that tracks ICANN's dozen, and then adds 50 or 60 of its own, and a Chinese root that tracks ICANN's dozen, and then adds 75 or 100 of its own, it becomes interesting to watch a Turkish user try to reach one of those 75 Chinese TLDs, or the Chinese user try to reach one of the 50 Turkish additions, or either of those users trying to reach the *.special-sauce domain the first alternate root created. A collision isn't the only failure mode to worry about And I didn't say it was, Valdis. I am fairly familiar with the potential problems of conflicting root zones, and, to date, I observe that -- in general -- they have fairly consistently failed to occur. Indeed, though, if governments get into the act, things are more likely to get broken. But Steve appeared to be suggesting that there was no reasonable way to *avoid* problems -- and that's clearly not the case. If I misinterpreted Steve, no doubt he'll correct me. But there are two fairly prominent, widely operated alternate root zones out there, ORSC, and P-R, which don't collide as far as I know, and between them probably account for a large percentage of the .01% of networks resolving off of non-ICANN roots. Seems to me any country wanting to build an alternate ccTLD and choosing one which is available in both those roots and not known to be planned as an active TLD at ICANN would be in pretty good shape. And don't most of us consider ourselves engineering types here? You deal with what *is*, not what you'd *like* to be. Sure, multiple, only informally synchronized roots aren't the best state of affairs. But they don't exist simply because one guy thought it would be cool; this isn't Joe's Bar and Root Zone we're talking about here... Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: Enable BIND cache server to resolve chinese domain name?
On Mon, 4 Jul 2005, Paul Vixie wrote: for those excellent readers who didn't follow this, here's an excerpt from http://european.de.orsn.net/faq.php#opmode: [skip] what this means is, it can't conflict with ICANN data other than that if ICANN deletes something it might not show up in ORSN. mathematically speaking that's a superset, but politically speaking it's not at all like an alternative root. While I doubt ICANN would delete a TLD zone (and if that happened it would presumably be for dead tld which no requests are expected to come to), I'm concerned that their system might work in regards to to host glue records which there are quite a number of in root zone. If some nameserver is no longer used by TLD and and now it wants to change its ip address, it would presumably request deletion of its glue record from root zone and then be able to change ip with no effect on anyone on the net. But if ORSN does not pick it up this would mean they will continue to use old ip address and that would cause inconsistency (which I suspect will not be easy to track either). What I don't understand why for their project they don't just go ahead and copy ICANN root zone as-is. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Fundamental changes to Internet architecture
At 12:41 PM 7/3/2005, Jay R. Ashworth wrote: On Fri, Jul 01, 2005 at 10:44:33AM -0500, John Dupuy wrote: However, philosophically: security=less trust vs. scalability=more trust. intelligent=smart-enough-to-confuse vs. simple=predictable. Thus, a very Intelligent Secure network is usually a nightmare of unexplained failures and limited scope. Counter-example: SS7. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer+-Internetworking--+--+ RFC 2100 Ashworth Associates | Best Practices Wiki | |'87 e24 St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274 If you can read this... thank a system administrator. Or two. --me That is a good counter example, although it comes with some caveats. I work with SS7 regularly. SS7 should be simple since it performs a simple function, it is actually complicated and complex. But, since SS7 takes us away from the human-managed static routing of the older (MF?) trunk networks systems, it's intelligence creates redundancy and limited failover. Perhaps Clark will create something that is win-win like that... (I assume you are giving this as a intelligent vs. simple counter-example, since SS7 is an example of good scale because it trusts blindingly.) John
Re: Enable BIND cache server to resolve chinese domain name?
william(at)elan.net wrote: On Mon, 4 Jul 2005, Paul Vixie wrote: for those excellent readers who didn't follow this, here's an excerpt from http://european.de.orsn.net/faq.php#opmode: [skip] what this means is, it can't conflict with ICANN data other than that if ICANN deletes something it might not show up in ORSN. mathematically speaking that's a superset, but politically speaking it's not at all like an alternative root. While I doubt ICANN would delete a TLD zone (and if that happened it would presumably be for dead tld which no requests are expected to come to), I'm concerned that their system might work in regards to to host glue records which there are quite a number of in root zone. If some nameserver is no longer used by TLD and and now it wants to change its ip address, it would presumably request deletion of its glue record from root zone and then be able to change ip with no effect on anyone on the net. But if ORSN does not pick it up this would mean they will continue to use old ip address and that would cause inconsistency (which I suspect will not be easy to track either). check_soa from the O'Reilly book 'DNS and Bind' will do or dig XXX +nsserach What I don't understand why for their project they don't just go ahead and copy ICANN root zone as-is. Copyright reasons. But nevertheless those 261 zones are watched to be synchronous to the ICANN root. And there is another check that sees when suddenly a new zone appears like it did for '.eu' some month ago. Both Public-Root and ORSN had it the very same day. I have seen when ORNS and ICANN were out of sync ORSN hat the information from the zone file for 'at', '.de' and '.gr' while ICANN had stale information for a very long time. Same went for '.ke' and the Public-Root for a month or two. Regards, Peter and Karin Dambier -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) +1-360-448-1275 (VoIP: freeworldialup.com) +1-360-226-6583-9563 (INAIC) mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Tue, 5 Jul 2005, Jay R. Ashworth wrote: But Steve appeared to be suggesting that there was no reasonable way to *avoid* problems -- and that's clearly not the case. If I misinterpreted Steve, no doubt he'll correct me. But there are two fairly prominent, I don't think that was what I said. What I was attempting to say is that the issue of alternate roots probably isn't something that's worth worrying about. I see no reason why they'll catch on, other than perhaps in limited cases where they'll work ok. In the general case, with alternate roots, there's a chicken and egg problem. Right now, if you're an end user doing your DNS lookups via the ICANN root, you can get to just about everything. If you're something that end users want to connect to, using an ICANN-recognized domain will mean almost everybody can get to you, while an alternative TLD would mean only a tiny fraction of the Internet would be able to get to you. So, if you're a content provider, why would you use anything other than a real ICANN-recognized domain? And, if the content providers aren't using real domain names, why would an end user care about whether they can get to the TLDs that nobody is using? This is the same phonomenon we saw ten years ago, as the various online services, GENIE, Prodigy, MCIMail, Compuserve, AOL, etc. either interconnected their e-mail systems with the Internet or faded away and died. As the Internet got more and more critical mass, there was less and less incentive to be using something else. It's been a long time since I've seen a business card with several different, incompatible, e-mail addresses printed on it, and that's because something simpler worked, not because people screamed loudly about the falling sky. The exceptions to this that I see would be either when somebody comes out with something that is so much better that it's useful in spite of a lack of an installed userbase (Skype may be doing this to phone calls), or when something is rolled out to a large enough self-contained user community that the lack of ability to communicate outside that region won't be a significant barrier. If a few large countries were to roll out alternate root zones nation-wide, in such a way that they worked well for domestic communication, but couldn't be used for international stuff, *maybe* that would be good enough to catch on. But still, anybody wanting to communicate outside that region or userbase would probably find they were much happier using addresses that met global standards. So anyhow, that's a long way of saying that, just as this hasn't gone anywhere any of the many other times it's been raised over the last several years, it's unlikely to go anywhere, or cause problems, this time. -Steve
Re: Enable BIND cache server to resolve chinese domain name?
I don't think the root zone is sufficiently original to be legally copyrightable. And we don't have database copyright in the US. Even if it were copyrightable, it is made avaiable for download hence there is good reason to assume an implied license. On Tue, 5 Jul 2005, Peter Dambier wrote: william(at)elan.net wrote: [in response to] What I don't understand why for their project they don't just go ahead and copy ICANN root zone as-is. Copyright reasons. -- http://www.icannwatch.org Personal Blog: http://www.discourse.net A. Michael Froomkin |Professor of Law| [EMAIL PROTECTED] U. Miami School of Law, P.O. Box 248087, Coral Gables, FL 33124 USA +1 (305) 284-4285 | +1 (305) 284-6506 (fax) | http://www.law.tm --It's hot here.--
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
steve, all. On Tue, Jul 05, 2005 at 10:01:22AM -0700, Steve Gibbard wrote: problem. Right now, if you're an end user doing your DNS lookups via the ICANN root, you can get to just about everything. If you're something that end users want to connect to, using an ICANN-recognized domain will mean almost everybody can get to you, while an alternative TLD would mean only a tiny fraction of the Internet would be able to get to you. So, if you're a content provider, why would you use anything other than a real ICANN-recognized domain? And, if the content providers aren't using real domain names, why would an end user care about whether they can get to the TLDs that nobody is using? s/ICANN root/real Internet/ s/alternative TLD/IPv6/ The exceptions to this that I see would be either when somebody comes out with something that is so much better that it's useful in spite of a lack of an installed userbase (Skype may be doing this to phone calls), or when something is rolled out to a large enough self-contained user community that the lack of ability to communicate outside that region won't be a significant barrier. [...] But still, anybody wanting to communicate outside that region or userbase would probably find they were much happier using addresses that met global standards. all of this applies directly to lack of IPv6 adoption, again. So anyhow, that's a long way of saying that, just as this hasn't gone anywhere any of the many other times it's been raised over the last several years, it's unlikely to go anywhere, or cause problems, this time. so does this. IPv6: unlikely to go anywhere or cause problems. good to know. funny. all threads eventually merge. (and then someone mentions the nazis and they end. i think meta-mentions like this explicitly don't count so we may have to suffer through this thread for a while longer). t. -- _ todd underwood director of operations security renesys - interdomain intelligence [EMAIL PROTECTED] www.renesys.com
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Tue, 5 Jul 2005, Todd Underwood wrote: problem. Right now, if you're an end user doing your DNS lookups via the ICANN root, you can get to just about everything. If you're something that end users want to connect to, using an ICANN-recognized domain will mean almost everybody can get to you, while an alternative TLD would mean only a tiny fraction of the Internet would be able to get to you. So, if you're a content provider, why would you use anything other than a real ICANN-recognized domain? And, if the content providers aren't using real domain names, why would an end user care about whether they can get to the TLDs that nobody is using? s/ICANN root/real Internet/ s/alternative TLD/IPv6/ That isn't as perfect a simile as you're attempting to make it, because the pairs do not have the same relationships to each other: With ICANN vs. non-ICANN roots, you have one in isolated parallel to the other, with one happening to imitate the contents of the other. (In addition, you have multiple non-ICANN roots which do not imitate each other.) With IPv4 vs. IPv6, you have one as an integrable parallel to the other, where both can operate simultaneously from any host, and interoperability of single-type connectivity can be accomplished at the low protocol level (NAT-PT and similar). Non-ICANN vs. ICANN is much more like OSI vs. IP, rather than IPv6 vs. IPv4. Good try, though. -- -- Todd Vierling [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Tue, Jul 05, 2005 at 10:01:22AM -0700, Steve Gibbard wrote: On Tue, 5 Jul 2005, Jay R. Ashworth wrote: But Steve appeared to be suggesting that there was no reasonable way to *avoid* problems -- and that's clearly not the case. If I misinterpreted Steve, no doubt he'll correct me. But there are two fairly prominent, I don't think that was what I said. What I was attempting to say is that the issue of alternate roots probably isn't something that's worth worrying about. I see no reason why they'll catch on, other than perhaps in limited cases where they'll work ok. Catch on in the consumer sense? No, probably not -- though the question is will IAP's switch their resolver servers to an alt-root which leads directly to: In the general case, with alternate roots, there's a chicken and egg problem. Right now, if you're an end user doing your DNS lookups via the ICANN root, you can get to just about everything. If you're something that end users want to connect to, using an ICANN-recognized domain will mean almost everybody can get to you, while an alternative TLD would mean only a tiny fraction of the Internet would be able to get to you. So, if you're a content provider, why would you use anything other than a real ICANN-recognized domain? And, if the content providers aren't using real domain names, why would an end user care about whether they can get to the TLDs that nobody is using? Two points: 1) this speaks to the same issue as my comments the other day on the IPv6 killer app, though it's admittedly even harder to posit a site which would do this. 2) Based on the events earlier in the week, I believe that's a US Department of Commerce approved TLD... which changes the game a little bit. This is the same phonomenon we saw ten years ago, as the various online services, GENIE, Prodigy, MCIMail, Compuserve, AOL, etc. either interconnected their e-mail systems with the Internet or faded away and died. As the Internet got more and more critical mass, there was less and less incentive to be using something else. It's been a long time since I've seen a business card with several different, incompatible, e-mail addresses printed on it, and that's because something simpler worked, not because people screamed loudly about the falling sky. Certainly. But there weren't geopolitical implications there, merely commercial ones. I think the stakes may be a bit higher here, particularly in the case we were using as an example: China. The exceptions to this that I see would be either when somebody comes out with something that is so much better that it's useful in spite of a lack of an installed userbase (Skype may be doing this to phone calls), Yup. Killer apps are great. Hard to predict; *really* hard to invent. or when something is rolled out to a large enough self-contained user community that the lack of ability to communicate outside that region won't be a significant barrier. If a few large countries were to roll out alternate root zones nation-wide, in such a way that they worked well for domestic communication, but couldn't be used for international stuff, *maybe* that would be good enough to catch on. But still, anybody wanting to communicate outside that region or userbase would probably find they were much happier using addresses that met global standards. But again, you're positing that someone would create a root zone that *purposefully* conflicted with the current one, which doesn't seem supported by history, much less common sense. Am I wrong that you mean that? So anyhow, that's a long way of saying that, just as this hasn't gone anywhere any of the many other times it's been raised over the last several years, it's unlikely to go anywhere, or cause problems, this time. Maybe. China's *really* big. America's *really* unpopular, in some places. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
What? You mean that marketing spin doesn't convince you of how much a killer app something is? ;-) - ferg -- Jay R. Ashworth [EMAIL PROTECTED] wrote: Yup. Killer apps are great. Hard to predict; *really* hard to invent. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
RE: Enable BIND cache server to resolve chinese domain name?
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steve Gibbard Sent: Monday, July 04, 2005 1:20 AM To: [EMAIL PROTECTED] Subject: Re: Enable BIND cache server to resolve chinese domain name? On Mon, 4 Jul 2005, Mark Andrews wrote: [ SNIP ] That doesn't mean a competing system wouldn't work, for those who are using it. They'd just be limited in who they could talk to, and that generally wouldn't be very appealing. Are you just making noise here, Steve? That doesn't really say anything outside of status quo. That said, a big country implementing a new DNS root on a national scale may not have that problem. The telecom world is already full of systems that don't cross national borders. In the US case, think of all the cell phones that have international dialing turned off by default, That's a poor example. That's between the subscriber and their carrier, not a technical limitation. and all the 800 numbers whose owners probably aren't at all bothered by their inability to receive calls from other countries. That's also a poor example since there are work arounds for this technical issue. A system that would limit my ability to talk to people in other countries doesn't sound very appealing to me. I know. I know. Don't feed the trolls. -M
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
At 9:43 AM -0400 2005-07-05, Jay R. Ashworth wrote: Moreover, most of them are unlikely to be willing to just live with the problem, if no other suitable technical solution can be found. Instead, they'll believe the sales pitch of someone else who says that they can fix the problem, even if that's not technically possible. Well they might. Well, actually, poorly they might. But that argument seems to play right *to* the alt-root operators, since the fix is to switch your customer resolvers to point to one of them. I disagree. The problem is that there are too many alternatives. (Assuming, of course, they stay supersets of ICANN, and don't get at cross-purposes with one another.) The problem is that they are pretty much guaranteed to get at cross-purposes. In fact, merging them at your resolvers might be the best solution. I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant. The alternative roots will always be marginal, at best. The problem is that while they are marginal, they can still create serious problems for the rest of us. But Steve's approach doesn't seem to *me* to play in that direction. Am I wrong? I'm not sure I understand which Steve you're talking about. Do you mean Steve Gibbard, in his post dated Sun, 3 Jul 2005 22:20:13 -0700 (PDT)? If so, then each country running their own alternative root won't solve the problem of data leaking through the edges. People will always be able to access data by pure IP address, or choosing to use the real root servers. Push come to shove, and the real root servers could be proxied through other systems via other methods. The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
OT? /dev/null 5.1.1 email
disclaimer I know this is an email-only question, however the value of the feedback from NANOG is greater than elsewhere, imho. /disclaimer Should undeliverable email (5.1.1, User unknown) be directed to /dev/null rather than responded to? I was always under the impression that it was nice to respond with a polite message, however these days it seems that 95% of the polite responses are going to 5.1.1 addresses themselves. Tia, -Jim P.
Re: OT? /dev/null 5.1.1 email
Should undeliverable email (5.1.1, User unknown) be directed to /dev/null rather than responded to? one current fashion is to try to catch it as early in the smtp receipt process as possible and reject the mail to the smtp sender. this gives the rejection to the real source as opposed to the joe job name. randy
Re: source for GIS-correlated fiber conduit data
On Mon, 4 Jul 2005, Sam Crooks wrote: Can anyone point me in the direction of a source for fiber cable installations correlated to GIS data? You will probably have difficulty in getting this from your carriers of choice. Chances are, if they provide anything at all, it would be done under NDA. jms
Re: OT? /dev/null 5.1.1 email
On Tue, 2005-07-05 at 09:42 -1000, Randy Bush wrote: Should undeliverable email (5.1.1, User unknown) be directed to /dev/null rather than responded to? one current fashion is to try to catch it as early in the smtp receipt process as possible and reject the mail to the smtp sender. this gives the rejection to the real source as opposed to the joe job name. Thanks Randy, It just dawned on me that rejects are in fact occurring early in the receipt process on the primary MX. This is nicely done via Sendmail's virtualusers table having a complete and accurate list of who is valid for the domains handled by that MX. However, is seems the problem is over on the secondary MX (Postfix) which only has a list of legit relay domains for pMX. When pMX is back online sMX fwds it's queue, but at that point pMX rejects to sMX...who then rejects to Sender. I'm not sure how I can get away from that happening. -Jim P.
Re: OT? /dev/null 5.1.1 email
However, is seems the problem is over on the secondary MX (Postfix) which only has a list of legit relay domains for pMX. When pMX is back online sMX fwds it's queue, but at that point pMX rejects to sMX...who then rejects to Sender. I'm not sure how I can get away from that happening. what is the purpose of having a secondary mx? randy
Re: source for GIS-correlated fiber conduit data
On Tue, 5 Jul 2005, Justin M. Streiner wrote: On Mon, 4 Jul 2005, Sam Crooks wrote: Can anyone point me in the direction of a source for fiber cable installations correlated to GIS data? You will probably have difficulty in getting this from your carriers of choice. Chances are, if they provide anything at all, it would be done under NDA. Didn't Sean Doran do this out of GMU about 2 years ago? and get slapped with some silly classification by the us-gov for it? (or am I thinking of another sean?)
Re: OT? /dev/null 5.1.1 email
On Tue, 2005-07-05 at 10:05 -1000, Randy Bush wrote: However, is seems the problem is over on the secondary MX (Postfix) which only has a list of legit relay domains for pMX. When pMX is back online sMX fwds it's queue, but at that point pMX rejects to sMX...who then rejects to Sender. I'm not sure how I can get away from that happening. what is the purpose of having a secondary mx? The first one goes up and down more than it probably should. :-) The principle purpose of the secondary mx, in this case, is to accept email for the primary mx during periods where the primary is down, being re-configured, or loadavg 10. The primary handles a few chatty mailinglists, and other than abuse@, postmaster@, admin@, there are no real user accounts involved. My only reason for not dropping the secondary mx is that, while I am a big proponent of using your upstream SMTP server, those who deliver directly would get temporarily unavailable messages (or worse). Of course, at least on the primary, most of those that deliver directly are dropped due to DUL RBLs. -Jim P.
Re: source for GIS-correlated fiber conduit data
Date: Tue, 05 Jul 2005 20:09:39 + (GMT) From: Christopher L. Morrow [EMAIL PROTECTED] On Tue, 5 Jul 2005, Justin M. Streiner wrote: On Mon, 4 Jul 2005, Sam Crooks wrote: Can anyone point me in the direction of a source for fiber cable installations correlated to GIS data? You will probably have difficulty in getting this from your carriers of choice. Chances are, if they provide anything at all, it would be done under NDA. Didn't Sean Doran do this out of GMU about 2 years ago? and get slapped with some silly classification by the us-gov for it? (or am I thinking of another sean?) Someone did but it was not limited to fiber but included utilities... And did get slapped down for putting together publicly available info into a usable form... - I am perfectly capable of learning from my mistakes. I will surely learn a great deal today. A democracy is a sheep and two wolves deciding on what to have for lunch. Freedom is a well armed sheep contesting the results of the decision. - Benjamin Franklin The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton
Re: source for GIS-correlated fiber conduit data
On Tue, 5 Jul 2005, Christopher L. Morrow wrote: On Tue, 5 Jul 2005, Justin M. Streiner wrote: On Mon, 4 Jul 2005, Sam Crooks wrote: Can anyone point me in the direction of a source for fiber cable installations correlated to GIS data? You will probably have difficulty in getting this from your carriers of choice. Chances are, if they provide anything at all, it would be done under NDA. Didn't Sean Doran do this out of GMU about 2 years ago? and get slapped with some silly classification by the us-gov for it? (or am I thinking of another sean?) I do recall someone pulling together data that got a lot of the homeland security types all riled up, but I don't recall the source. From past experience, the OSP route maps I've seen for $CARRIER have been 1) done under strict NDA (we will show you the map only in our presence, you cannot keep it, make copies, scan it, smell it, touch it, etc) and 2) only for very specific cable routes that were directly relevant to my original request. jms
Re: OT? /dev/null 5.1.1 email
The first one goes up and down more than it probably should. :-) Make your secondary mx aware of all the valid recipient addresses. Adi
Re: OT? /dev/null 5.1.1 email
On Tue, 2005-07-05 at 15:27 -0500, Adi Linden wrote: The first one goes up and down more than it probably should. :-) Make your secondary mx aware of all the valid recipient addresses. Thank you Adi, Chris, Randy, Daniel, etc. ;-) Syncing virtual/valid users seems to be the preferred method for dealing with this, as opposed to just dev/null'ing. Since the two systems are relatively compatible, I'll look into just pushing the virtualtable to the postfix system. Thanks all, -Jim P.
Re: source for GIS-correlated fiber conduit data
On Tue, 5 Jul 2005, Christopher L. Morrow wrote: On Tue, 5 Jul 2005, Justin M. Streiner wrote: On Mon, 4 Jul 2005, Sam Crooks wrote: Can anyone point me in the direction of a source for fiber cable installations correlated to GIS data? You will probably have difficulty in getting this from your carriers of choice. Chances are, if they provide anything at all, it would be done under NDA. Didn't Sean Doran do this out of GMU about 2 years ago? and get slapped with some silly classification by the us-gov for it? (or am I thinking of another sean?) sean GORMAN... doh! (as 3+ people already pointed out to me, one even with the washingtonpost article a link to that article: http://www.washingtonpost.com/ac2/wp-dyn?pagename=articlecontentId=A23689-2003Jul7notFound=true -chris
Re: OT? /dev/null 5.1.1 email
At 4:00 PM -0400 2005-07-05, Jim Popovitch wrote: However, is seems the problem is over on the secondary MX (Postfix) which only has a list of legit relay domains for pMX. When pMX is back online sMX fwds it's queue, but at that point pMX rejects to sMX...who then rejects to Sender. Yup, and a lot of spammers take advantage of this fact by directly connecting to the secondary MXes of their targets, and never connecting to the primary MXes. I'm not sure how I can get away from that happening. Short of having a complete list of all your valid recipients on the secondary MX, or having some way for them to obtain this information, I don't think you can. Also note that you have to completely replicate the full anti-spam/anti-virus configuration from the primary MXes to the secondary MXes, for the same reasons. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: OT? /dev/null 5.1.1 email
At 4:35 PM -0400 2005-07-05, Daniel Senie wrote: Use something like LDAP to do the lookups on the primary, or rsync over files so you can do the rejects on the secondary, perhaps. Given you said in another message your primary freaks on occasion, I guess the LDAP would need to be to some third server. Do an LDAP master database somewhere, then put LDAP slaves on each mail server that needs to access that information. Not too hard. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Tue, Jul 05, 2005 at 08:38:41PM +0200, Brad Knowles wrote: At 9:43 AM -0400 2005-07-05, Jay R. Ashworth wrote: Moreover, most of them are unlikely to be willing to just live with the problem, if no other suitable technical solution can be found. Instead, they'll believe the sales pitch of someone else who says that they can fix the problem, even if that's not technically possible. Well they might. Well, actually, poorly they might. But that argument seems to play right *to* the alt-root operators, since the fix is to switch your customer resolvers to point to one of them. I disagree. The problem is that there are too many alternatives. To many alt-roots? Or too many alt-TLD's? (Assuming, of course, they stay supersets of ICANN, and don't get at cross-purposes with one another.) The problem is that they are pretty much guaranteed to get at cross-purposes. Well, there have been alt-root zones available for, what 6 or 7 years now? And how many collisions have there actually been in practice? 2? 3? In fact, merging them at your resolvers might be the best solution. I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant. Well, I meant at your customer recursive resolver servers, since the topic at hand was what do IAP's do to support their retail customers, but... The alternative roots will always be marginal, at best. The problem is that while they are marginal, they can still create serious problems for the rest of us. In the context which people have been discussing, I don't honestly see how they cause the rest of us problems. People with domains *in* those aTLD's, yes. But as I noted somewhere else in this thread, the only people who would have un-mirrored aTLD domains would be precisely those who were evangelising for the concept, and it would be in their best interest to be explaining what was going on... But Steve's approach doesn't seem to *me* to play in that direction. Am I wrong? I'm not sure I understand which Steve you're talking about. Do you mean Steve Gibbard, in his post dated Sun, 3 Jul 2005 22:20:13 -0700 (PDT)? I did mean Mr. Gibbard, yes. If so, then each country running their own alternative root won't solve the problem of data leaking through the edges. Data leaking through the edges... People will always be able to access data by pure IP address, or choosing to use the real root servers. Push come to shove, and the real root servers could be proxied through other systems via other methods. Real is *such* a metaphysical term here, isn't it? :-) The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root. Stipulated. But whose problem *is* that? Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: source for GIS-correlated fiber conduit data
On 7/5/05, Gregory Hicks [EMAIL PROTECTED] wrote: Someone did but it was not limited to fiber but included utilities... And did get slapped down for putting together publicly available info into a usable form... Where are these publicly available records that Sean Gorman and TeleGeography are using to develop these maps? I've tried in ernest to find even a starting point to no avail. aaron.glenn
Net traffic explodes for NASA'S comet collision
I hope many of you saw this near- real-time. It was awsome. Roy Mark writes for internetnews.com: [snip] Deep Impact's spectacular collision with the comet Tempel 1 resulted in an explosion of record traffic to the NASA Web site to see how it looked. The hyper-speed demise of the ship's probe, as it smashed into a comet half the size of Manhattan, generated approximately 80 million page views. It's off the scale, Brian Dunbar, NASA's Internet Services Manager, told internetnews.com, noting the previous traffic record was 30 million page views for the Mars landing in 2004. Hands down, it was a record day. [snip] http://www.internetnews.com/xSP/article.php/3517721 Pretty cool stuff. :-) - ferg ps. We should also be aware of how far AOL has come, too, since the 1996 Victoria's Secret fashion show. From every report, they pulled off streaming 7 simulateous video feeds of the Live 8 concerts this past weekend without any substantial problems whatsoever. http://news.yahoo.com/news?tmpl=storyu=/ap/20050705/ap_en_bu/internet_video_performs Time they are a'changin'. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: Net traffic explodes for NASA'S comet collision
On Tue, 5 Jul 2005 22:54:59 GMT Fergie (Paul Ferguson) [EMAIL PROTECTED] wrote: I hope many of you saw this near- real-time. It was awsome. It was indeed. I like to use Alexa to look at web site rankings, so here is a comparison of the recent encounter and the Mars Rover landings http://www.americafree.tv/rankings/nasa.html It does indeed seem to have been more popular. Regards Marshall Roy Mark writes for internetnews.com: [snip] Deep Impact's spectacular collision with the comet Tempel 1 resulted in an explosion of record traffic to the NASA Web site to see how it looked. The hyper-speed demise of the ship's probe, as it smashed into a comet half the size of Manhattan, generated approximately 80 million page views. It's off the scale, Brian Dunbar, NASA's Internet Services Manager, told internetnews.com, noting the previous traffic record was 30 million page views for the Mars landing in 2004. Hands down, it was a record day. [snip] http://www.internetnews.com/xSP/article.php/3517721 Pretty cool stuff. :-) - ferg ps. We should also be aware of how far AOL has come, too, since the 1996 Victoria's Secret fashion show. From every report, they pulled off streaming 7 simulateous video feeds of the Live 8 concerts this past weekend without any substantial problems whatsoever. http://news.yahoo.com/news?tmpl=storyu=/ap/20050705/ap_en_bu/internet_video_performs Time they are a'changin'. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet [EMAIL PROTECTED] or [EMAIL PROTECTED] ferg's tech blog: http://fergdawg.blogspot.com/
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Wed, Jul 06, 2005 at 01:06:15AM +0200, Brad Knowles wrote: To many alt-roots? Or too many alt-TLD's? Too many of the former is likely to lead to having too many of the latter. Both are bad. I don't know that I agree with either of those assertions, absent collision problems, personally, but this subthread officially makes this a religious argument; comments here off-list. The problem is that they are pretty much guaranteed to get at cross-purposes. Well, there have been alt-root zones available for, what 6 or 7 years now? And how many collisions have there actually been in practice? 2? 3? We have not yet hit the knee of the curve. Perhaps. I think those people are *much* more concerned about this than I think you think they are. I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant. Well, I meant at your customer recursive resolver servers, since the topic at hand was what do IAP's do to support their retail customers, but... I don't trust them to write code that will be used in mission-critical situations or places, regardless of where that is. Wasn't sure which them you meant here... It's not that they don't have the best intentions -- I'm sure that at least some of them do. It's that they don't have the necessary experience. The people I would trust to have enough of the right experience to make something like this work (if that's possible at all) are the same people who wrote Nominum's ANS and CNS. However, I suspect that they would probably be about the last people in the world who would be interested in trying to make something like this work. And then I figured it out. Hmmm... again, absent TLD collisions, I don't see that writing a recursive-only server that can coalesce the TLD namespace from multiple roots ought to be *that* hard... but then I'm not Cricket, neither. People will always be able to access data by pure IP address, or choosing to use the real root servers. Push come to shove, and the real root servers could be proxied through other systems via other methods. Real is *such* a metaphysical term here, isn't it? :-) Heh. Shall we use the term IRS? As in Incumbent Root Servers? I don't have a problem with that one, the amusing connotations notwithstanding. Incumbent isn't a value judgement, it's merely descriptive. The reverse problem is more difficult to deal with -- that of people wanting to access Chinese (or whatever) sites that can only be found in the Chinese-owned alternative root. Stipulated. But whose problem *is* that? The users will make it our problem, if we don't get this sorted out soon. Yup, it is. And my perception is that the cat is *out* of the bag, and fretting about how bad it would be were the cat to get out of the bag (which is my perception of most people's view of this issue) isn't especially productive; the solution is to figure out how to manage the problem. Cheers, -- jra -- Jay R. Ashworth[EMAIL PROTECTED] Designer Baylink RFC 2100 Ashworth AssociatesThe Things I Think'87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me
Re: source for GIS-correlated fiber conduit data
Hi, Yes, we have spent some time collecting and building GIS analysis tools for various infrastructures, including fiber. There are folks that sell or did sell GIS fiber data. There are pros and cons for each, and nothing is complete. That said a few places you might want to check out: Geo-tel - has metro fiber for several cities. Drawback is you cannot do routing analysis beacuse a large unumber of the conduits to do not connect to form cohesive paths. Platts - used to have a product call Telcomap that had longhaul and metro fiber. The product was incomplete and discontinued, but there is data if you can get a hold of it. Universal Access - also has GIS data but it is rather limited from what I've heard, have not actually worked with this set. Depending on what you want to do with the data, some of these might work for you. Despite the media's best attemts, our work at GMU was not classified ** shameless plug ** the dissertation will be coming out as a book this summer. We have progressed quite a bit with the work in the intervening years, and have some interesting tools for quantifying the diversity between different sets of providers to optimize resiliency of networks, fail-sims, ROI models for different multi provider configurations. Although I think the most interesting application of late is mapping IP traffic to its physical fiber routes. Still in the prototype phase, but should be a good tool for finding points where a large number of logically diverse paths are in the same ditch. best, sean - Original Message - From: Aaron Glenn [EMAIL PROTECTED] Date: Tuesday, July 5, 2005 6:41 pm Subject: Re: source for GIS-correlated fiber conduit data On 7/5/05, Gregory Hicks [EMAIL PROTECTED] wrote: Someone did but it was not limited to fiber but included utilities... And did get slapped down for putting together publicly available info into a usable form... Where are these publicly available records that Sean Gorman and TeleGeography are using to develop these maps? I've tried in ernest to find even a starting point to no avail. aaron.glenn
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
On Wed, Jul 06, 2005 at 08:52:09AM +0930, Mark Newton wrote:
Stipulated. But whose problem *is* that?
The users will make it our problem, if we don't get this sorted out
soon.
It seems to me that this is *already* sorted out, and that all of
this discussion has been about whether to invent new problems, rather
than about whether to solve existing problems.
Sorry to hear you feel that way, Mark. I'm not entitled to have
on-topicness opinions here, but Brad is, and he hasn't told me to shut
up yet. ;-)
Alternate root servers exist for one plain simple reason: To give
their operators their own little playpen of TLDs they can mess
around with without ICANN getting in their faces. People who don't
want to own and operate TLDs don't actually give a crap about that
reason.
These operators have been pushing this idea for 6 or 7 years now.
Frankly I'm of the view that if the benefits of alternate roots
were in any way desirable *to anyone other than those who operate
them* we'd probably all be using them by now.
But we aren't. And probably never will.
I dunno, The China Proposition seemed fairly believable to *me*...
If we probably never will then the alternate root operators can
either stop flogging their dead horse and shuffle off into the sunset,
or they can continue to pollute mailing lists with useless discussions
about whether they have a right to exist every time the concept is
mentioned from now until eternity, just like they do now.
Note that I am *not* an alt-root operator, nor do I have any direct
or indirect interest in any of them, except that some of my routers are
configured to resolve off of them.
Right now, on July 5th 2005, The whole alternate-root ${STATE}horse
has absolutely zero operational impact on any network operators.
So could y'all please perhaps take it to USEnet where it belongs
and let this list get back to normal?
My appraisal is that it has about as much direct percentage impact on
North American networks as IPv6 and Multicast. And, as Brad notes,
there's a believable case to be made that it *might become* an issue to
this audience.
All those who disagree or don't object to being caught with their pants
down are welcome to kill the thread, which I courteously retitled and
unthreaded at the outset.
Cheers,
-- jra
--
Jay R. Ashworth[EMAIL PROTECTED]
Designer+-Internetworking--+--+ RFC 2100
Ashworth Associates | Best Practices Wiki | |'87 e24
St Petersburg FL USAhttp://bestpractices.wikicities.com+1 727 647 1274
If you can read this... thank a system administrator. Or two. --me
Please update filters for 58/8
Dear colleagues In May 2005, IANA's delegation of the following address block to APNIC was widely broadcast to the operational and RIR mailing lists: 58.0.0.0/8 However, since that time, APNIC has received widespread reports of difficulties routing address space within this range. If you haven't already done so, please update your network configurations specifically for this range. IANA maintains a list of reserved and delegated IPv4 address ranges at: http://www.iana.org/assignments/ipv4-address-space Regards Son __ Resources Services Manager [EMAIL PROTECTED] Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: [EMAIL PROTECTED] Please send Internet Resource Requests to [EMAIL PROTECTED] __
OT: Stupid vendor tricks.
Co-workers from past lives will recognize this as a subject near and dear to my little black heart: CISCO-SLB-MIB::slbServerFarmBindId.4.10.0.0.10 = Gauge32: 0 CISCO-SLB-MIB::slbServerFarmBindId.4.10.0.0.11 = Gauge32: 0 CISCO-SLB-MIB::slbServerFarmBindId.4.10.0.0.12 = Gauge32: 0 CISCO-SLB-MIB::slbServerFarmBindId.4.10.0.0.13 = Gauge32: 0 The pure numerics are even worse, right down to the polling response behavior. - billn
Re: The whole alternate-root ${STATE}horse (was Re: Enable BIND cache server to resolve chinese domain name?)
At 7:37 PM -0400 2005-07-05, Jay R. Ashworth wrote: Hmmm... again, absent TLD collisions, I don't see that writing a recursive-only server that can coalesce the TLD namespace from multiple roots ought to be *that* hard... but then I'm not Cricket, neither. In theory, it should be trivial. In practice, I believe that it is quite non-trivial. I believe that we can look around and pretty easily find at least a few examples that demonstrate how difficult it is to get this right. The history of BIND alone is quite instructive, I believe. The fact that everyone and their brother seems to create authoritative-only servers as their 6th grade science project, but there are still relatively few caching-only servers, is another data point. And my perception is that the cat is *out* of the bag, and fretting about how bad it would be were the cat to get out of the bag (which is my perception of most people's view of this issue) isn't especially productive; the solution is to figure out how to manage the problem. I'm not sure, but I think we're at the stage where we might just be able to put the genie back in the bottle, if we act fast and we can get suitable alternative mechanisms in place through the existing official IETF/ICANN process. But if we don't get this fixed soon, I fear that we'll never be able to do that. At that point, we've got our private parts hanging out in the wind, and we're depending on the good nature of people not to come along and whack them with baseball bats, and we're depending on good fortune keeping harsh weather away that might result in lightning strikes. There's not much we can do to stop the alternate roots. They already exist, and at least two are currently in operation. However, I think we can look at what it is that they're offering in terms of i18n and see what we can do to address those issues from inside the system. IMO, i18n is the only potentially legitimate thing that alternate roots are capable of providing, and the only thing we need to worry about resolving within the system. Outside of i18n, I don't give a flying flip what the alternate roots do or what services they claim to offer. And that, I believe, is operationally relevant because the outcome will affect us all. If nothing else, code will have to be adapted to match whatever is specified as a result of the IETF/ICANN political process. And we'll all have to update our servers. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See http://www.sage.org/ for more info.
Re: OT? /dev/null 5.1.1 email
On Tue, 2005-07-05 at 16:35 -0400, Daniel Senie wrote: Generally there's little reason to run a secondary MX. Email will queue if the sole MX is offline or unreachable. Email will queue at senders' mail servers. The problem with the above is that your (or your users') email delivery is then dependent upon the configuration and timeouts of someone else's system (my system drops undeliverables after 1 hour). A backup mx system gives you the capability of getting and keeping what you can, when you can. What you do with it after that is all under your control. -Jim P.
Re: OT? /dev/null 5.1.1 email
On Tue, 2005-07-05 at 12:02 -1000, Randy Bush wrote: The principle purpose of the secondary mx, in this case, is to accept email for the primary mx during periods where the primary is down and the sending smtp server has no spool. i.e. no useful purpose. Presumably sending smtp servers do have spools, however given the range of things that send email these days... who really knows? What happens when a blackberry system sends an email to a mx that's temporarily down? Don't some routers support email notifications too, do they spool? Multiply that by mis-configured Linux systems, Exchange servers, text-paging, etc., etc. and all of a sudden the possibilities are endless. NOTE: I am a HUGE proponent of routing outbound smtp through the upstream provider. However, I can not guarantee that all the senders to my system agree with and follow that philosophy. I also desire to be RFC compliant, but I also realize I can't force the world to follow. today, the primary purpose of secondary mxs is to receive spam. I agree, but that is probably only because (most) primary mxs have been locked down. The problem of receiving spam, that is headed your way anyway, and then rejecting it is no different from primary to secondary. The means of rejecting it however could have an impact on other systems, and that is why I started this thread in the first place. ;-) So, it comes down to this: Lock down the secondary mx(s), or delete them. -Jim P.
148 counting
On Tue, Jul 05, 2005 at 08:29:55PM -0500, John Palmer (NANOG Acct) wrote: I have the BIND source, its available to the public. You want to know how hard it is? I'll show you. I will write it. Thats what I do for a living. I accept your challenge. See you in six months. I don't think that's really practical. I'm sorry, I just don't trust them to write a resolver that's going to get included in libc (or wherever), and for which the world is going to be dependant. Well, I meant at your customer recursive resolver servers, since the topic at hand was what do IAP's do to support their retail customers, but... I don't trust them to write code that will be used in mission-critical situations or places, regardless of where that is. whatever those are. there are at least 146 DNS varients out there, the number may be higher. about 50ish or so are BIND versions. Hmmm... again, absent TLD collisions, I don't see that writing a recursive-only server that can coalesce the TLD namespace from multiple roots ought to be *that* hard... but then I'm not Cricket, neither. in theory - its easy. six months... might work debugged working code - a bit longer me thinks. --bill
Re: OT? /dev/null 5.1.1 email
Brad Knowles wrote: At 4:00 PM -0400 2005-07-05, Jim Popovitch wrote: However, is seems the problem is over on the secondary MX (Postfix) which only has a list of legit relay domains for pMX. When pMX is back online sMX fwds it's queue, but at that point pMX rejects to sMX...who then rejects to Sender. Yup, and a lot of spammers take advantage of this fact by directly connecting to the secondary MXes of their targets, and never connecting to the primary MXes. What about setting your highest order MX and lowest order MX to point to the same set of mail servers, and hide your backup servers in the middle. Even better if you can implement something that auto blacklists people that connect to your secondary MX's when you know that your primaries are up and accepting e-mail. -Patrick
Re: OT? /dev/null 5.1.1 email
In message [EMAIL PROTECTED], Todd Vierling writes: The default recommendation I give anyone these days is to use no secondaries, and let the sender's mail server queue it up, as that's the fastest implementation path. As a second stage, and only if the expertise and time is available, then a backup MX with some sort of recipient validation at SMTP time can be implemented. The usual justification for a secondary MX is when the MX servers have some sort of special access to the ultimate recipients -- non-SMTP mail delivery, firewalls that they are privileged to pass, etc. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Re: OT? /dev/null 5.1.1 email
On Tue, 05 Jul 2005 21:49:54 EDT, Jim Popovitch said: The problem with the above is that your (or your users') email delivery is then dependent upon the configuration and timeouts of someone else's system (my system drops undeliverables after 1 hour). Wow. A whole whopping 1% of the RFC2821-recommended 4-5 days. How's that working out for you? pgpjPvXALF0dZ.pgp Description: PGP signature
Re: OT? /dev/null 5.1.1 email
On Tue, 5 Jul 2005, Patrick Muldoon wrote: Even better if you can implement something that auto blacklists people that connect to your secondary MX's when you know that your primaries are up and accepting e-mail. You might be able to connect to them but who knows what transient network even might stop a remote site from connecting to your primaries long enough that they try the secondary MX. A related thing is that these days your mail system has to check the validity of the address on SMTP connect time. I've used/seen a few email setups where the front layer just checked the domain validity and the layers further back checked the full address. Doing that these days leaves you with a lot of email/spam to invalid addresses you have to drop or bounce. -- Simon J. Lyall. | Very Busy | Mail: [EMAIL PROTECTED] To stay awake all night adds a day to your life - Stilgar | eMT.
Re: OT? /dev/null 5.1.1 email
On Jul 5, 2005, at 11:28 PM, Steven M. Bellovin wrote:
In message [EMAIL PROTECTED], Todd Vierling
writes:
The default recommendation I give anyone these days is to use no
secondaries, and let the sender's mail server queue it up, as that's
the
fastest implementation path. As a second stage, and only if the
expertise
and time is available, then a backup MX with some sort of recipient
validation at SMTP time can be implemented.
The usual justification for a secondary MX is when the MX servers have
some sort of special access to the ultimate recipients -- non-SMTP mail
delivery, firewalls that they are privileged to pass, etc.
They're also mighty handy when dealing with planned, extended outages,
such as moving to a new {building, ISP, etc.} or, say, losing power to
the {only IX for Moscow, northeastern U.S.}, etc. It's much easier to
configure your backup MXen to not toss messages or send warning emails
after 4h than it is to politely ask all sending SMTP servers to do the
same.
-Dave
Re: OT? /dev/null 5.1.1 email
David Andersen wrote: On Jul 5, 2005, at 11:28 PM, Steven M. Bellovin wrote: snip It's much easier to configure your backup MXen to not toss messages or send warning emails after 4h than it is to politely ask all sending SMTP servers to do the same. -Dave Apparently this has boiled down to - Some people feel perfectly comfortable trusting the sender's queuing (witness graylisting's popularity) - Some people feel more secure managing the queued mail. This is also nicer to the sender's queues. - Secondary MX's should make every possible effort not to add to spam blowblack -- popular mechanisms include smtp call aheads, LDAP, virtusertable maps and so on. If this is impossible serious thought should be given to the need for the MX in the first place. - Secondary MX's should take care not to be an end run against any anti abuse systems deployed by the primary MX path. - Typically similar effort that goes into enabling a secondary MX to perform recipient verification needs to be done anyway when having more than one primary MX for simple load balancing reasons. So not having secondaries at that point does not make much sense. - Building a setup depending on a failure mode for productive purposes is not wise. IOW, depending on collecting mal-clients for blacklisting who connect to your secondary when you believe that they shouldnt is potentialy problematic. So is designing a setup where you rely on failure of the primary MX reachability so that the secondary MX with better conectivity than the sender can simply relay it based on MX records.
Re: Please update filters for 58/8
Randy Bush wrote: repeat: it expitites things if you give folk an address they can ping to test. randy 58.6.7.1 is setup and should be pingable for testing purposes. Jason
Re: OT? /dev/null 5.1.1 email
On 7/5/2005 10:47 PM, Patrick Muldoon wrote: Even better if you can implement something that auto blacklists people that connect to your secondary MX's when you know that your primaries are up and accepting e-mail. http://wiki.apache.org/spamassassin/WrongMXPlugin is a SpamAssassin plugin that determines if an email was sent to a lower preference MX when a higher preference MX was likely available. Haven't used it but it's an interesting idea on my to-examine list -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Re: OT? /dev/null 5.1.1 email
On Tue, 05 Jul 2005 22:47:48 EDT, Patrick Muldoon said: What about setting your highest order MX and lowest order MX to point to the same set of mail servers, and hide your backup servers in the middle. Devious. ;) Even better if you can implement something that auto blacklists people that connect to your secondary MX's when you know that your primaries are up and accepting e-mail. The problem there (especially if the primary and secondary aren't on the same subnet/network) is that just because *you* know that your primary is up and receiving, that doesn't mean that a network glitch didn't render it inaccessible from the sending site. I'd hate to get blacklisted just because our main link to the outside world hiccupped, and it happened to come up in time for us to fall back to the secondary MX that you *TOLD* us to use. ;) pgptIueqWR6zT.pgp Description: PGP signature
Re: OT? /dev/null 5.1.1 email
On Tue, 05 Jul 2005 21:27:23 PDT, Justin Mason said: BTW, someone (possibly Randal L. Schwartz) came up with a neat related trick to the above -- set up an interface alias on *the same machine* as the primary MX, list that as the last MX in the list, and (assuming that the software side of the primary MX is reliable) you're then assured that any SMTP traffic that arrives on that IP's port 25 is spam, since when the primary MX's hardware goes down, this MX will, too. That's got the same failure mode - if I take a 30-second hit and can't reach the first MX, then the link comes up before I try the last MX, I hit the bad one. And since the link burp is at *my* end, you don't even know about it, unless you hook it into a full BGP feed with Zebra or something and see AS1312's routes flap (and even then, it's dicy - a very short burp may not cause the routes to be withdrawn) pgpVsuyQhLtfp.pgp Description: PGP signature
Re: OT? /dev/null 5.1.1 email
On Tue, 05 Jul 2005 21:27:23 PDT, Justin Mason said: BTW, someone (possibly Randal L. Schwartz) came up with a neat related trick to the above -- set up an interface alias on *the same machine* as the primary MX, list that as the last MX in the list, and (assuming that the software side of the primary MX is reliable) you're then assured that any SMTP traffic that arrives on that IP's port 25 is spam, since when the primary MX's hardware goes down, this MX will, too. (Damn, left out a paragraph somehow) And in fact, given that most link hiccups *are* transitory, the chances are *good* that if our attempts at the first MX fail, the link will be back before we finish running through the MX's - at which point we find ourselves talking to a spamtrap. pgpMFPvyyQviD.pgp Description: PGP signature
