Incorrectly replacing remote `localhost` hostname peers with local hostname

[cherinyy]

qBittorrent & operating system versions

qBittorrent: 5.0.0beta1 Operating System: Windows 11 Pro for Workstations 23H2 x64 Qt: 6.6.2 Libtorrent: 2.0.11.0 Boost: 1.84.0 OpenSSL: 3.2.1 zlib: 1.3.1

What is the problem?

Some IPs have their PTR records set to localhost, and qBittorrent automatically replaces remote localhost hostname peers with local hostname.

For example localhost is replaced with Windows-PC which is the hostname I set for the device.

Steps to reproduce

1. Enable the ‘resolve user hostname’ option.

Additional context

> dig +short -x 183.216.123.142
localhost.

Log(s) & preferences file(s)

No response

[HanabishiRecca]

I reviewed some qBittorrent and Qt code, but haven't found any logic where that could happen. Maybe I missed something, but maybe this is a system-level quirk.

[mhoes]

I'm not exactly sure here, but my guess would be that yes, this is a OS / system-level phenomenon. 'hostname resolution' (determining what hostname belongs to a certain IP-address, or vice versa), is done via DNS on the (local) system running qbittorrent, and not by the (remote) peer. The name 'localhost' is reserved for (each) local system (meant to refer to itself), and is not supposed to be in DNS. Although I am fairly certain that it is not even allowed by the DNS specifications to do so, apparently some DNS server implementations allow you to set it to that value in DNS anyway. So what happens then is that (for example) the IP-address '183.216.123.142' gets resolved to 'localhost' by DNS, and then when you try to convert that back to an IP, the local system will find the locally reserved/defined name you have set for your system, and not the IP the remote peer has.

If this is correct, then to me, including 'localhost' in DNS is definitely breaking the specifications, and there really is not much you can do about that in the qbittorrent codebase, since how DNS functions is outside of qbittorrent's control. If you do not want this behaviour, I suggest you do not let qbittorrent do hostname resolution, and let it show the IP's instead of hostnames.

Just my 2$.

[HanabishiRecca]

I am fairly certain that it is not even allowed by the DNS specifications to do so

PTR is not the same thing as regular DNS. They serve no real functionality and work more like notes. So you are generally allowed to place any arbitrary string there iirc.

I suggest you do not let qbittorrent do hostname resolution, and let it show the IP's instead of hostnames.

Yeah, reverse lookup is a useless function at best. Or even harmful imo. Because:

1. You spam lookup requests, slowing down your system and the network in general. You could be banned by resolvers for that actually.
2. You see effectively garbage instead of real IPs. (I could see some script kiddy putting "I b**g your mom" there lol.)

[mhoes]

PTR is not the same thing as regular DNS. They serve no real functionality and work more like notes. So you are generally allowed to place any arbitrary string there iirc.

Actually, PTR records are a very real, regular', and 'normal' use of DNS, as they define the (formal) hostname that belongs to an IP. Setting that to 'localhost' is the equivalent of setting your IP in DNS to something like '127.0.0.1', and you will definitely break things when you do that.

Also, RFC 1912 explicitly states in section "2.1 Inconsistent, Missing, or Bad Data" that you must "Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain." and "Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all."