Re: data request on Sitefinder
At 9:46 PM -0500 10/20/03, Jack Bates wrote: todd glassey wrote: Richard - Do they (Verisign) have any legal reason to??? - is there anything between them and ANY of their clients that requires them to inform them before any changes to protocol facilities are made - I think not. To inform? Not yet, although I have the feeling that this will be changed due to historic record. However, changes that have an effect are always analyzed and a course of action chosen. I believe this is the job of ICANN. At some point, ICANN's power will need to be tested and set in stone. Only the community can create or strip that power. Yet if an organization is going to exist to serve the community and maintain order, then it needs the power to do it. Throughout this affair, I've been puzzled by what seems to be an assumption that once a contract exists, it cannot be changed or cancelled. Yet such changes and cancellations happen daily in business. They may require litigation, lobbying of the Congress or executive when government is involved, market/consumer pressures, etc., but change is not impossible. Jack makes excellent points here, which I might restate that this is a defining moment for ICANN to establish its viability and relevance as an organization. If ICANN is to be meaningful in the future, it _must_ make a strong stand here. Related issues include whether the IETF process, even if flawed, is the consensus means of proposing and discussing changes in the infrastructure. Whether or not the operational forums like NANOG have a role in this process, or even in presenting consensus opinions, also is a basic question for Internet governance. Purely from my experience in journalism, media relations and lobbying, I have to respect the effectiveness of the Verisign corporate folk who largely have been setting the terms of debate, and managing the perception -- or misperception -- of this matter in the business and general press. Apropos of that, lots of people equate privatization of the Internet to its commercialization. Privatization isn't nearly that binary. If privatization, in general, is getting the US government out of Internet governance, we still have the options of: -- transferring such control as exists (and there may be no control mechanism) to a quasi-governmental body such as ICANN. -- transferring control, especially with regard to stewardship, to a not-for-profit corporation (e.g., ARIN) -- accepting that an organization such as IETF will manage a consensus process -- subcontracting, but closely monitoring, to a general for-profit enterprise. -- transferring control to a regulated technical monopoly, probably with a financial model of return-on-investment rather than maximizing shareholder value. -- transferring control, at least for a defined period, to a for-profit enterprise with a fiduciary responsibility to maximize shareholder value -- transferring control to competing for-profit organizations Howard, who is puzzled by what seems to be lots of tunnel vision (and I don't mean GRE). I think Vixie has alluded to this a few times, and I know there is much that goes on in the hallways concerning the overall problem of who controls what. Verisign is just helping to push the process along. I doubt it will end as they want it to. -Jack
Re: Dos attack?
Eric, You should start with your upstream's security dept. They may have seen either this incident, a related one, or both. And they more than likely have resources at other transit providers' security depts. You pay for their service, you may as well use it, right? Guy Hi, We are getting a LOT of web requests containing what mostly looks like giberish. [Mon Oct 20 21:13:42 2003] [error] [client 172.133.3.204] request failed: erroneous characters after protocol string: \xb8\xcf\xc235\x9f\xc4\x1c\xebj\xd7\xc5\x8e\xe9d\xfdMe\xed\x16\xca\xd51\xcfReF\x82\xa3qi\x89\x832\vJ5k\x15\xa2\x0c\ x90\xed\x8bCT\xa3\xa2\x96\xd7\xe8\xa2`S#+W\xfc\xc2\xc2w*\xce\x1a\xb9\xc3\x91\x14\xb0\x9e\xfe\x14\7\xaa\xeaR\xd1\x9c \x13\x1a\xf0\x1aN\x8eklP\xdc\xc1\xe3\xb9w\xb0\x1aGt\x04|I4\xae\x06WC\x15NA\x80\xb1\xc5E~\xd59\x85+\xcc\x9e\xb8\xaf(\r \x1f\x97 But this is not the standard Microsoft worm stuff that I can tell. It is coming from numerous IP addresses and nearly took down a few of our servers until we started blocking them with the firewall. So I am trying to find out as much as I can about what is happening, but I don't really know where to start. I don't believe it is considered approperiate to send a list of IPs to this list. So where should I start? The list so far contains about 60 addresses. Thanks, Eric
Re: Hijacked IP blocks
either do it for all or for none) So I hope that any of you that may have questinable blocks in current use would on your stop and return them to the state they were before in whois or return them to arin or continue using the blocks and apply to officially transfer them (remember ARIN currently does transfers at no extra charge, this will not last forever!!!). While I agree that this is the right thing to do, the statement that ARIN does transfers at no extra charge, while technically true, does not paint a complete picture of the truth. While there is no charge for the transfer, there are potential financial consequences. They are minor, but, they exist. If you have legacy space which was allocated pre-ARIN and you transfer it to your own ORG-ID, you will go from Legacy free status to current $100/year status. Owen
Re: Dos attack?
Thanks Guy I have sent them more detailed info. Eric guy wrote: Eric, You should start with your upstream's security dept. They may have seen either this incident, a related one, or both. And they more than likely have resources at other transit providers' security depts. You pay for their service, you may as well use it, right? Guy Hi, We are getting a LOT of web requests containing what mostly looks like giberish. [Mon Oct 20 21:13:42 2003] [error] [client 172.133.3.204] request failed: erroneous characters after protocol string: \xb8\xcf\xc235\x9f\xc4\x1c\xebj\xd7\xc5\x8e\xe9d\xfdMe\xed\x16\xca\xd51\xcfReF\x82\xa3qi\x89\x832\vJ5k\x15\xa2\x0c\ x90\xed\x8bCT\xa3\xa2\x96\xd7\xe8\xa2`S#+W\xfc\xc2\xc2w*\xce\x1a\xb9\xc3\x91\x14\xb0\x9e\xfe\x14\7\xaa\xeaR\xd1\x9c \x13\x1a\xf0\x1aN\x8eklP\xdc\xc1\xe3\xb9w\xb0\x1aGt\x04|I4\xae\x06WC\x15NA\x80\xb1\xc5E~\xd59\x85+\xcc\x9e\xb8\xaf(\r \x1f\x97 But this is not the standard Microsoft worm stuff that I can tell. It is coming from numerous IP addresses and nearly took down a few of our servers until we started blocking them with the firewall. So I am trying to find out as much as I can about what is happening, but I don't really know where to start. I don't believe it is considered approperiate to send a list of IPs to this list. So where should I start? The list so far contains about 60 addresses. Thanks, Eric
Re: Whois software run by Lacnic and BR?
Hank Nussbacher wrote: The whois server at the .BR registry (also the NIR for Brazil) doesn't provide country information because it's implicit as it only provide information for Brazil. Implicit is fine for humans but for automated scripts, couldn't it be made to have country=BR for all your inetnum entries? When I was running a whois server we discovered that not all local people appeared to want to use a local address. Some of them had head offices used for billing, and the like, that was in a different country so having the country code was useful even for humans. Mark.
Re: data request on Sitefinder
To inform? Not yet, although I have the feeling that this will be changed due to historic record. However, changes that have an effect are always analyzed and a course of action chosen. I believe this is the job of ICANN. At some point, ICANN's power will need to be tested and set in stone. Only the community can create or strip that power. Yet if an organization is going to exist to serve the community and maintain order, then it needs the power to do it. I will point out that it will be much easier for the community to strip that power than to vest it in another entity. To strip that power only requires one of two things: 1. Enough of the community heading in a different direction and disregarding said entity (ICANN). 2. An organization such as Verisign openly defying ICANN and ICANN failing to make a sufficiently strong response to enforce and protect the consensus will of the community. I think item 1 is unlikely unless fueled by item 2. Verisign would do well to notice that if they do implement the sitefinder wildcards again, and, ICANN does not successfully put a stop to it, the single most likely outcome is for the community to view ICANN as irrelevant and impotent. Once this happens, the inevitable result is a fragmentation of the DNS, disparate roots, and, loss of the convention of a single recognized authority at the root of the tree. This convention is fundamental to the stability of the current internet. Losing it would definitely have negative impact on the end user experience. In every forum to which I have convenient access, Verisign has repeatedly attempted to restrict the discussion to the technical issues around the wildcards. The reality is that the technical issues are the tip of the iceburg and, while costly and significant, they are not the real danger. The issues that must be addressed are the issues of internet governance, control of the root (does Verisign serve ICANN or vice-versa), and finally, whether the .com/.net zones belong to the public trust or to Verisign. Focusing on the technical is to fiddle while Rome burns. Related issues include whether the IETF process, even if flawed, is the consensus means of proposing and discussing changes in the infrastructure. Whether or not the operational forums like NANOG have a role in this process, or even in presenting consensus opinions, also is a basic question for Internet governance. The IETF process is the consensus means of proposing and discussing changes in the DESIGN of the infrastructure, not the construction or maintenance. That _IS_ the role of the network operators and the operators forums. For this to work, however, the operators have to be generally of good will and cooperative for the greater good. This model is somewhat antithetical to capitalism because for it to operate efficiently, it requires the long term good of the community to take precedence over the short-term gains of the individual or single organization. Capitalism is well optimized for the short-term gains of the individual or single organization. This is one of the growing pains that comes from the internet being originated as a government-sponsored community research project. The design was done assuming a collection of organizations whose primary motivation was to cooperate. As we shifted to a privatized internet, that fundamental design assumption was broken and we have seen some interesting changes as a result. The fact that it still works at all is somewhat of a miracle. Its continued stable operation will vitally require the continued good will and cooperation of the entities playing vital roles. An ISP can be routed-around as damage, although the larger the provider, the more painful the injury. If it becomes necessary, significant portions of the internet will route around Verisign in a similar manner. The difference is that absent ICANN providing for this, there will be no agreed upon replacement, and, several alternatives will emerge. The result will be fragmentation of the root, marginalization of ICANN and a reduction in internet stability. I believe much of ICANN's previous resistance to dealing with Verisign's abuses of their role has been fear of the instability that could result. It has appeared to me to be strategically and tactically very similar to the accomodations made by the powers in Europe in the late 1930s. (No, I am not comparing Verisign's actions to those of Hitler, but, the strategy and tactics are a match.) If ICANN continues to give ground, Verisign's capabilities to commit further abuses will continue to grow as well. Purely from my experience in journalism, media relations and lobbying, I have to respect the effectiveness of the Verisign corporate folk who largely have been setting the terms of debate, and managing the perception -- or misperception -- of this matter in the business and general press. Agreed. This is
Next hop issues inside AS852 ?
Anyone seeing any problems getting to AS852 ? I think the problem is coming back, as I can throw packets out to them and they seem to come back fine via 6539. However, going out and coming back via 852 seems to be hosed for me. (AS11647) From their routeserver, route-views.onshow ip bgp 64.236.16.52 BGP routing table entry for 64.236.16.0/20, version 1861266639 Paths: (2 available, best #2) Advertised to non peer-group peers: 198.32.162.100 198.32.162.102 1668 5662 154.11.0.195 from 154.11.0.151 (154.11.0.151) Origin IGP, metric 1119, localpref 180, valid, internal Originator: 154.11.0.195, Cluster list: 154.11.0.151, 154.11.0.222 1668 5662 154.11.0.195 from 154.11.0.150 (154.11.0.150) Origin IGP, metric 1119, localpref 180, valid, internal, best Originator: 154.11.0.195, Cluster list: 154.11.0.150, 154.11.0.222 route-views.on route-views.ontraceroute www.cnn.com Translating www.cnn.com...domain server (209.115.142.1) [OK] Type escape sequence to abort. Tracing the route to cnn.com (64.236.16.52) 1 toroonxngr00.bb.telus.com (154.11.63.85) 4 msec 0 msec 0 msec 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: data request on Sitefinder
On Mon, 20 Oct 2003 [EMAIL PROTECTED] wrote: On Mon, 20 Oct 2003 16:31:45 EDT, Steven M. Bellovin [EMAIL PROTECTED] said: A number of people havce responded that they don't want to be forced to pay for a change that will benefit Verisign. That's a policy issue I'm trying to avoid here. I'm looking for pure technical answers -- how much lead time do you need to make such changes safely? OK, since you asked At least from where I am, the answer will depend *heavily* on whether Verisign deploys something that an end-user program can *reliably* detect if it's been fed a wildcard it didn't expect. Note that making a second lookup for '*.foo' and comparing the two answers is specifically *NOT* acceptable due to the added lookup latency (and to some extent, the attendant race conditions and failure modes as well). Its not just wildcards. Although the IAB rejected VeriSign's previous request to do specific response synthesis for IDN, it is conceivable that someone else will do 'interesting' response synthesis, which applications will be _unable_ to detect by querying for a wildcard. ( A similar problem to Randy's 'how do I tell which nameserver gave me this response, without requerying?' ) Also note that it has to be done in a manner that can be tested by an application - there will be a *REAL* need for things like Sendmail to be able to test for wildcards *without the assistance* of a patched local DNS. Yes, which implies that many applications would need to change 'gethostbyname()' calls to 'getrealhostbyname()' (or whatever). Whilst many _popular_ applications can be patched in a relatively quick timeframe, the more subtle implications of large scale synthesis deployment will probably take much longer to be understood, let alone patches being deployed, particular with less popular applications. And yes, this means the minimum lead time to deploy is 'amount of time to write a Wildcard Reply Bit I-D, advance through IETF to some reasonable point on standards track, and then upgrade DNS, end host resolvers, and applications'. draft-bcampbell-non-wildcard-00 was submitted last Tuesday to the rfc editor and should appear in time to be discussed during dnsext in Minnie. Even if its approved instantly (very unlikely, as I've suggested using the last reserved header bit), and relevant authoritative nameservers are upgraded in short order, there is a huge implied change to applications and libraries, which extends the deployment timeline tremendously. To answer Steve's question, it would be at least 3 months to patch my employer's applications to work around a possible .com or .net wildcard, and at least 6 months to do it in a fashion which does not break established standards. --==-- Bruce.
Re: data request on Sitefinder
Owen DeLong wrote: The issues that must be addressed are the issues of internet governance, control of the root (does Verisign serve ICANN or vice-versa), and finally, whether the .com/.net zones belong to the public trust or to Verisign. Focusing on the technical is to fiddle while Rome burns. This is the part that drives me nuts. Unless a court ordered it otherwise, the root servers can designate ANYONE as the registry for a tld. My understanding is that the process for making such changes is lengthy and involves the agreement of 3 different organizations. However, on a technical level, such changes are possible, and such a registry can form agreements with ICANN and the various registrars. I'm suddenly reminded of .org... -Jack
Re: Whois software run by Lacnic and BR?
Mark Prior [EMAIL PROTECTED] wrote: [...] The whois server at the .BR registry (also the NIR for Brazil) doesn't provide country information because it's implicit as it only provide information for Brazil. Implicit is fine for humans but for automated scripts, couldn't it be made to have country=BR for all your inetnum entries? When I was running a whois server we discovered that not all local people appeared to want to use a local address. Some of them had head offices used for billing, and the like, that was in a different country so having the country code was useful even for humans. So how should whois users understand country information in the database? Should they interpret it as my network is located in this country? Alternatively, should they interpret it as our corporate offices are in this country? Increasingly, there is a discontinuity between the two as international corporations run networks in many countries from an HQ in just one. If people updating the information in whois have different ideas about its meaning then users of whois its value might be lower than expected. Regards, -- leo vegoda RIPE NCC Registration Services Manager
Re: data request on Sitefinder
At 7:26 AM -0700 10/21/03, Owen DeLong wrote: To inform? Not yet, although I have the feeling that this will be changed due to historic record. However, changes that have an effect are always analyzed and a course of action chosen. I believe this is the job of ICANN. At some point, ICANN's power will need to be tested and set in stone. Only the community can create or strip that power. Yet if an organization is going to exist to serve the community and maintain order, then it needs the power to do it. I will point out that it will be much easier for the community to strip that power than to vest it in another entity. To strip that power only requires one of two things: 1. Enough of the community heading in a different direction and disregarding said entity (ICANN). 2. An organization such as Verisign openly defying ICANN and ICANN failing to make a sufficiently strong response to enforce and protect the consensus will of the community. I think item 1 is unlikely unless fueled by item 2. Verisign would do well to notice that if they do implement the sitefinder wildcards again, and, ICANN does not successfully put a stop to it, the single most likely outcome is for the community to view ICANN as irrelevant and impotent. Once this happens, the inevitable result is a fragmentation of the DNS, disparate roots, and, loss of the convention of a single recognized authority at the root of the tree. This convention is fundamental to the stability of the current internet. Losing it would definitely have negative impact on the end user experience. In every forum to which I have convenient access, Verisign has repeatedly attempted to restrict the discussion to the technical issues around the wildcards. The reality is that the technical issues are the tip of the iceburg and, while costly and significant, they are not the real danger. The issues that must be addressed are the issues of internet governance, control of the root (does Verisign serve ICANN or vice-versa), and finally, whether the .com/.net zones belong to the public trust or to Verisign. Focusing on the technical is to fiddle while Rome burns. Related issues include whether the IETF process, even if flawed, is the consensus means of proposing and discussing changes in the infrastructure. Whether or not the operational forums like NANOG have a role in this process, or even in presenting consensus opinions, also is a basic question for Internet governance. The IETF process is the consensus means of proposing and discussing changes in the DESIGN of the infrastructure, not the construction or maintenance. Valid observation. That _IS_ the role of the network operators and the operators forums. If one thinks of using the IETF model in the operational forums, which I don't consider an unreasonable idea, the operational forums will need specialized mailing lists/working groups, a document handling procedure, and a means of signing off on the best current practices track (analogous to standards track). This isn't rocket science, since most of the conceptual work has been done in the IETF -- mind you, if we ever do this, could we NOT perpetuate some of the more obscure rules in RFC formatting? I'd certainly be willing to work with developing such a process as long as I have a roof over my head (In this economy, I'm more in the will network for food category). I think others will, and I would hope that there's even a little time this week for hallway discussion of the idea. For this to work, however, the operators have to be generally of good will and cooperative for the greater good. This model is somewhat antithetical to capitalism because for it to operate efficiently, it requires the long term good of the community to take precedence over the short-term gains of the individual or single organization. Capitalism is well optimized for the short-term gains of the individual or single organization. This is one of the growing pains that comes from the internet being originated as a government-sponsored community research project. Although there have been precedents for competitive profit-making organizations to cooperate for their mutual benefit. One of the earliest examples is the cooperation of insurers to form Underwriters Laboratories. The design was done assuming a collection of organizations whose primary motivation was to cooperate. As we shifted to a privatized internet, that fundamental design assumption was broken and we have seen some interesting changes as a result. Again, there are precedents for conflict-avoiding organizations, or organizations to mitigate industry-created threats. In the first case are both government organizations like the air traffic control system, and private monitoring centers for utility and telephone networks. We have intermediate cases like the VISA network, owned by its competing member banks. In the latter, we have
Re: Next hop issues inside AS852 ? (resolved)
Thanks to those who replied with info. The Telus folks contacted me not too long ago and corrected an ACL inside their network. ---Mike At 10:46 AM 21/10/2003, Mike Tancsa wrote: Anyone seeing any problems getting to AS852 ? I think the problem is coming back, as I can throw packets out to them and they seem to come back fine via 6539. However, going out and coming back via 852 seems to be hosed for me. (AS11647) From their routeserver, route-views.onshow ip bgp 64.236.16.52 BGP routing table entry for 64.236.16.0/20, version 1861266639 Paths: (2 available, best #2) Advertised to non peer-group peers: 198.32.162.100 198.32.162.102 1668 5662 154.11.0.195 from 154.11.0.151 (154.11.0.151) Origin IGP, metric 1119, localpref 180, valid, internal Originator: 154.11.0.195, Cluster list: 154.11.0.151, 154.11.0.222 1668 5662 154.11.0.195 from 154.11.0.150 (154.11.0.150) Origin IGP, metric 1119, localpref 180, valid, internal, best Originator: 154.11.0.195, Cluster list: 154.11.0.150, 154.11.0.222 route-views.on route-views.ontraceroute www.cnn.com Translating www.cnn.com...domain server (209.115.142.1) [OK] Type escape sequence to abort. Tracing the route to cnn.com (64.236.16.52) 1 toroonxngr00.bb.telus.com (154.11.63.85) 4 msec 0 msec 0 msec 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike
Re: data request on Sitefinder
--On Tuesday, October 21, 2003 10:03:09 AM -0500 Jack Bates [EMAIL PROTECTED] wrote: Owen DeLong wrote: The issues that must be addressed are the issues of internet governance, control of the root (does Verisign serve ICANN or vice-versa), and finally, whether the .com/.net zones belong to the public trust or to Verisign. Focusing on the technical is to fiddle while Rome burns. This is the part that drives me nuts. Unless a court ordered it otherwise, the root servers can designate ANYONE as the registry for a tld. My understanding is that the process for making such changes is lengthy and involves the agreement of 3 different organizations. However, on a technical level, such changes are possible, and such a registry can form agreements with ICANN and the various registrars. I'm suddenly reminded of .org... I can't tell if you are: 1. Agreeing 2. Disagreeing 3. Making a tangential point to what I said. I agree that technically, designating a new registry for .com/.net and transferring the existing zone file to that registry is a simple matter. However, transferring the other metadata associated with the registry function and getting the registrars all cooperating with the new registry is a bit more involved. If this is not done in advance of the root switch, there are stability issues involved. If this is not done proactively by ICANN, then the probability of a successful and smooth transition drops dramatically. Getting registrars, a new registry, and the root servers to do ICANNs bidding is probably relatively simple. Having those decisions survive the legal and lobbying-based challenge that will surely come from Verisign as a result is a bit harder (Verisign will claim it has rights to continue until the end of it's contract and, I suspect, will not simply accept ICANN paying out the remainder of Verisigns contract, even if they could). Getting this to occur without the involvement and cooperation of ICANN will be virtually impossible because of the loyalty divisions. Further, it will make it much easier for Verisign to get injunctions preventing the root server operators from switching to an alternative registry (or reversing such action). I will remind you that .org was done proactively by ICANN with the cooperation of Verisign and that ICANN made concessions to Verisign to get them to cooperate on the .org transition. Owen
netgear sntp followup, embedded address I-D
NANOG folks, I'm posting this as a followup invitation for feedback regarding the SNTP anycast operational strategy I proposed in this talk: http://www.nanog.org/mtg-0310/plonka.html http://net.doit.wisc.edu/~plonka/nanog/nanog29/ [formats other than PDF] The new Internet Draft I mentioned, Embedding Globally Routable Internet Addresses Considered Harmful, can be found here: http://net.doit.wisc.edu/~plonka/embed-addr/ (it hasn't shown up on the IETF internet-drafts site yet) If you have feedback that would benefit from the group's review, please follow-up in the nanog mailing list, otherwise email me personally. Thanks, Dave -- [EMAIL PROTECTED] http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI
News peering/feeding?
I know back in the good old days this used to be fairly common, but does anyone still trade news feeds/peering? We just upgraded our NNTP system and have noticed that the incoming feeds we're receiving are a tad incomplete. So we would like to add a few more feeds. Thanks, -Drew
cityinternet.org DNS issues..
Hi, Has anyone had any fun and exciting DNS issues pertaining to cityinternet.org? For example, try: dig NS1.CITYINTERNET.ORG or dig NS1.CITYINTERNET.ORG If you want to see something really cool, do a WHOIS lookup on 69.64.70.248. Our nameserver is getting inundated with danger messages and I'm trying to figure out a workaround. Thanks in advance for your time. Neezam.
Re: cityinternet.org DNS issues..
Hi, Teaches me to be funny; to prevent myself from getting flamed like there's no tomorrow, let me qualify why I'm bringing this up. On our nameservers, we get the following message: Oct 21 00:00:17 ns named[3203]: sysquery: nslookup reports danger (NS2. CITYINTERNET.ORG) We get a huge volume of them and as a result, the load on our nameservers have increased. So I'm trying to figure out if there is anything I can do to get rid of the messages. Neezam.
Re: cityinternet.org DNS issues..
Neezam Haniff writes on 10/22/2003 1:42 AM: Oct 21 00:00:17 ns named[3203]: sysquery: nslookup reports danger (NS2. CITYINTERNET.ORG) Did you like, try google before wasting your time posting to nanog? http://www.acmebw.com/askmrdns/archive.php?category=83question=143 is the first hit I get when I search for nslookup reports danger -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: cityinternet.org DNS issues..
On Wed, 22 Oct 2003, Suresh Ramasubramanian wrote: Did you like, try google before wasting your time posting to nanog? http://www.acmebw.com/askmrdns/archive.php?category=83question=143 is the first hit I get when I search for nslookup reports danger I did, and I tracked down the problem to be that our nameservers are trying to resolve IP blocks assigned to those DNS servers. Since this is a problem that I cannot solve myself, I'm wondering if there is anything I can do to prevent our nameservers from resolving the ip block 69.64.64.0/20. Neezam.
Re: cityinternet.org DNS issues..
On Tue, Oct 21, 2003 at 03:56:41PM -0400, Neezam Haniff wrote: Has anyone had any fun and exciting DNS issues pertaining to cityinternet.org? For example, try: http://www.isc.org/services/public/lists/bind-lists.html
Re: cityinternet.org DNS issues..
Hi, No worries, someone posted to me offlist pointing out the problem; something that will make me candidate for NANOG's Dumbass of the Year. Go me. *sigh* Just can't win... Neezam.
Heads-up: ATT apparently going to whitelist-only inbound mail
- Forwarded message - Return-Path: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] (added by [EMAIL PROTECTED]) Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 2.102 (B2.12; Q2.03) Date: Tue, 21 Oct 2003 20:21:50 UT Subject: *** ACTION: IP Address of Outbound SMTP Server Requested (Updated 10/21/03) From: [EMAIL PROTECTED] ATT Business Partners Customers ATT has received many of the requested IP addresses in response to an e-mail originally broadcast yesterday to our business partners and clients. However, we have also received many concerned responses to the original request. This 2nd e-mail is to let you know that this is a legitimate ATT request asking for your cooperation, which will let us improve the service that ATT offers you and that our partnership requires. We have provided a toll-free number below to help you confirm the legitimacy of this request. We have assembled the distribution list for this e-mail by looking up the administrative contacts for each of the known e-mail domains we currently exchange e-mail with, referencing WHOIS and other such services available via the Internet. What ATT is asking is for you to help ATT to restrict incoming mail to just our known and trusted sources (e.g., business partners, clients and customers). Therefore, we need to know which IP address(es) are used by your outbound e-mail service so we can selectively permit them. Please send this information to the following e-mail address ([EMAIL PROTECTED]). If you need assistance determining what these IP addresses are, please contact your company's administrative e-mail server support / network administration personnel. We regret that ATT is burdening you with this request, but our ATT security team is advising that we take this step to help safeguard our e-mail systems, which ultimately will help us serve you better. Please contact us with any concerns or questions: ATT Security Help Desk 1-800-456-4230, prompt 4 (8am - 10pm est) Thank you for your prompt attention to this matter. We appreciate your cooperation. Sincerely, Brian Williams, IP Network Services Tim Scholl - District Manager, IP Network Services Kevin O'Connell - Division Manager, Information Technology Services Engineering Bill O'Hern - Division Manager, Network Security - Original Message (Sent Monday, 10/20/03) - ATT has an urgent situation with our anti-spam list. In order to continue to allow email to ATT you need to provide the IP addresses of all your outbound email gateways. If you do not respond immediately, your access may not continue. The required information should be sent to [EMAIL PROTECTED] - End forwarded message -
Re: Heads-up: ATT apparently going to whitelist-only inbound mail
This is apparently already in place, as it explains why all of my ATT emails bounced today. I guess it they don't want any _new_ customers. On Tuesday, October 21, 2003, at 05:24 PM, Jeff Wasilko wrote: - Forwarded message - Return-Path: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] (added by [EMAIL PROTECTED]) Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 2.102 (B2.12; Q2.03) Date: Tue, 21 Oct 2003 20:21:50 UT Subject: *** ACTION: IP Address of Outbound SMTP Server Requested (Updated 10/21/03) From: [EMAIL PROTECTED] ATT Business Partners Customers ATT has received many of the requested IP addresses in response to an e-mail originally broadcast yesterday to our business partners and clients. However, we have also received many concerned responses to the original request. This 2nd e-mail is to let you know that this is a legitimate ATT request asking for your cooperation, which will let us improve the service that ATT offers you and that our partnership requires. We have provided a toll-free number below to help you confirm the legitimacy of this request. We have assembled the distribution list for this e-mail by looking up the administrative contacts for each of the known e-mail domains we currently exchange e-mail with, referencing WHOIS and other such services available via the Internet. What ATT is asking is for you to help ATT to restrict incoming mail to just our known and trusted sources (e.g., business partners, clients and customers). Therefore, we need to know which IP address(es) are used by your outbound e-mail service so we can selectively permit them. Please send this information to the following e-mail address ([EMAIL PROTECTED]). If you need assistance determining what these IP addresses are, please contact your company's administrative e-mail server support / network administration personnel. We regret that ATT is burdening you with this request, but our ATT security team is advising that we take this step to help safeguard our e-mail systems, which ultimately will help us serve you better. Please contact us with any concerns or questions: ATT Security Help Desk 1-800-456-4230, prompt 4 (8am - 10pm est) Thank you for your prompt attention to this matter. We appreciate your cooperation. Sincerely, Brian Williams, IP Network Services Tim Scholl - District Manager, IP Network Services Kevin O'Connell - Division Manager, Information Technology Services Engineering Bill O'Hern - Division Manager, Network Security - Original Message (Sent Monday, 10/20/03) - ATT has an urgent situation with our anti-spam list. In order to continue to allow email to ATT you need to provide the IP addresses of all your outbound email gateways. If you do not respond immediately, your access may not continue. The required information should be sent to [EMAIL PROTECTED] - End forwarded message - Regards Marshall Eubanks T.M. Eubanks e-mail : [EMAIL PROTECTED] http://www.telesuite.com
Re: Heads-up: ATT apparently going to whitelist-only inbound mail
On Tuesday, 2003-10-21 at 17:24 AST, Jeff Wasilko [EMAIL PROTECTED] wrote: - Forwarded message - What ATT is asking is for you to help ATT to restrict incoming mail to just our known and trusted sources (e.g., business partners, clients and customers). Therefore, we need to know which IP address(es) are used by your outbound e-mail service so we can selectively permit them. Please send this information to the following e-mail address ([EMAIL PROTECTED]). - Original Message (Sent Monday, 10/20/03) - ATT has an urgent situation with our anti-spam list. In order to continue to allow email to ATT you need to provide the IP addresses of all your outbound email gateways. If you do not respond immediately, your access may not continue. The required information should be sent to [EMAIL PROTECTED] - End forwarded message - It sure looks to me that they are referring to outbound (from the customer, through ATT, to the Internet) mail only. Presumably this means they are going to either block all 25/tcp from their customers except from those addresses on their list. Alternatively they might be routing all outbound customer mail from non-whitelisted machines through a transparent proxy; possibly the proxy would rate limit the amount of mail being allowed. Tony Rall
Re: Heads-up: ATT apparently going to whitelist-only inbound mail
Wow, this sounds like a pretty extreme shotgun approach. (or is it April 1st somewhere). Is ATT going to make this whitelist publicly available ? Perhaps if there was some global white list that everyone could consult against, it might be a little more useable. Still, what do you do about multi-stage relays ? ---Mike At 05:24 PM 21/10/2003, Jeff Wasilko wrote: - Forwarded message - Return-Path: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] (added by [EMAIL PROTECTED]) Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 2.102 (B2.12; Q2.03) Date: Tue, 21 Oct 2003 20:21:50 UT Subject: *** ACTION: IP Address of Outbound SMTP Server Requested (Updated 10/21/03) From: [EMAIL PROTECTED] ATT Business Partners Customers ATT has received many of the requested IP addresses in response to an e-mail originally broadcast yesterday to our business partners and clients. However, we have also received many concerned responses to the original request. This 2nd e-mail is to let you know that this is a legitimate ATT request asking for your cooperation, which will let us improve the service that ATT offers you and that our partnership requires. We have provided a toll-free number below to help you confirm the legitimacy of this request. We have assembled the distribution list for this e-mail by looking up the administrative contacts for each of the known e-mail domains we currently exchange e-mail with, referencing WHOIS and other such services available via the Internet. What ATT is asking is for you to help ATT to restrict incoming mail to just our known and trusted sources (e.g., business partners, clients and customers). Therefore, we need to know which IP address(es) are used by your outbound e-mail service so we can selectively permit them. Please send this information to the following e-mail address ([EMAIL PROTECTED]). If you need assistance determining what these IP addresses are, please contact your company's administrative e-mail server support / network administration personnel. We regret that ATT is burdening you with this request, but our ATT security team is advising that we take this step to help safeguard our e-mail systems, which ultimately will help us serve you better. Please contact us with any concerns or questions: ATT Security Help Desk 1-800-456-4230, prompt 4 (8am - 10pm est) Thank you for your prompt attention to this matter. We appreciate your cooperation. Sincerely, Brian Williams, IP Network Services Tim Scholl - District Manager, IP Network Services Kevin O'Connell - Division Manager, Information Technology Services Engineering Bill O'Hern - Division Manager, Network Security - Original Message (Sent Monday, 10/20/03) - ATT has an urgent situation with our anti-spam list. In order to continue to allow email to ATT you need to provide the IP addresses of all your outbound email gateways. If you do not respond immediately, your access may not continue. The required information should be sent to [EMAIL PROTECTED] - End forwarded message -
Re: Heads-up: ATT apparently going to whitelist-only inbound mail
Here is my experience (names are changed to protect...) : Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain att.com) reports: message text rejected by ckmsi2.att.com: 550 5.7.1 Your message was rejected as possible spam. Please call your ATT contact. [3] Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain att.com) reports: message text rejected by ckmsi2.att.com: 550 5.7.1 Your message was rejected as possible spam. Please call your ATT contact. [3] Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain att.com) reports: message text rejected by ckmsi2.att.com: 550 5.7.1 Your message was rejected as possible spam. Please call your ATT contact. [3] Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain att.com) reports: message text rejected by ckmsi2.att.com: 550 5.7.1 Your message was rejected as possible spam. Please call your ATT contact. [3] Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain att.com) reports: message text rejected by ckmsi2.att.com: 550 5.7.1 Your message was rejected as possible spam. Please call your ATT contact. [3] On Tuesday, October 21, 2003, at 05:46 PM, Mike Tancsa wrote: Wow, this sounds like a pretty extreme shotgun approach. (or is it April 1st somewhere). Is ATT going to make this whitelist publicly available ? Perhaps if there was some global white list that everyone could consult against, it might be a little more useable. Still, what do you do about multi-stage relays ? ---Mike At 05:24 PM 21/10/2003, Jeff Wasilko wrote: - Forwarded message - Return-Path: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] (added by [EMAIL PROTECTED]) Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 2.102 (B2.12; Q2.03) Date: Tue, 21 Oct 2003 20:21:50 UT Subject: *** ACTION: IP Address of Outbound SMTP Server Requested (Updated 10/21/03) From: [EMAIL PROTECTED] ATT Business Partners Customers ATT has received many of the requested IP addresses in response to an e-mail originally broadcast yesterday to our business partners and clients. However, we have also received many concerned responses to the original request. This 2nd e-mail is to let you know that this is a legitimate ATT request asking for your cooperation, which will let us improve the service that ATT offers you and that our partnership requires. We have provided a toll-free number below to help you confirm the legitimacy of this request. We have assembled the distribution list for this e-mail by looking up the administrative contacts for each of the known e-mail domains we currently exchange e-mail with, referencing WHOIS and other such services available via the Internet. What ATT is asking is for you to help ATT to restrict incoming mail to just our known and trusted sources (e.g., business partners, clients and customers). Therefore, we need to know which IP address(es) are used by your outbound e-mail service so we can selectively permit them. Please send this information to the following e-mail address ([EMAIL PROTECTED]). If you need assistance determining what these IP addresses are, please contact your company's administrative e-mail server support / network administration personnel. We regret that ATT is burdening you with this request, but our ATT security team is advising that we take this step to help safeguard our e-mail systems, which ultimately will help us serve you better. Please contact us with any concerns or questions: ATT Security Help Desk 1-800-456-4230, prompt 4 (8am - 10pm est) Thank you for your prompt attention to this matter. We appreciate your cooperation. Sincerely, Brian Williams, IP Network Services Tim Scholl - District Manager, IP Network Services Kevin O'Connell - Division Manager, Information Technology Services Engineering Bill O'Hern - Division Manager, Network Security - Original Message (Sent Monday, 10/20/03) - ATT has an urgent situation with our anti-spam list. In order to continue to allow email to ATT you need to provide the IP addresses of all your outbound email gateways. If you do not respond immediately, your access may not continue. The required information should be sent to [EMAIL PROTECTED] - End forwarded message - Regards Marshall Eubanks T.M. Eubanks e-mail : [EMAIL PROTECTED] http://www.telesuite.com
Re: Heads-up: ATT apparently going to whitelist-only inbound mail
I'm not sure whether shadenfreude is the right word, however, it seems that, regarding a previous conversation about cutting off users infected with viruses, ATT has decided that putting a bit of stick about is the right thing to do. It will be very interesting to see how this works out, as it may set a very big precedent. I just hope that they do it subnet by subnet over time instead of all at once, so that the interruption can be isolated brifly to small areas over a longer period of time. I don't envy their customers, or their security department for having to resort to this, but we should all be watching for the results, as it may make or break the case for dealing with user sites that expose the network to risk. Best, -j -- Jamie.Reid, CISSP, [EMAIL PROTECTED] Senior Security Specialist, Information Protection Centre Corporate Security, MBS 416 327 2324 Jeff Wasilko [EMAIL PROTECTED] 10/21/03 05:24pm - Forwarded message - Return-Path: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] (added by [EMAIL PROTECTED]) Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 X-Mailer: MIME::Lite 2.102 (B2.12; Q2.03) Date: Tue, 21 Oct 2003 20:21:50 UT Subject: *** ACTION: IP Address of Outbound SMTP Server Requested (Updated 10/21/03) From: [EMAIL PROTECTED] ATT Business Partners Customers ATT has received many of the requested IP addresses in response to an e-mail originally broadcast yesterday to our business partners and clients. However, we have also received many concerned responses to the original request. This 2nd e-mail is to let you know that this is a legitimate ATT request asking for your cooperation, which will let us improve the service that ATT offers you and that our partnership requires. We have provided a toll-free number below to help you confirm the legitimacy of this request. We have assembled the distribution list for this e-mail by looking up the administrative contacts for each of the known e-mail domains we currently exchange e-mail with, referencing WHOIS and other such services available via the Internet. What ATT is asking is for you to help ATT to restrict incoming mail to just our known and trusted sources (e.g., business partners, clients and customers). Therefore, we need to know which IP address(es) are used by your outbound e-mail service so we can selectively permit them. Please send this information to the following e-mail address ([EMAIL PROTECTED]). If you need assistance determining what these IP addresses are, please contact your company's administrative e-mail server support / network administration personnel. We regret that ATT is burdening you with this request, but our ATT security team is advising that we take this step to help safeguard our e-mail systems, which ultimately will help us serve you better. Please contact us with any concerns or questions: ATT Security Help Desk 1-800-456-4230, prompt 4 (8am - 10pm est) Thank you for your prompt attention to this matter. We appreciate your cooperation. Sincerely, Brian Williams, IP Network Services Tim Scholl - District Manager, IP Network Services Kevin O'Connell - Division Manager, Information Technology Services Engineering Bill O'Hern - Division Manager, Network Security - Original Message (Sent Monday, 10/20/03) - ATT has an urgent situation with our anti-spam list. In order to continue to allow email to ATT you need to provide the IP addresses of all your outbound email gateways. If you do not respond immediately, your access may not continue. The required information should be sent to [EMAIL PROTECTED] - End forwarded message - !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN HTMLHEAD META http-equiv=Content-Type content=text/html; charset=windows-1252 META content=MSHTML 6.00.2800.1226 name=GENERATOR/HEAD BODY style=MARGIN-TOP: 2px; FONT: 8pt Tahoma; MARGIN-LEFT: 2px DIVFONT size=1/FONTnbsp;/DIV DIVFONT size=1I'm not sure whether shadenfreude is the right word, however, it seems that, /FONT/DIV DIVFONT size=1regarding a previous conversation about cutting offnbsp;users infected with viruses,/FONT/DIV DIVnbsp;FONT size=1ATT has decided that putting a bit of stick /FONTFONT size=1about is the right thing to do. /FONT/DIV DIVFONT size=1/FONTnbsp;/DIV DIVFONT size=1It will be very interesting to see how this works /FONTFONT size=1out, as it may set a very /FONT/DIV DIVFONT size=1big precedent. /FONT/DIV DIVFONT size=1/FONTnbsp;/DIV DIVFONT size=1Inbsp;just nbsp;hope that they do it subnet by subnet over time instead of all at once, /FONT/DIV DIVFONT size=1so that the interruption can be isolated brifly to small areas over a longer /FONT/DIV DIVFONT size=1period of /FONTFONT size=1time.nbsp; I don't envy their customers, or their security department/FONT/DIV DIVFONT size=1for having to resort to this, but we should all be watching for the results,
Re: Heads-up: ATT apparently going to whitelist-only inbound mail
I'm getting nothing but timeouts at this point to any of att's mail servers. Nothing going through at all. -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org ICQ: 8077511 - Original Message - From: Marshall Eubanks [EMAIL PROTECTED] To: Mike Tancsa [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 21, 2003 5:57 PM Subject: Re: Heads-up: ATT apparently going to whitelist-only inbound mail Here is my experience (names are changed to protect...) : Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain att.com) reports: message text rejected by ckmsi2.att.com: 550 5.7.1 Your message was rejected as possible spam. Please call your ATT contact. [3] Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain att.com) reports: message text rejected by ckmsi2.att.com: 550 5.7.1 Your message was rejected as possible spam. Please call your ATT contact. [3] Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain att.com) reports: message text rejected by ckmsi2.att.com: 550 5.7.1 Your message was rejected as possible spam. Please call your ATT contact. [3] Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain att.com) reports: message text rejected by ckmsi2.att.com: 550 5.7.1 Your message was rejected as possible spam. Please call your ATT contact. [3] Failed to deliver to '[EMAIL PROTECTED]' SMTP module(domain att.com) reports: message text rejected by ckmsi2.att.com: 550 5.7.1 Your message was rejected as possible spam. Please call your ATT contact. [3] On Tuesday, October 21, 2003, at 05:46 PM, Mike Tancsa wrote: Wow, this sounds like a pretty extreme shotgun approach. (or is it April 1st somewhere). Is ATT going to make this whitelist publicly available ? Perhaps if there was some global white list that everyone could consult against, it might be a little more useable. Still, what do you do about multi-stage relays ? ---Mike
Re: Heads-up: ATT apparently going to whitelist-only inbound mail
Jeff Wasilko wrote: What ATT is asking is for you to help ATT to restrict incoming mail to just our known and trusted sources (e.g., business partners, clients and customers). Therefore, we need to know which IP address(es) are used by your outbound e-mail service so we can selectively permit them. Please send this information to the following e-mail address ([EMAIL PROTECTED]). And none of ATT's legitimate business partners, clients, and customers have dynamic IP addresses? None of them go home and relay through their home ISP? Or use YourFreeFlyByNightWebMailPopUpAdSite.com when off site? I mean dealing with spam and email borne worms costs money, but I cannot imagine how much $$$ in administrative overhead this policy will cost. This is going to burn many man-hours to build and then to maintain forever and ever and ever. Any ATTers on this list know the inside story? And I would think something like this will show up in the trade rags if not the techology section of mainstream media outlets. Anyone seen anything (or should I wait for it to hit /.)? -- Crist J. Clark [EMAIL PROTECTED] Globalstar Communications(408) 933-4387
OT: Chicago field trip, late tonight...
In November, 2000, the radio show This American Life condensed twenty-four hours of life in a Chicago neighborhood 24-hour cafe into a one-hour show. This cafe was the site of notable quantitative experiments demonstrating that rotating pies sold significantly better than static ones. We may wish to independently corroborate their results using the same data source. I propose that we conduct this experiment at midnight, tonight. The Golden Apple cafe can be reached on the El, Chicago's elevated railway: http://www.transitchicago.com/maps/maps/F2003N.html Wellington on the Brown Line or Scheffield on the Purple Line (same station). The This American Life radio show, with a textual abstract and full version in Real Audio: http://207.70.82.73/pages/descriptions/00/172.html A restaurant review: http://entertainment.metromix.chicagotribune.com/top/1,1419,M-Metromix-Restaurants-golden+apple!PlaceDetail-3696,00.html And a driving map, in case you don't like the train: http://www.mapquest.com/directions/main.adp?go=1do=nwct=NA1y=US1a=540+north+michigan1c=chicago1s=il1z=1ah=2y=US2a=2971+N.+LINCOLN+AVE2c=chicago2s=il2z=2ah= If folks like, they can meet in the lobby of the Marriott at 11:20pm. -Bill
NSI gives away a years reg and free transfer of the domain name...
Hey all - I got this advertising email blurb today from NSI saying that I could move all my domains to NSI and get an additional free years subscription. And there is NO movement cost. Interesting marketing ploy - how many others got one of these... Todd
Re: NSI gives away a years reg and free transfer of the domain name...
On Tue, Oct 21, 2003 at 04:01:22PM -0700, todd glassey wrote: Hey all - I got this advertising email blurb today from NSI saying that I could move all my domains to NSI and get an additional free years subscription. And there is NO movement cost. Interesting marketing ploy - how many others got one of these... Sounds like long distance carriers all over again, people will be transferring their domain back and forth when it nears expiration =) Todd -- Matthew S. HallacyFUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203
Re: How long much advanced notice do ISPs need to deploy IPv6?
On Tue, 21 Oct 2003, Sean Donelan wrote: How much notice is adequate when changing widely used behavior on the Internet? Widely deployed Filters, including uRPF, would probably qualify as this right? When the ARPANET changed from NCP to TCP/IP how many days advance notice was needed? When the Internet changed from IPv4 to IPv6 how many days advance notice was needed? I'm going to show some (alot?) ignorance here... BUT: won't the network go: pure-v4 - v4+v6 - v6 (probably with v4 tunnels) - pure-v6 I don't think its just going to go: POOF! one night, nor in one year... Judging by how long it takes people to upgrade a simple major application or OS it'll take YEARS to upgrade entirely to pure-v6. of course, I could be completely wrong.
Unusual GET requests
Hmmm, this is probably offtopic, but I can't seem to find anything online which explains this and I've never seen it before. Maybe someone else here has seen this in their logs or has any idea what would do this? Its obviously trying to gather some sort of information, could it be a prelude to some sort of DoS or exploit thats not publically known yet? 68.63.88.173 - - [21/Oct/2003:19:47:49 -0500] GET /pad-Files HTTP/1.1 404 322 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:49 -0500] GET /PAD-FILES HTTP/1.1 404 322 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:49 -0500] GET /Pad-Files HTTP/1.1 404 322 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:48 -0500] GET /Pad-files HTTP/1.1 404 322 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:48 -0500] GET /pad-files HTTP/1.1 404 322 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:48 -0500] GET /PAD-FILE HTTP/1.1 404 321 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:48 -0500] GET /Pad-file HTTP/1.1 404 321 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:47 -0500] GET /pad-File HTTP/1.1 404 321 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:47 -0500] GET /Pad-File HTTP/1.1 404 321 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:44 -0500] GET /PadFiles HTTP/1.1 404 321 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:44 -0500] GET /Padfiles HTTP/1.1 404 321 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:44 -0500] GET /PADFILES HTTP/1.1 404 321 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:44 -0500] GET /padfiles HTTP/1.1 404 321 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:43 -0500] GET /PadFile HTTP/1.1 404 320 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:43 -0500] GET /Padfile HTTP/1.1 404 320 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:43 -0500] GET /PADFILE HTTP/1.1 404 320 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:43 -0500] GET /padfile HTTP/1.1 404 320 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:43 -0500] GET /Pads HTTP/1.1 404 317 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:43 -0500] GET /PADS HTTP/1.1 404 317 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:42 -0500] GET /pads HTTP/1.1 404 317 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:42 -0500] GET /Pad HTTP/1.1 404 316 - l ibwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:42 -0500] GET /PAD HTTP/1.1 404 316 - l ibwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:42 -0500] GET /pad HTTP/1.1 404 316 - l ibwww-perl/5.65 -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org ICQ: 8077511
Re: Unusual GET requests
At 8:59 PM -0400 10/21/03, Brian Bruns wrote: 68.63.88.173 - - [21/Oct/2003:19:47:49 -0500] GET /pad-Files HTTP/1.1 404 322 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:49 -0500] GET /PAD-FILES HTTP/1.1 404 322 - libwww-perl/5.65 68.63.88.173 - - [21/Oct/2003:19:47:49 -0500] GET /Pad-Files HTTP/1.1 404 322 - libwww-perl/5.65 That's VeriSign's new spell corrector DNS wildcard. :-) -- Kee Hinckley http://www.messagefire.com/ Next Generation Spam Defense http://commons.somewhere.com/buzz/ Writings on Technology and Society I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
Re: How long much advanced notice do ISPs need to deploy IPv6?
Sean Donelan wrote: How much notice is adequate when changing widely used behavior on the Internet? When the ARPANET changed from NCP to TCP/IP how many days advance notice was needed? Umm, hard to remember that long ago, and haven't looked at IENs in ages, but should memory serve me correctly, the first TCP/IP documents I read were circa 1978, and the cutover was circa 1983. However, I wasn't directly involved -- my email eventually went through a gateway at UMich to ARPAnet -- and the network I was cobbling together on a NOAA+EPA grant used bisync, X.25 (for the satellite links), and an assortment of serial protocols (such as 5-bit baudo coded weather data) that we mixed together on Alpha somethingorothers and Interdata 7/32s, first with the proprietary OS, and then with a new-fangled thingy called Unix. (Now, we'll drag out the old stories for the kiddies.) The folks at Merit fed me the TCP/IP documents, and were a lot more closely involved in the cutover. When the Internet changed from IPv4 to IPv6 how many days advance notice was needed? Well, we finished the initial design in 1993 (I was part of the original design team), and the cutover will be (heavy sigh) probably never After all, it's time to design the next generation! When the COM and NET zone behvior was changed to eliminate NXDOMAIN how many days advance notice was needed? sarcasm Oh, there was advance notice? /sarcasm I wrote my first DNS implementation in 1987. I know it's still in use on a number of old routers and dialup access boxen. My guess would be another 16 years, or so, to clean up the entire mess. Easier to eliminate the problem at the source! -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
RE: How long much advanced notice do ISPs need to deploy IPv6?
Sean Donelan wrote: When the Internet changed from IPv4 to IPv6 how many days advance notice was needed? Uhh if the Internet has changed from IPv4 to IPv6 how come I can't find a single ISP that provides IPv6 service in the capital of California? Michel.
RE: How long much advanced notice do ISPs need to deploy IPv6?
On Tue, 21 Oct 2003, Michel Py wrote: Sean Donelan wrote: When the Internet changed from IPv4 to IPv6 how many days advance notice was needed? Uhh if the Internet has changed from IPv4 to IPv6 how come I can't find a single ISP that provides IPv6 service in the capital of California? note, I'm obviously NOT a sales person, BUT... http://www.verio.net/access/ipv6.cfm perhaps you should ask them?
