Speaking only for myself, not any particular group... I've never really been happy with any of the hostmasking implementations I've seen so far. They all seem to have flaws in either mask effectiveness or usability. Hosts as used on IRC have a few useful properties. For one thing, they are set at connect and do not change; a client always has the same host for as long as it's online. This is a pretty fundamental assumption that makes everything from pretty client displays to access lists and scripting work. Another property is that hosts have a hierarchy, where certain parts may change for dynamically-assigned addresses while other parts remain static based on ISP or geographical location; this of course is what makes wildcard masks in access lists etc work. One usability flaw in most hostmasking implementations then is assigning it to a usermode. This means from the perspective of the client itself, its host on IRC is not static, as the mode (and thus its host) can be changed at any time. This breaks the assumption above and affects things as basic as automatic line breaks in channel or private message text. (A client that knows its own host length can calculate the maximum length of message text it can send before one server along the chain will truncate it, and can do its own line splitting to compensate.) It also affects other clients, as things like bot access lists and channel bans no longer apply properly, WATCH/MONITOR-generated notifications might not be correct for subscribing clients, etc. The most common workaround to this is for each server to fake quit/ reconnect the mask-changing client for the benefit of other clients, but whether they internally reevaluate channel bans or deal with WATCH etc appropriately is of course an open question. It's a rather fragile and kludgy practice. The proper way to handle masking is to do it on connect, and not allow the masked status to change during the session. I'll assume the goal of hostmasking is to replace the IRC-visible host with one that does not indicate the actual host the client is connecting from. Hash-based hostmasking, being derived from the client's actual host and therefore anonymous, usually has the secondary goal of maintaining at least a partial hierarchy. This allows channel bans and bot access lists to still cover a group of clients by ISP or region. I often see such masking implemented as hashing hostnames first. As pointed out by others, this is problematic because hostnames vary in the number of components and amount of information available in each component. What happens is that either not enough of the real host is hidden (so masking fails), or not enough of the hierarchy is preserved (so the secondary goal is not met). 10.1.2.3.city.state.isp.tld -> mask.1.2.3.city.state.isp.tld 10.1.2.3.city.state.isp.tld -> mask.isp.tld Hashing unresolved IP addresses is more useful due to the relative stability in number of components and amount of information revealed by each one. This is also a more important area to focus on because the effectiveness of a hash-based mask is decided here. Because the identifier space of an IPv4 address is so small in number- crunching terms, a fixed hash algorithm is easily applied in a brute- force manner to find the real host for a masked host (again mentioned by others). Fixed hash algorithms therefore do not meet the goal of hostmasking. The logical change is to use an algorithm that incorporates a secret known only to the server, which artificially increases the identifier space of the real host. This can entirely avoid the simple brute-force attack if properly implemented. (That last point is worth emphasizing, as I've obtained the secrets of more than one server simply by analyzing known masked hosts, because they used flawed algorithms.) However, there remains an issue with the secondary goal of maintaining a hierarchy: a mapping attack. A fundamental property of a hierarchical host is that parts of it remain static based on ISP or region. This means that for a hierarchical mask, parts of the mask remain the same, and so obtaining only one real host in the region effectively breaks part of the mask for all hosts in the same region. 5342.8743.2357.9026 -> 10.1.2.3 5342.8743.2357.1824 -> 10.1.2.something One counter-proposal to this is to periodically change keys, but that is simply a less-effective way of not having a hierarchy at all, as the fundamental property of portions being static is voilated. I'm not aware of any hash-based system that actually achieves the basic goal of hostmasking while still preserving hierarchy. It is an insecure combination by nature. Masks based on centrally-assigned identifiers are much more effective, since they cannot reveal part of the real host if they are not based on it. The most common implementation of this is on networks that register user accounts (instead of nicknames), where the user account name becomes the identifying part of the masked hostname. Since DALnet registers nicknames instead of user accounts, this approach doesn't seem directly useful. As mentioned by others, there are issues with simply changing nicks or identifying to different ones during a session, but there is also the point that nicknames can contain characters that are not appropriate for hostnames. Networks with user account registration typically only allow hostname- appropriate characters in account names. Perhaps this could be applied to DALnet by using a unique identifier mapped to email address instead. (*Not* a hash based on the actual address, just an identifier assigned internally.) While making the resulting hosts not as aesthetically pleasing, it sidesteps the valid character issue, and should narrow the abuse window to the same size as networks using user account registration (as they usually limit number of registrations per email address). Of course, most implementations of this tend to have two usability flaws: one being that masking is modifiable during the session; the other being that first a connection and then a roundtrip authentication to services is required before masking can be done at all. The result is that while the end mask is quite effective, there is a large window at the beginning of a session where it is entirely ineffective, and things like WATCH are left completely unprotected. Again, the proper way to handle masking is to do it immediately at the start of a session. Connecting clients give the server a nickname, a username, and optionally a password, so the information necessary to make the decision is already present from the client side. Another issue is that if masking is optional, then most people consider it desirable for server-side access lists (channel bans, SILENCE, etc) that contain entries based on real hosts to match even if a client is masked. However, that means those lists themselves can be used to perform mapping attacks, e.g. by CTCP PINGing a client repeatedly while modifying your own SILENCE list to see which address components block the response. Note that this works in real time regardless of the masking algorithm used. A logical way to avoid this is to make hostmasking non-optional and forget about real hosts entirely. -- Quension