User hostname lookup fails if both AAAA and A DNS records exist for a hostname
HubbeKing opened this issue · comments
When I migrated my server from Vultr to DigitalOcean I also started managing my domain's DNS records through DigitalOcean, and added both AAAA and A records for the same hostname.
This meant that a DNS lookup on hubbe.club returned both an IPv6 and an IPv4 address.
However, txircd apparently got confused by this, and where I used to be properly detected as hubbe@hubbe.club, I was now hubbe@{IPv4 IP} instead.
Removing the AAAA record for hubbe.club resolved the issue, and I was now properly signed on as hubbe@hubbe.club again.
Thus, it seems that txircd somehow gets confused during hostname resolution if it finds both an IPv6 and an IPv4 address for the same hostname.
Had StarlitGhost test the same thing, and she is now also properly detected as SG@starlitghost.xyz, after having removed her AAAA record for starlitghost.xyz
Unsure if this is only an issue with DigitalOcean's DNS nameservers, or if it's also a problem with other providers. Should be easy to test if that's the case, since having both A and AAAA records for the same domain/hostname is fairly common.
I still have the AAAA record, but I changed it to no longer match the A record. It is now ipv6.starlitghost.xyz
Presumably this is an issue with the DNS anti-spoof check. We try to resolve the hostname from the IP and then look up the hostname to make sure it matches that IP. If txircd sees a different IP than the DNS resolver returns, it treats that as a failed DNS lookup.
Should be fixed by 0ed2fd6. This is live on the testnet now, so please give it a quick test.
Tested and it works!
Could we cherrypick that onto 0.4?
Not easily. It piggybacks on the IP-object changes I made, but those don't exist in py2.
I could maybe remake it in 0.4 if we really need it.
I'm trying to get 0.5 done pretty soon, so I'm going to go ahead and close this. If you think we really urgently need this in 0.4, let me know and we can reopen and port.