- Test - lists.nanog.org

RE: ARIN Policy on IP-based Web Hosting
by Roeland M.J. Meyer 31 Aug '00

31 Aug '00

everything to the right side of the final dot. Such as in "/etc/named.conf" the extension is "conf". A better example is "/usr/local/src/whois.1.9.0/readme.txt" where the extension is "txt". > -----Original Message----- > From: Alex Kamantauskas [mailto:alexk@tugger.net] > Sent: Thursday, August 31, 2000 7:19 AM > To: Andrew Brown > Cc: Jeff Mcadams; nanog(a)merit.edu > Subject: Re: ARIN Policy on IP-based Web Hosting > > > > On Thu, 31 Aug 2000, Andrew Brown wrote: > > > > > the mime type is made up, usually based on the file's > extension, which > > is, of course, passed along with the contents of the file when you > > transfer it. it's no extra information in this context. > > > > What's a file extension? > > -- > Alex Kamantauskas > alexk(a)tugger.net > >

2 1

Re: ARIN Policy on IP-based Web Hosting (fwd)
by smd＠clock.org 31 Aug '00

31 Aug '00

["Uh oh, Sean must be bored" sotto voce from the crowd... "But really, it's network-related!"] Richard Shetron writes: | On MS-DOS/Windows, its the last part of the dotted filename, ie junk.txt | would be a text file of junk.c would be a C cource file. | | Most Unix's are the same. The extension is the last component in a | period separated name. Hmmm... Funny that someone with a login of "multics" would say that! : sean (es) ; ln -s /bin/echo foo.c : sean (es) ; ./foo.c hello there hello there : sean (es) ; file * | egrep '(English|International language) text' | wc -l 24 : sean (es) ; ls *.txt | wc -l 9 : sean (es) ; uname -sr NetBSD 1.5E : sean (es) ; echo 'main() { exit(0); }' > x : sean (es) ; cc -o y.c -x cpp-output x : sean (es) ; file x y.c x: ASCII text y.c: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped : sean (es) ; cc -v Using builtin specs. gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) So, making this network-relevant, you have to understand what abstraction you are looking at, and when you are overloading an abstraction - in classical IP and its useless and too-costly-to-deploy Official Successor, the IP address serves both as a topological identifier ("where") and an endpoint identifier ("what"). This is broken. In "most UNIXes", a pathname ("/bin/sh") serves as a topological identifier, since it _locates_ the file. This locator function is overloaded with a hint about what is at the location, but they are separate things, because of links (one what has many locations) and because there is no rule about (for example) something that has a locator like ".../foo.c" HAVING to contain a C program file. Several operating systems try to avoid the overloading of where and what. Apple's MacOS is a familiar example - the "what" part is not part of the folder locator ("where"). This is valuable since one does not have to _infer_ the content based on location, nor try to abuse the topology of the filesystem to align the two. IPv6's architecture is fundamentally broken because it DOES NOT separate "what" from "where", inviting the same overloading that leads us into these discussions about allocation policies and concerns about the number of progressively-longer prefixes being carried in the global routing system. This is, I believe, the point that David Conrad was trying to make. Sean.

1 0

Re: ARIN Policy on IP-based Web Hosting
by Alec H. Peterson 31 Aug '00

31 Aug '00

"John A. Tamplin" wrote: > > What I am getting at is that this is a massive undertaking for a large > hosting provider to comply with this new policy, and it will definitely > affect how customers interact with the service. You may not care if > customers are unhappy, but everyone else does. I hate it when people try to put words into my mouth. ARIN is a membership organization. ARIN does not make decisions just because they piss people off and fill our mailboxes with hate mail about how we should crawl into a hole and die. This policy was by and large forged BY ARIN MEMBERS. Many of the people who participated in the discussion work for large web hosting providers. The migration issue was raised, and several of these people outlined ways to migrate customers without any downtime whatsoever. Alec -- Alec H. Peterson - ahp(a)hilander.com Staff Scientist CenterGate Research Group - http://www.centergate.com "Technology so advanced, even _we_ don't understand it!"

1 0

RE: ARIN Policy on IP-based Web Hosting
by Roeland M.J. Meyer 31 Aug '00

31 Aug '00

> From: jlewis(a)lewis.org [mailto:jlewis@lewis.org] > Sent: Tuesday, August 29, 2000 3:44 PM > > On Tue, 29 Aug 2000 sigma(a)pair.com wrote: > ARIN's site says: > > Where security is a concern, name-based hosting is capable of > supporting the transmission of sensitive materials > with some servers. > Unless something's changed recently, SSL still requires IP > based virtual > hosting. Here's a clipping from the c2.net Stronghold FAQ: > > Should I use name-based or IP-based virtual hosts? > > Name-based virtual hosts do not work with SSL because > certificates are > sent before server names are established. Secure virtual > hosts must be > either IP-based or port-based. IP-based virtual hosts are more > convenient, as users would have to remember the port numbers for > port-based virtual hosts. In addition, neither OpenSSL nor mod_ssl work with named-based virtual hosts. All vHosts have to share the same cert whereas IP-based hosts don't. Someone at ARIN is hallucinating, if they think that their statement is true. As a side note, MS-IIS doesn't do it any more successfully than Apache/OpenSSL even v5.5 under Win2K, I run both. It sounds more like ARIN wants to shut down web-hosting companies or prevent them from doing SSL. The only other way to read this is that someone at ARIN is incompetent. Frankly, I'd like to know which.

4 3

Re: ARIN Policy on IP-based Web Hosting (fwd)
by multics＠ruserved.com 31 Aug '00

31 Aug '00

Forwarded message: > On Thu, 31 Aug 2000, Andrew Brown wrote: > > > the mime type is made up, usually based on the file's extension, which > > is, of course, passed along with the contents of the file when you > > transfer it. it's no extra information in this context. > > What's a file extension? > > -- > Alex Kamantauskas > alexk(a)tugger.net Depends on what machine you're on. On MS-DOS/Windows, its the last part of the dotted filename, ie junk.txt would be a text file of junk.c would be a C cource file. Most Unix's are the same. The extension is the last component in a period separated name. I believe that on MacOS, BEOS and others, the extension information is stored separately and not part of the name or may optionally be part of the name. That's also how web servers and web browsers know what to do with files that have an html extension. Unfortunatly, if the file being transported by the server or the browser has a 'known' extension, the file will be processed by one or the other or both. Once the file is processed, you can't save a copy that's identical to what was sent. This is particulalry true as extensions do not have to be unique. I've seen two or more applications use the same extension and conflict with one known by a web browser. Click on the link and you can't download the file, you just get junk on the screen. -- Richard Shetron multics(a)ruserved.com multics(a)acm.rpi.edu NO UCE What is the Meaning of Life? There is no meaning, It's just a consequence of complex carbon based chemistry; don't worry about it The Super 76, "Free Aspirin and Tender Sympathy", Las Vegas Strip.

1 0

You are the backup
by Sean Donelan 31 Aug '00

31 Aug '00

Poking around the AP newswire for details on their satellite problems yesterday I found AP retired their previous backup system. For most AP customers the Internet is the primary backup. A few AP customers also had ISDN or FAX backup. Whether folks tell us or not, the net seems to be included in more and more backup plans.

4 4

RE: ARIN Policy on IP-based Web Hosting
by Richard A. Steenbergen 31 Aug '00

31 Aug '00

On Thu, 31 Aug 2000, Jason Slagle wrote: > The problem is that SCP is several orders of magnitude slower then FTP. I > use scp, rsync (on top of ssh), nfs, and several other methods of moving > files around, and ftp blows them all away. > > You also need to build a ftp like structure on top of it. ie: I pick the > files I want instead of having to know the filenames. > > Until this happens, I can see no viable alternative to FTP. > > I wouldn't be unhappy to see one, but we can't retire it without a good > replacement that performs nearly as well. IMHO the original ftp protocol is quite dated, and could be improved upon in any number of ways, but it probably won't go away any time soon. There are also a number of secure ftp-like interfaces, including one distributed w/ssh. And for the record, there is no inherent reason scp should be more then a slight bit slower then ftp (overhead - the ssh protocol packetizes data), other then being purely CPU bound when doing encryption. If you're seeing even one order of magnitude in performance loss, its probably because you're using a painfully slow default 3DES. Try changing it to something a little better like Blowfish, or none if you really want. (A)RC4 is the least CPU intensive, being a stream cipher, but its not terribly functional in the ssh protocol. If you really want to do high performance crypto, check out some hardware based addons like PowerCrypt (http://www.powercrypt.com) or ASICs from Hi/fn. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

RE: Root zone change -- Informational message
by Verd, Brad 30 Aug '00

30 Aug '00

Yes, the new m.gtld-servers.net and the old will run in parallel for a minimum of a week. I believe the TTL on the com, net, and org TLD's is a little less then a week. Thanks, Brad -----Original Message----- From: John Hawkinson [mailto:jhawk@bbnplanet.com] Sent: Wednesday, August 30, 2000 5:16 PM To: Verd, Brad Subject: Re: Root zone change -- Informational message > The IP for m.gtld-servers.net will be changed in the authoritative list for > .com, .net, and .org. Changes will be reflected in the zone with serial > number 2000083001 I presume that the old IP will continue to function for a few days, at least? --jhawk

1 0

Re: Full disclosure
by John Fraizer 30 Aug '00

30 Aug '00

Connected to 62.153.217.141. Escape character is '^]'. 220 MERCUR SMTP-Server (v3.10.18 AS-0098304) for Windows NT ready at Wed, 30 Aug 2000 22:43:55 +0200 helo blah.com 250 kamen-ewr1 Hello 209.41.244.2 mail from: test(a)test.com 250 <test(a)test.com>, sender ok rcpt to: blah(a)blah.com 250 User not local; will forward to <blah(a)blah.com> A large percentage of the addresses listed are running this same mailserver software. You can't get much more SPAM friendly than that. --- John Fraizer EnterZone, Inc

1 0

Full disclosure
by John Fraizer 30 Aug '00

30 Aug '00

Over the past couple of days, some person or group has been sending out thousands of SPAMs through open relays using random @enterzone.net addresses as the FROM address. This is NOT happening through our mailservers, nor is it happening from any VALID enterzone.net account. Thus far, the following servers have been identified as having been used to relay the SPAM: dialupFF60.mpls.uswest.net (answers as mail.pmhadv.com on 25) 195.162.167.134 62.153.217.141 212.77.168.66 195.127.176.98 195.4.100.19 193.85.146.161 195.86.241.191 The list just keeps on growing. Logs from those who run these mailservers would be appreciated. We plan on pursuing this legally. We're not sure if this SPAM run is still underway but, I want to stress the fact that this is NOT originating from our mailservers, nor from any of our customers. Feel free to run our mailservers through whichever relay-tests you like to verify. We do so weekly. --- John Fraizer EnterZone, Inc

1 0