How does hostname spoofing/customization work on IRC networks?
There are two types of "vhosts": real and fake.
Real vhosts are usually called "reverse DNS" (also called rDNS)—it's basically a DNS record for your IP address, pointing to some domain name with a PTR
record, which is looked up by the server upon connection (be it ircd
, httpd
, or anything else). This is the "Looking up your hostname..." notice you see immediately after connecting to IRC.
If a user connects from 2001:db8::42
, for example, a DNS lookup is performed for 2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
. If the user connected from 192.0.2.123
, the equivalent DNS name will be 123.2.0.192.in-addr.arpa.
. The reverse DNS can be changed by whoever controls the IP address block. If you have a single IPv4 address for your home network, you usually have to annoy your ISP to get the rDNS changed.
To avoid spoofing, an ircd
(the IRC server program) will compare reverse and forward DNS—that is, it will make sure your rDNS hostname points back to your IP address—before displaying it to other users.
For those who are unable to change their real rDNS, most IRC networks offer "virtual hosts" or "cloaks".
Almost every IRC daemon has the ability to change user's displayed hostname at any time; usually this is restricted to operators, or even to services. For example, with the IRC command /chghost joeuser joes-fake-hostname.net
(assuming sufficient privileges).
On most networks this process is automated by services—once an operator assigns you a vhost (cloak), you get it set every time you identify to your services account.
(I'm saying "services", not "NickServ" or "HostServ", because most of the time it is a single program presenting itself as all of the *Servs.)
If the server is using IRC services (Anope, Atheme, etc.), there is usually a V-Host service, usually named 'HostServ' or a variant thereof.
Most servers running this type of service allow users to specify their own v-host (virtual host).
A typical IRC network consists of several pieces of software working together. First, there is the daemon, which controls connections, binding to specific ports, etc. Most networks run some type of software known as 'services' to handle channel registration, nickname registration, etc.
Part of the most common services software is a service called (usually) HostServ. On the IRC server, do '/whois HostServ' and see if there's a user by that name. You may also want to find a IRC Operator (usually a channel for help) and ask them.
you are trying to use your custom hostname instead of the fixed one. This is possible on some networks and many people contracts some bouncer services to do so.
Since time ago, IRC networks are implementing the "hidden hostname" or "custom vhost" which has two main points: - Hide you real hostname to prevent any DoS/DDoS from anyone to you - Hide spam hostnames
If the network has that policy you cannot do anything. They saves the "real hostname" and the "faked hostname/vhost" on a internal data structure and only propagates the faked one. The real is used when checking bans, k-lines, etc.
Oh! Another line of defense is checking your reverse DNS. If you have an A record pointing to 10.1.1.1 with "test.example.tld" as hostname, "test.example.tld" must resolv to "10.0.0.1" using a PTR record. Some servers may deny your connection or kill you if that check is not satisfied.
So you can report your hostname as being anything. But since that is true, pretty much no-one pays attention to that, and instead they reverse-resolve your IP address to a hostname, and use that.
To affect the hostname on these systems, you need to have control over what your IP address reverse resolves to. Typically that means you need to have a very friendly ISP and a static IP address, control over a large block of IP addresses, or...?
Reverse resolution uses the DNS system to resolve IP addresses by first reversing them (placing most significant portion last, as the DNS system does) and tacking on in-addr.arpa to the end before resolving them. Thus 198.82.183.54 becomes 54.183.82.198.in-addr.arpa. Then it is resolved normally to a PTR record pointing to the "correct" hostname.
Of course, the vhost / etc. options are much easier if you have them available.