View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006428 | unreal | ircd | public | 2024-06-26 14:27 | 2024-09-23 12:56 |
| Reporter | BlackBishop | Assigned To | syzop | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Summary | 0006428: blacklist { url } support | ||||
| Description | Extend the support for the blacklist to support URL. This would allow services to use API calls to check external stuff. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
The blacklist { } block was designed so things like this could be added. It is the reason why the block is not called a dnsbl { } block by the way, because it is open to multiple methods. So I was initially positive about this request. But now I'm having serious second thoughts about this. The requests are quite "expensive". I mean it will work "just fine" in normal load situations and even slightly heavier load. But I already said, right from the beginning, that in high-peak-load situations the requests would be too slow and overwhelm the server. Think of attacks.... and isn't that EXACTLY the situation when you want your blacklist blocks to protect the server? I mean, sure, we can add such a warning in bold in the documentation. But what kind of signal is that? It's confusing to the admin and then.. what is the remaining use case. People could/would blame UnrealIRCd "it can't handle it" even though it is a design problem because such requests are so much more expensive than other things. In comparison: DNS is super cheap and so are data streams such as a bot on IRC or JSON-RPC with log.subscribe. I think it therefore it would be like adding a feature that only gets people into trouble (and ourselves). Now, there's a middle ground, which is what Central Blocklist does (for the same reason as described above). It looks at all the pending connections together that are happening in the past 1 second and then does 1 request to the HTTPS server that contains all the connecting users. So not 1 HTTPS request per connection, but 1 HTTPS request per second. Problem is it complicates things on the other end ("your side"). Because, since you have to reply back with one big response telling what to do with all the connecting users, you need all the subrequests/subprocessing to be finished before you can reply back to UnrealIRCd basically. I have that covered in Central Blocklist but it can be quite a hassle. I don't really like that middle ground either. I think in the end everyone would be better off with one of the other 3 solutions: DNS, an IRC bot or JSON-RPC. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-06-26 14:27 | BlackBishop | New Issue | |
| 2024-07-12 08:28 | syzop | Note Added: 0023257 | |
| 2024-09-23 12:56 | syzop | Assigned To | => syzop |
| 2024-09-23 12:56 | syzop | Status | new => closed |
| 2024-09-23 12:56 | syzop | Resolution | open => no change required |
