View Issue Details

IDProjectCategoryView StatusLast Update
0005064unrealircdpublic2018-03-07 10:25
ReporterPeGaSuS Assigned Tosyzop  
Status resolvedResolutionfixed 
PlatformUnixOSUbuntuOS Version16.04 LTS
Product Version4.0.17 
Fixed in Version4.0.18 
Summary0005064: 'set::cloak-method ip' not working properly with DNS resolving
DescriptionI 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:
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 ReproduceEnable 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
Tagsbug, conf, host, ip, ipv6, ircd
3rd party modulesm_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)



2018-01-28 20:39

reporter   ~0020017

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.


2018-03-05 17:34

administrator   ~0020019

Thanks for the report. I'll take a look later this week.


2018-03-07 10:08

administrator   ~0020039

Confirmed. It does not occur in a single-server scenario but does occur on multi-server for remote users.


2018-03-07 10:25

administrator   ~0020040

Remote users were all seen as IP 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...

Issue History

Date Modified Username Field Change
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