J’raxis·Com
J’raxis·Com
As of 2005-04-04, the servers listed below are known to be working, or at least existing. All servers support connections on port 6667; some also allow connections on 6660–6669 and 7000. Often it’s best to try to connect directly to the IP address, and not use the hostname, as DALnet changes the hostnames’ IPs to 127.0.0.1 or 255.255.255.255 when they’re being packeted, and some servers’ hostnames are being redirected to the “main” DALnet server, irc.dal.net.
And as of 2005-04-04, the following servers appear to be dead:
As founder of the nameless channel, J’raxis practically lives on DALnet, but that doesn’t mean he has a problem recognizing how disastrously the network is run and how poorly some of the software, both Services and the server itself, seem to be designed and coded. J’raxis hopes that by collecting all of these examples here, perhaps some of these “features” will be fixed, and policies revisited.
DALnet is completely inconsistent with whether or not a new “feature” (or bug, or annoyance) will use new numeric responses or use server notices. Additionally, some new “features” tend to hijack numerics that already serve different purposes on other networks, and other “features” overload the semantics of preëxisting numerics.
DALnet implemented a “feature” that prevents users from flooding a channel with CTCPs. Sounds useful, right? Except they didn’t stop to think that the /ME command is implemented as a CTCP—so now if one or more users issue more than four /ME lines within a few seconds, the server rudely blocks it, sends a server notice (see previous item) to the channel, and prevents anyone from using CTCPs for the next 15–20 seconds.
DALnet replaced the output of the /LINKS command with a simple flat list of all the extant servers. (Note that says “extant,” not “working” or “those with actual IP addresses.”)
Wait, DALnet has servers without actual IP addresses?
DALnet, in their infinite wisdom, decided that, due to all the packeting attacks they suffer, they would stop allowing people to connect to individual servers, redirect the publicly-known server names to the same IP address, that of irc.dal.net, and set up irc.dal.net as an anycast server (the “IX Concept”).
Anycast is a pretty nice setup, but since this is DALnet, there is, of course, a problem—these anycast servers are only reachable from ISPs who get on board with the scheme. If a user tries to connect to irc.dal.net from an ISP that hasn’t “peered” with DALnet, the server is completely uncontactable, making DALnet look like it did back in the days when it was being packeted to death.
Fortunately a handful of servers haven’t moved to IX yet, and continue to publish their actual IP addresses.
One of the main selling points is that these IX servers are resistant to DDoS attacks—since traffic is routed from a user to the nearest server represented by the anycast IP address, it makes it very difficult to overload these servers: e.g., an attack originating from a host in Indonesia would end up flooding an Asian DALnet server that sits behind irc.dal.net, but an attack originating from a host in New York would end up flooding an American server. Thus, a sufficiently large botnet located in the same geographic region could end up overloading the DALnet servers serving that region, or a sufficiently large worldwide botnet (J’raxis is sure the kiddies are already assembling one sufficiently large enough, as kiddies are wont to do) could still succeed in taking the entire thing down.
J’raxis believes this is the only instance of someone responding to DDoS attacks by introducing a single point-of-failure into a system. It may be hard to take out irc.dal.net, but if it were to be taken down, that pretty much renders DALnet offline.
In 2004-09, DALnet began to roll out the server software that finally implemented the +j, +e, and +I channel modes. This was originally planned many, many months ago and it seems they finally got around to finishing it. Well, no, not finishing it: Most of the servers on the network still don’t implement the modes, and, after a netsplit, these servers rudely clear a +j setting by replacing it with +j 0.
Additionally, as of 2004-10-30, setting a mode of +j 1:5 produces +j 4:5. As far as J’raxis knows, 1 ≠ 4 for any values of 1, including extremely large ones. This behavior happen for any values less than four—e.g., setting +j 5:6 works as expected, while setting +j 2:6 results in +j 4:6.
According to an IRCop with whom J’raxis discussed this, apparently this behavior is intentional—the calculations that a server performs when a user tries to join a channel are reportedly CPU-intensive, and low +j settings hopelessly confuse hapless newbies when they’re blocked from entering a channel, so a minimum +j value was mandated by DALnet.
One of the purposes of +j is to rate-limit channel joins in order to keep bot floods to a minimum. A setting of 1:5, for example, works well in this regard—it allows only one join every five seconds, whereas a setting of 4:20 (a naïve attempt to scale 1:5 upward to work around this bug/feature) is ineffective—four flood bots can quickly pile into a channel before the mode goes into effect. And four bots are more than enough to wreak havoc before ops’ scripts kick into action and ban the bots.
Unfortunately, from the DALnet coders’ perspective, the point of +j isn’t to stop all bot floods, but to simply stem the tide of a massively bandwidth-intensive one. Four bots—about sixteen lines of crap before they get throttled—is enough to disrupt the hell out of a channel, but it’s not bandwidth-intensive enough to qualify as worthy of being blocked by +j.
So, to summarize, DALnet has taken a potentially useful mode and half-assed it before they even finished rolling it out across the network.
Then there’s the infamous +R mode. This mode came came into existence long ago but didn’t actually work for more than a year afterward. The purpose of this mode was, in channel contexts, to prevent users with unregistered nicks from joining, and in nick contexts, to prevent them from querying you. The way it worked, in practice, was to completely lock out users. All users. Brilliance.
* Never makes, as a counter-argument, a complex mime about weighing on one hand the benefits of programming and doing actual work, and in the other hand the benefits of doing eight pounds of blow in a week.
* Never leaves, as an exercise for the reader, the actual conclusion as to which side DALnet’s programmers decide is more important.
<Never> I defy you to show a single instance where a DALnet programmer, faced with eight pounds of blow, would do anything other than immediately fall on his face and root around in it, snuffling like some sort of insane powder-faced truffle hog.
And there’s also the +r user mode. This mode is set by Services when you identify for a nick—except the server makes it look like you set the mode by showing your nick/user/host, not Services’, as the sender.
There was also a +r channel mode, which meant mostly the same thing, but it mysteriously disappeared one day and hasn’t been heard from since. Apparently DALnet made up this mode out of thin air before realizing it would confuse clients that assumed +r meant a restricted channel, as it means on other networks.
A number of servers require ident to be enabled by clients originating from certain ISPs or IP blocks. One justification of requiring ident is that this supposedly thwarts abuse from users connecting from shell providers (or other UNIX machines where identd, a root process, isn’t under the users’ control), except most of the ISPs that are required to have an ident response are home DSL/cable ISPs, such as cox.net or rr.com, and some entire ccTLDs such as *.tr or *.mx. DALnet says that requiring ident for these domains is because these domains often host exploited computers, and it’s “difficult” for a user to connect through an infected machine and still have a valid ident response. This is almost a legitimate reason—until the next 31336.999 kiddie writes a Trojan or worm that includes an ident server that returns randomized responses.
And the icing on this cake of stupidity? A number of servers frequently begin dropping ident queries on connect when they become overloaded. Do you think these servers waive the no-ident aKill? This is DALnet; guess.
The “successor” Services feature existed—it could be viewed in a channel’s info, and could be set by the founder—for well over a year before actually being implemented.
DALnet’s server code is based on the original IRC server implementation. J’raxis took one look at this rat’s nest of code (it uses strtok(), for fuck’s sake!), and suddenly realized why nothing ever gets fixed, why new features take slightly longer than forever to be implemented, and why they don’t work right when they finally are implemented.
DALnet’s solution to the problem of nick chasers—lusers who obsessively try to be the first one to grab a “leet” nick that’s about to drop—was to replace second-resolution timestamps with relative ones in the last-seen field in NickServ’s nick info display. For example, it would only display how many days ago a user was seen after they had been gone for more than twenty-four hours, and, after a week, it would merely say they hadn’t been seen for more than seven days.
This “solution” was withdrawn within a few days due to a massive amount of complaints.
DALnet then modified Services to display month names instead of numbers, i.e., they went from displaying something like 28/09/2004 to displaying 28-Sep-2004. (Compliments on replacing one hideous date format with another, also!) The “point” of this sudden and unannounced change was to, again, thwart nick chasers, particularly those who use automated scripts to calculate how soon a nick is about to drop. DALnet coders seem to believe that adding a couple lines to a script to translate month names into numbers is some kind of insurmountable difficulty.
This bit of idiocy is still in place and is most likely permanent.
IRCops frequently put notices in their away messages such as, “For operator help, go to #OperHelp.” (You might think this is to be “helpful,” but it’s more likely because they don’t want to be bothered.) After other users started putting this in their away messages, IRCops accused these users of trying to impersonate opers, then started aKilling people and freezing their nicks. The IRCops are probably right that lusers are trying to trick naïve newbies, but an IRCop can be identified by the presence of a 313 line in the whois output, which states quite plainly that an IRCop is, indeed, an IRCop. So, this is stupid, and completely arbitrary.
A multitude of nick and username patterns are automatically treated as possible (meaning certain) Trojans, and cause a user to be immediately disconnected upon connect. If one tries to reconnect quickly, one cannot even get to the NICK/USER stage as the server will immediately close the connection. This is stupid, arbitrary, and incredibly annoying.
So far, J’raxis has discovered that “short” (especially one-letter) usernames, “short” real names, and nicks of the format text[numbers] and text-numbers result in automatic aKills. There are most likely many more.
DALnet used to publish aKill information in the output of a /STATS command, but no longer does. So now when some hapless user falls victim to an overly broad and mysterious aKill, he has to try and guess what pattern he’s matching with no way to tell other than to reconnect and try, try again.
DALnet recently redesigned the NickServ “enforce” setting to, instead of merely guestifying users who try to use someone else’s nick, guestify a user and then hold the nick indefinitely, forcing the owner of the nick to identify and then issue a RELEASE command before being able to use the nick again. This new “feature” makes it almost impossible to use a registered nick as one connects, as one may, instead of actually connecting, get rudely interrupted by Services, often throwing the client into confusion and forcing one to disconnect and reconnect under a temporary nick.
Naturally, reconnecting too quickly often results in the server accusing you of flooding, disconnecting you, and threatening to aKill you.
Initially, DALnet overloaded the 433 numeric reply (nick in use), but then silently changed it to 432 (erroneous nick). Overloading the semantics of numerics is a Bad Idea: it means that if one wants to write code to handle this specific contingency differently from ordinary erroneous nicks, one must scan the text of the reply for specific keywords in order to do so. Additionally, in this specific case, 433 was a better choice to overload than 432.
As of 2004-09-28, DALnet is now automatically disconnecting people that set long away messages! How long, you may ask? Who knows! “Long” away messages apparently indicate “channel filler” bots and result in an immediate disconnect with the rather ungrammatical kill message—
Killed (stats.dal.net (User has been banned from DALnet ([clones/Fillers] are not allowed on DALnet from Go to http://kline.dal.net/exploits/exploitsakill.htm for more info)))
“Stupid” doesn’t even begin to describe this one: Words have yet to be invented that could properly capture the sheer idiocy, the complete and total moronicy, the unbounded imbecility, the absolutely, fantastical, unbelievable ass-hattery of the decision-making process that had to come together and fuck itself sideways to result in this policy. All the stupidity in the Universe couldn’t conspire together to come up with an idea this absolutely fucktastical. It’s beyond stupid—it’s transtupid, metastupid, hyperstupid. It’s stupid within stupid within stupid—it’s some sort of fractal stupidity such that when you peel back each layer of stupidity all you find is more and more and more stupidity in a never-ending inward spiral of stupid.
J’raxis, after composing himself, would like to believe that this is merely some sort of accident, that perhaps an IRCop was being a tad too “liberal” with the crack the last time he was editing a configuration file, but then again, this is DALnet.
As of 2004-10-13, it seems that the +e mode has been rendered essentially useless by a new Services “feature.” Services has been “upgraded” to be aware of +e settings, but only to the extent that it clears them when setting an aKick. So, if you want to put a broad banmask on aKick, but then exempt a few specific users with +e, you can’t do it—ChanServ intentionally overrides this.
It appears that ChanServ will eventually have, in addition to the aKick list, an “auto-exempt” list, but this feature is only half-implemented at the moment: If you type /CHANSERV EXEMPT LIST, it tells you the command is only available to “Services Root” users. J’raxis suspects it will be fully implemented sometime between two years from now and the ultimate heat death of the Universe.
So, until DALnet gets around to finishing this feature, the +e mode is essentially useless—just like +j.
The following transcript, provided without any further commentary, should describe beyond any shadow of a doubt how useless the existence of Services has become—
*** J^raxis already in use; retrying with Guest31337…—NickServ— Password accepted for J^raxis./NICKSERV IDENTIFY J^raxis password/NICKSERV GHOST J^raxis—NickServ— Your ghost has been successfully killed./NICK J^raxis*** J^raxis: Nickname is already in use./NICKSERV GHOST J^raxis—NickServ— Your ghost has been successfully killed./NICK J^raxis*** J^raxis: Nickname is already in use./NICKSERV RELEASE J^raxis—NickServ— The nickname J^raxis has been released./NICK J^raxis*** J^raxis: Nickname is already in use.
Apparently if one tries to use a nick, username, and real-name field that matches poutine, footeen, grooteen, rooteen, or something similar (the exact pattern is unknown; it’s not something as simple as -teen, -tine, or seven characters), and tries to set the +R user mode, one is aKilled with:
Killed (services2.dal.net (Autokilled: You match the pattern of a known trojan, please check your system with a cleaner from http://www.moosoft.com or Swat-it from http://www.lockdowncorp.com/bots/downloadswatit.html [AKILL ID: OS21114311280-100]))
Advice from the ever-useful IRCops is to just change one’s real-name field to not match the nick and username, but, as of 2005-04-23, that doesn’t seem to work anymore—as a # voice, poutine, can attest. DALnet’s explanation for this ridiculous-looking aKill is of course nonexistent.
Speaking of aKill messages, here’s a useful one:
autokilled: [AKILL ID:1114410286K-a] [exp/comp] compromised host. At the time of the ban, this host was detected as possibly causing a problem on our network. For more information go to http://kline.dal.net/exploits/akills.htm
This appears to be a newly elaborated version of the common “compromised host” aKill. And it’s so informative and useful now, isn’t it? “Possibly causing a problem”! That’ll surely aid the hapless user in figuring out why he was aKilled!
The below stupidity, as seen in the powertech.dal.net MOTD, was pointed out to J’raxis on 2005-06-10 by jeian, one of #’s voices:
2002-07-01: We get overwhelmed by requests to add special access for LAN parties and small businesses running NAT (for the illiterate, if your IP address starts with 192.168. or 10., you are probably running NAT—and your personal freedom is severely restricted).
Please understand; our answer will always be no. It always has been, and it always will be. I will try to put this in simple terms; NAT (Network Address Translation) and similar “technologies” (masquerading, etc.) are detrimental to the Public Internet.
NAT destroys the end-to-end transparency of the Internet. If you do not understand this or the ramifications of this, please read up on it and make up your mind. It is a short-term, detrimental solution to a long-term problem which is most easily solved by using up all available IPv4 addresses as soon as possible to force a transition to IPv6.
Wow. So in other words, DALnet is denying users access to the network because one pinheaded IRCop has a political axe to grind with respect to the glacial rollout of IPv6. A user who wishes to connect from his office, who has no control over his company’s network policy, or a user on an apartment/dorm LAN who might not want to go blow a few hundred bucks buying extra IP addresses from his ISP, is denied access because some random IRCop doesn’t like NAT.
And this certainly helps to spread the “personal freedom” our dear IRCop here cares so much about, doesn’t it?
According to /LUSERS at the time of this writing, there were approximately 31,000 users connected to DALnet; back in its heyday before the massive packetings and server failures, there were over 100,000. Perhaps if DALnet wishes to attract users (beyond the packet kiddies and channel-filler bots that infest the network now) back to their network they can start by removing IRCops who aren’t fit to command power over a toaster oven, let alone a publicly accessible server on the “Public Internet [sic].”