- NANOG - lists.nanog.org

Re: Enable BIND cache server to resolve chinese domain name?
by Peter Dambier 05 Jul '05

05 Jul '05

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: peter(a)peter-dambier.de http://iason.site.voila.fr http://www.kokoom.com/iason

2 1

Fundamental changes to Internet architecture
by Michael.Dillon＠btradianz.com 05 Jul '05

05 Jul '05

I guess I'm not the only one who thinks that we could benefit from some fundamental changes to Internet architecture. http://www.wired.com/news/infostructure/0,1377,68004,00.html?tw=wn_6techhead Dave Clark is proposing that the NSF should fund a new demonstration network that implements a fundamentally new architecture at many levels. ------------------------------------------------------- Michael Dillon Capacity Management, 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon(a)btradianz.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com One Community One Connection One Focus

9 12

Re: Enable BIND cache server to resolve chinese domain name?
by Brad Knowles 05 Jul '05

05 Jul '05

At 2:33 PM +0100 2005-07-04, Michael.Dillon(a)btradianz.com wrote: >> That works, up until the point where India decides to use a >> different alternative root solution than China does. > > The only people affected by this are the people who run > the alternative root used by China because, presumably, > it means that they lose some business to a competitor > who has won the Indian market. Not at all. Any third party who might want to see both the Indian sites and the Chinese sites would also lose, because they couldn't use both sets of alternative root servers at the same time. Any ISP that might serve some customers who want to see one set of sites, and another set of customers who want to see the other set, would also lose. In other words, just about everyone else in the world would also lose. >> That works, up >> until the point where the inexperienced alternative root operators >> screw something up and their entire "expanded" Internet goes down, >> while the real root servers continue normal operations. > > Yes, and Google works until they screw something up and > their wonderful search engine goes down while Excite and > Yahoo et al. continue normal operations. Yes, but people aren't forced by their ISP to use a given search site. They can use any search site they want. That same level of choice does not exist with one or more alternative roots. >> The balkanization of the 'net is something to be avoided at all >> possible costs. > > My company makes good money off balkanization of the 'net > and we are definitely *NOT* the only one. AOL has always > operated a network apart from the rest. AOL is a bad choice here. They've finally decided that the walled garden model doesn't work, and they're opening up all their content to the whole world, all you have to do is use their portal. If you're going to make arguments, you should at least choose examples that support your thesis. > Remember, the public root systems are not attacking > the ICANN root infrastructure at the network layer > in any way. They are not impeding the ability of the > ICANN roots to function and they are not stopping > people from following your "only one root" model. Actually, they are. They are causing confusion. People don't understand why they can't get to a given set of sites. Intentionally creating such a situation is just about the worst possible thing you could do. > Their entrepreneurial spirit is consistent with the > free and open way in which the Internet has developed. No, it's not. If it had been, they would have worked their business model through the IETF. > 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. -- Brad Knowles, <brad(a)stop.mail-abuse.org> "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.

3 2

OT: Thanks Everyone 4 the EMail Observations and Tips/eom
by Frank Coluccio 04 Jul '05

04 Jul '05

1 0

Re: Enable BIND cache server to resolve chinese domain name?
by Brad Knowles 04 Jul '05

04 Jul '05

At 11:26 AM +0100 2005-07-04, Michael.Dillon(a)btradianz.com wrote: > I think that the marketing people are going to win > this one. There is no marketable benefit to the ICANN > root zone but there are clear advantages for countries > using non-Latin alphabets to switch to a root zone that > allows for their own language to be used in domain names. That works, up until the point where India decides to use a different alternative root solution than China does. That works, up until the point where the inexperienced alternative root operators screw something up and their entire "expanded" Internet goes down, while the real root servers continue normal operations. The balkanization of the 'net is something to be avoided at all possible costs. > Turkey was recently mentioned and that is also a country > that uses a non-Latin alphabet. It doesn't matter how many non-Latin alphabets you introduce. What matters is that there can be only one root. -- Brad Knowles, <brad(a)stop.mail-abuse.org> "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.

3 2

Re: Enable BIND cache server to resolve chinese domain name?
by Suresh Ramasubramanian 04 Jul '05

04 Jul '05

On 04/07/05, Brad Knowles <brad(a)stop.mail-abuse.org> wrote: > That works, up until the point where India decides to use a > different alternative root solution than China does. That works, up Oh - most indians couldnt care a sh*t about it I expect, except those who have business or other contacts with china. On the other hand, .tw and .cn are quite likely to find sharing the same namespace very tough .. and there are all the oh so wonderful encoding and other differences that you can get that make IDN using nonstandard and non interoperable schemes so very interesting. --srs -- Suresh Ramasubramanian (ops.lists(a)gmail.com)

3 2

Re: Enable BIND cache server to resolve chinese domain name?
by Brad Knowles 04 Jul '05

04 Jul '05

At 1:25 PM +0100 2005-07-04, Michael.Dillon(a)btradianz.com wrote: > They are battling it out in the marketplace and one > of the IDN solutions will evolve to the point where > the market considers it clearly superior. I think that would be the worst possible outcome. > Personally, I think that the Internet is too young > and we have too little experience with multilingual > naming to engineer an Internationalised Domain Naming > solution that solves the problem once and for all. > This means that we should be ready for more than one > iteration to get to the solution. I have no problem with multiple iterations to get this right. I have real problems with those multiple iterations being done via the marketplace. These sorts of things need to be engineered using the correct methods (at least, as known at the time), and they need to go through the correct process. That means the IETF. We don't let Joe Moron invent his own better-cheaper-faster replacement for SS7 and then casually bet-the-businesses/livelihoods of thousands or millions of innocent people that they got their engineering right. We shouldn't be allowing anyone to do the same for DNS. -- Brad Knowles, <brad(a)stop.mail-abuse.org> "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.

1 0

drone armies C&C report - June/2005
by Gadi Evron 04 Jul '05

04 Jul '05

Below is a periodic public report from the drone armies / botnets research and mitigation mailing list. For this report it should be noted that we base our analysis on the data we have accumulated from various sources. According to our incomplete analysis of information we have thus far, we now publish our regular reports, with some additional statistics. We changed our report this month to reflect past data, and try to ascertain from our own experience response rates to botnet reports. This month we would once again like to commend Staminus and Internap, who continually surprise us with their immediate response to our reports. The numbers speak for themselves. A couple of other notable ISP's we rarely mention (because they were never a problem) are AOL and Comcast. Comcast has been with us since the start and has shown nothing but seriousness. AOL are continuously ahead of the curve, which is something I personally am close to adoring. The most impressive turn-about change in behavior though came from ThePlanet, who investigate and eliminate any botnet C&C they encounter in record time up to the point where they no longer appear in our monthly reports - where they used to have a revered seat at the top. The report summary includes a Percent Resolved Column in order to recognize the mitigation efforts of the AS Responsible Parties. The Opens Unresolved column represents the number of unique C&C which reported as open to the survey's connection attempts and which have neither been investigated nor cleared by the Responsible Party (to the extent of our knowledge). The Mapping count may include multiple names mapping to a single IP within an AS. We count each mapping count as a unique C&C. AS responsible Parties ranked by top Opens Unresolved Responsible Party Mapping Opens Percent Count Unresolved Resolved SERVER4YOU - Server4You Inc. 49 37 24 UNITEDCOLO-AS Autonomous Syste 44 36 18 SAGONET-TPA - Sago Networks 80 32 60 MFNX MFN - Metromedia Fiber Ne 61 28 54 NOC - Network Operations Cente 39 27 31 AS13680 Hostway Corporation Ta 22 22 0 FDCSERVERS - FDCservers.net LL 42 19 55 NEBRIX-CA - Nebrix Communicati 33 16 52 ASN-NA-MSG-01 - Managed Soluti 31 14 55 LAMBDANET-AS European Backbone 15 14 7 INFOLINK-MIA-US - Infolink Inf 28 13 54 LYCOS-EUROPE Lycos Europe GmbH 17 13 24 Historical Report ranked by past suspect C&Cs mapping into the AS: Responsible Party Mapping Opens Percent Count Unresolved Resolved SAGONET-TPA - Sago Networks 80 32 60 MFNX MFN - Metromedia Fiber Ne 61 28 54 STAMINUS-COMM - Staminus Commu 56 0 100 INTERNAP-BLOCK-4 - Internap Ne 54 0 100 INTERNAP-BLK - Internap Networ 52 0 100 SERVER4YOU - Server4You Inc. 49 37 24 UNITEDCOLO-AS Autonomous Syste 44 36 18 FDCSERVERS - FDCservers.net LL 42 19 55 NOC - Network Operations Cente 39 27 31 KIXS-AS-KR Korea Telecom 33 8 76 NEBRIX-CA - Nebrix Communicati 33 16 52 ASN-NA-MSG-01 - Managed Soluti 31 14 55 * We would gladly like to establish a trusted relationship with these and any organizations to help them in the future. * By previous requests here is an explanation of what "ASN" is, by Joe St Sauver: http://darkwing.uoregon.edu/~joe/one-pager-asn.pdf The Trojan horses most used in botnets: 1. Korgobot. 2. SpyBot. 3. Optix Pro. 4. rBot. 5. Other SpyBot variants and strains (AgoBot, PhatBot, actual SDbots, etc.). This report is unchanged. Credit for gathering the data and compiling the statistics from our group efforts should go to the Statistics Project lead: Prof. Randal Vaughn <Randy_Vaughn(a)baylor.edu> -- Gadi Evron, Israeli Government CERT Manager, Tehila, Ministry of Finance. gadi(a)CERT.gov.il Office: +972-2-5317890 Fax: +972-2-5317801 The opinions, views, facts or anything else expressed in this email message are not necessarily those of the Israeli Government.

1 0

mobile user strawman argument
by Mike Leber 04 Jul '05

04 Jul '05

Directed at no specific person because I've seen several people use it in their examples recently... I'm seeing alot of arguments in the form of "I have mobile users and they aren't going to be able to send email if you use injection IP mail filtering approach X" (where X is SPF, MX+, or what have you); which take the same form as the arguments people made against closing open relays. For those that don't remember, prior to around 1995 or so most all mail servers would relay may for anybody by default. People that got tired of being abused made it so only their customers could use their mail servers to relay mail by methods such as: POP AUTH, only relaying mail for their customer IPs, only accepting mail to be relayed from domains that were hosted on that server, etc. At that time some people swore up and down it was unworkable because all of their mobile users wouldn't be able to send mail using their mail servers because the remote users use random dynamic IPs from all over the Internet. After a large amount of gnashing of teeth and whining, and the spread of knowhow of the several different methods to close an open server yet still allow your users to send mail, these objections were overcome and the open relays were closed. Ok... fast forward to the present in which we can now assert that service providers don't use open relays to provide service to their customers. So now I'm supposed to believe that its impossible for service providers to coordinate which mail server a user is supposed to use to send their mail through (with the information about authorized sending IPs for a domain communicated to receipient SMTP servers according to the method of your choice) when they already force their users to use only SMTP servers that they have authorized access to relay through. Ya, ya, ya... you are going to say 1) its impossible to get people to use designated servers for outgoing email. Or you will say 2) even if you do this there will still be *spam*! (egads shock horrror!) Ugh please. 1) Getting customers to use designated servers is already done and standard operating procedure. 2) Most people would agree that closing the open relays as they were was worthwhile and a sound security decision. The fact that spam still exists doesn't make the decision wrong, it just means that you should not be so naive or disingenuous as to expect various limited practical precautions to solve all the world's spam problems. So much deja vu I feel like I'm on a merry-go-round. Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber(a)he.net http://www.he.net | +-----------------------------------------------------------------------+

7 13

Re: Enable BIND cache server to resolve chinese domain name?
by Frank Coluccio 04 Jul '05

04 Jul '05

Steve, I think that what it boils down to is how many times do you want to split Metcalfe before it becomes self-defeating. Similar arguments have surfaced recently due to the emergence of proprietary vertical voip applications such s Skype. If one is appeased simplmy by communing with a fixed set of users of a given community mind set, then it works and everyone is happy. Beyond that? One could be left sucking wind. Frank ps - I've been advised on several occasions by Randy Bush alone that whenever I post to NANOG I leave microsoft artifacts such as ( ^ } in my wake. I don't see it myself. If this happens to be the case in this writing, then would someone please email me indicating so? Appreash ..

1 0