View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005064||unreal||ircd||public||2018-01-28 20:36||2018-03-07 10:25|
|Platform||Unix||OS||Ubuntu||OS Version||16.04 LTS|
|Fixed in Version||4.0.18|
|Summary||0005064: 'set::cloak-method ip' not working properly with DNS resolving|
|Description||I had my network previously my network with set::options::dont-resolve (not resolving hostnames) to be able to give to my users a cloak in the format XXX.YYY.ZZZ.IP or XXX:YYY:ZZZ:IP (IPv4 or IPv6).|
But since UnrealIRCd 4.0.16, we have the option to enable DNS resolving and still allow the XXX.YYY.ZZZ.IP/XXX:YYY:ZZZ:IP cloaking format.
So, I've enabled DNS resolving in my network and used 'set::cloak-method ip' as explained here: https://www.unrealircd.org/docs/Set_block#set::cloak-method.
But I came across with one issue: different IP addresses are getting the same cloak, which didn't happened with set::options::dont-resolve enabled.
|Steps To Reproduce||Enable DNS resolving and use 'set::cloak-method ip' and you'll probably face the same issue I'm facing, if enough users connect to the network|
|Tags||bug, conf, host, ip, ipv6, ircd|
|3rd party modules||m_anti_amsg, m_auditorium, m_banfix_voice, m_block_masshighlight, m_chansno, m_denyban, m_netadmins, m_noinvite, m_pmlist, m_uniquemsg all of them made by Gottem (i don't really think that any of those affects the cloaking system)|
||Side note: I've set severity to major as this affects some extbans like '+b ~q:something' as some innocent users my be sharing the same cloak.|
||Thanks for the report. I'll take a look later this week.|
||Confirmed. It does not occur in a single-server scenario but does occur on multi-server for remote users.|
Remote users were all seen as IP 255.255.255.255 by the cloaking layer, resulting in the same cloaked IP. This has now been resolved by doing a recalculation once the IP has been set.
I could also have moved and duplicated code so it only has to be calculated once but that is dangerous as you have a NULL vhost for a short period of time which may cause crashes sooner or later. So went with the safe option of recalculating it...
|2018-01-28 20:36||PeGaSuS||New Issue|
|2018-01-28 20:36||PeGaSuS||Tag Attached: bug|
|2018-01-28 20:36||PeGaSuS||Tag Attached: conf|
|2018-01-28 20:36||PeGaSuS||Tag Attached: host|
|2018-01-28 20:36||PeGaSuS||Tag Attached: ip|
|2018-01-28 20:36||PeGaSuS||Tag Attached: ipv6|
|2018-01-28 20:36||PeGaSuS||Tag Attached: ircd|
|2018-01-28 20:39||PeGaSuS||Note Added: 0020017|
|2018-03-05 17:34||syzop||Note Added: 0020019|
|2018-03-07 10:08||syzop||Assigned To||=> syzop|
|2018-03-07 10:08||syzop||Status||new => confirmed|
|2018-03-07 10:08||syzop||Note Added: 0020039|
|2018-03-07 10:25||syzop||Status||confirmed => resolved|
|2018-03-07 10:25||syzop||Resolution||open => fixed|
|2018-03-07 10:25||syzop||Fixed in Version||=> 4.0.18|
|2018-03-07 10:25||syzop||Note Added: 0020040|