View Issue Details

IDProjectCategoryView StatusLast Update
0006306unrealircdpublic2023-10-11 19:05
ReporterBlackBishop Assigned Tosyzop  
PrioritylowSeverityfeatureReproducibilityhave not tried
Status resolvedResolutionfixed 
Fixed in Version6.1.2.3 
Summary0006306: dnsbl timeout and order
DescriptionWe 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)
TagsNo tags attached.
3rd party modules



2023-07-17 04:57


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 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.


2023-07-23 19:12

administrator   ~0022976

Last edited: 2023-07-23 19:14

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 ;)


2023-10-11 19:05

administrator   ~0023055

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

Issue History

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 user7720 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 =>
2023-10-11 19:05 syzop Note Added: 0023055