 |
 |
It seems that xrootd does a reverse DNS lookup rather early on a connection. In the case where the IP does not resolve AND takes a while about this (authoritative nameserver is down, several retries), this may lead to a denial-of-service. Perhaps there are ways to mitigate this (resolve via thread pool, do not resolve once threads are busy; do not resolve IPs for which a DNS request is outstanding etc)?
Actual case seen was EOSALICE being blocked by a handful of connections from the ALICE/CMS LCG Tier-2 in Kolkata (144.16.112.12) - logged connections per hour are ~100, i.e. roughly one per minute (other non-resolving IPs are logged at much higher rates). As a workaround, we have blocked that IP, this is not really a satisfactory situation for anybody involved.
We have not used the "nodnr" option, since the impact on other parts of the system (binding certain auth types to machines, or EOS-internal per-diskserver statekeeping are not understood). We are running a caching nameserver locally, but this does not help.
—
Reply to this email directly or view it on GitHub.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1