View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006306 | unreal | ircd | public | 2023-07-13 19:26 | 2023-10-11 19:05 |
| Reporter | BlackBishop | Assigned To | syzop | ||
| Priority | low | Severity | feature | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 6.1.2.3 | ||||
| Summary | 0006306: dnsbl timeout and order | ||||
| Description | We already talked about this, I know they're of low importance .. But I'd still want to keep them in mind - a timeout per dnsbl would help. I currently have a dnsbl that does some API checks in the background and takes a little bit long, those have quotas... Separating them in different dnsbl checks is possible but if one fails, there's no point on checking the others, this is where the order part would be useful. I imagine those not having an order id be parallel and unordered, those who do, be kept in order with an action (maybe depending on their answer? nvm... too much) | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
I agree with allow the DNS query timeout to be set on a per-DNSBL basis. While the global timeout may be fine for most of the DNSBLs; some DNSBLs may be laggy compared to others. For example, the DNSBL dnsblacklist.co.uk is hosted on a single Germany server, this server often has some high lookup times for my US servers, but it is a valuable DNSBL with a lot of good listings. On InspIRCd, I can set the timeout for this specific DNSBL higher than what my global timeout was and get more hits than before. |
|
|
Right, it seems we need a higher timeout option for blacklists indeed. It should be noted that we don't wait for the blacklists to timeout before allowing the user in. We start the blacklist checks once the incoming connection is opened, indeed all blacklists in parallel. Then, when the user client IP lookup is done (not the blacklist lookup), the ident lookup (if on) was finished, the USER/NICK/PASS/CAP sequence was finished, then the user will be allowed in EXCEPT there is MINIMUM time of set::handshake-delay which defaults to 2 seconds. That latter option is to give blacklists at least /some/ time or a head start to resolve, so fast DNSBL's like DroneBL can catch the user within 2 seconds. You can always set that higher if you want. And yeah, in the background, the blacklist DNS request still keeps on going even after those 2 seconds, if the user is fully connected, you could recognize it by a late kill/gline/.., unless that is not working right, then I apparently have some kind of bug in that area. So I think we could get away with just add one single DNSBL retry/timeout option to keep things easy. It would pretty much result in the same, as it doesn't matter if 1 of the DNSBL's doesn't need the longer timeout. Or, if that is not what you want, it would at least help you significantly ;) |
|
|
I think this should be helpful. As mentioned previously you don't need it per-dnsbl as it does not hurt anything to set it higher for all (see explanation in last comment). commit a04295c588b9fae2e1ae0669c6a86c29ce16de05 (HEAD -> unreal60_dev, origin/unreal60_dev, origin/HEAD) Author: Bram Matthys <[email protected]> Date: Wed Oct 11 18:56:12 2023 +0200 Add set::dns and increase DNS timeout for DNSBL (3000ms first, then on retry 6000ms). This is quite a bit higher than client DNS lookups (1500ms first, on retry 3000ms) and is because some DNSBL are reported to be quite a bit slower than ordinary DNS. (Maybe just some, but.. the higher timeout does not hurt anyone anyway) Note that all this has no effect on client handshake times, as DNSBL checks are done in the background. Only side-effect is that if we do get a "late hit" then you may now see a kill a few seconds after the client is online (which was actually already possible before too for quick clients, but.. yeah...) These settings can be overriden via set::dns, these are the defaults: set { dns { client { timeout 1500; retry 2; } dnsbl { timeout 3000; retry 2; } } } When you REHASH we will check if the values are different than the current c-ares settings and if so, reinitialize the resolver. Reinitializing the resolver will destroy outstanding DNS requests, eg DNS lookups for clients currently connecting, but so be it. Not a super-huge issue since changing this is rare. Requested by BlackBishop in https://bugs.unrealircd.org/view.php?id=6306 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-07-13 19:26 | syzop | New Issue | |
| 2023-07-13 19:26 | syzop | Issue generated from: 0006305 | |
| 2023-07-13 19:26 | syzop | Issue cloned: 0006307 | |
| 2023-07-13 19:27 | syzop | Reporter | syzop => BlackBishop |
| 2023-07-13 19:29 | syzop | Summary | Gline hit stats, big kline list, dnsbl timeout and order, skip from recheck? => dnsbl timeout and order |
| 2023-07-13 19:29 | syzop | Description Updated | |
| 2023-07-17 04:57 |
|
Note Added: 0022961 | |
| 2023-07-23 19:12 | syzop | Note Added: 0022976 | |
| 2023-07-23 19:12 | syzop | Status | new => acknowledged |
| 2023-07-23 19:14 | syzop | Note Edited: 0022976 | |
| 2023-10-11 19:05 | syzop | Assigned To | => syzop |
| 2023-10-11 19:05 | syzop | Status | acknowledged => resolved |
| 2023-10-11 19:05 | syzop | Resolution | open => fixed |
| 2023-10-11 19:05 | syzop | Fixed in Version | => 6.1.2.3 |
| 2023-10-11 19:05 | syzop | Note Added: 0023055 |
