The bug has been opened on https://bugs.launchpad.net/bugs/133894

"Binary package hint: xchat-gnome

I have set up the oftc network in xchat-gnome. The network list contains one server, irc.oftc.net. However, if I get disconnected, instead of retrying irc.oftc.net, it will try whichever alias it connected to, e.g. xenon.oftc.net. These do not resolve, and so it always fails. It will not try irc.oftc.net again, until i close that network and do IRC->Connect again.
...
This is an upgraded gutsy.

Note that the problem happens only if I *get* disconnected, not if I manually disconnect (i.e. right-clicking on the network and choosing "disconnect" does not cause the problem.) The way I am disconnected is generally by the wireless network dropping; it should be reproducible by disabling and re-enabling wireless, or by ifdown on a standard ethernet connection, or possibly by physically unplugging a wired ethernet connection.

To answer your question "if there's only one how they can try to connect to the other server", I don't know. It seems like it takes the server's host name ("Your host is xenon.oftc.net") and tries to reconnect to that.
...
I still have this problem. I have trouble getting x-chat to actually disconnect; if I ifdown it actually just lags forever (or at least a long time) until I reconnect. Once I do, the messages flow again, without disconnecting me from IRC. It might be that I simply need to wait longer; however, when the disconnect is unintentional, the disconnect happens immediately.

If you have the ability, it might be possible to duplicate by either powering of an access point, or simply roaming out of range of it.
...
No, no DNS configuration issues. The server's idea of its host name simply doesnt resolve. See http://www.zoneedit.com/lookup.html?host=xenon.oftc.net&type=A&server=&forward=Look+it+up for an example. The question is, why is xchat-gnome attempting to connect to a server name which is not in the network's list of servers?

Looking at the code, on line 780 of src/common/server.c it looks like it attempts to reconnect to serv->hostname. I debugged xchat-gnome, and found that, indeed, serv->hostname is set to the server's alias at reconnect time rather than being a resolvable host. At first I thought this was being set on line 1662 of the same file, but apparently not. After further examination, I think it's actually line 2872 of src/common/outbound.c Not sure though, it could be either place, or somewhere else entirely. There aren't a whole lot of places where serv->hostname is set though ( I think those are the only two)"