Sonarr version 2.0.0.5085
Mono version 5.4.1
Arch Linux ARM
Short snippet of log follows:
|Newznab|DOGnzb https://api.dognzb.cr/api?t=tvsearch&cat=5030,5040&extended=1&apikey=(removed)&offset=0&limit=100 DNS Name Resolution Failure: 'api.dognzb.cr'|2:50pm
|Newznab|NZBCat https://nzb.cat/api?t=tvsearch&cat=5030,5040&extended=1&apikey=(removed)&offset=0&limit=100 DNS Name Resolution Failure: 'nzb.cat'|2:50pm
These entries continue to appear in the log until I test an indexer individually. I’m pretty sure the reason is that their servers are overloaded. Sometimes I am unable to access the indexers at first from a browser but they do come up. Their addresses can be pinged from a prompt.
It seems that Mono is caching the bad DNS replies. I have seen others with the same issue on the forum and on GitHub. Is there some way to clear the caches with a cron job? I leave my machine running 24x7 and only reboot for system updates. I am not running in a container, just a regular service. The machine connects through a VPN and I have a static /etc/resolv.conf
What is the best way to move forward with this? This seems to affect the usenet indexers the most. I have only occasional problems with torrent indexers.
Their server being overloaded wouldn’t cause DNS to fail to resolve and I doubt they run their own DNS servers.
Mono no longer caches DNS entries indefinitely, but if it did, simply testing the indexer in Sonarr wouldn’t work as it doesn’t do anything different than an RSS Sync or a search.
This sounds like a problem with your DNS server/config. The fact that usenet indexers seem to be affected more may come down to the record TTLs.
I changed my DNS to 8.8.8.8 and 8.8.4.4 to see if that’s the issue. It could well be that it’s something on my VPN provider’s end.
I’ll post more if I see more errors. If it is my VPN’s DNS servers (and I’m gathering that this is the issue here), I guess I’ll have to raise a ticket with them.
Okay I just had a DNS resolution problem with RARBG (torrentapi.org). From my main machine which connects to my regular ISP and its nameservers, I pinged the address and it didn’t resolve. I pinged google.com and it resolved. I pinged it again about 15 seconds later and RARBG resolved.
So maybe RARBG has some kind of DNS issue themselves? That’s not a subject I’m very familiar with but it seems like something weird is going on. I did not mistype the domain name – I checked it. And maybe by extension the other usenet indexers have issues, particularly DogNZB which Sonarr can’t resolve very frequently? But that’s a leap in logic.
Or could I have some kind of DNS issue internally with my network? Again, the query was run from my regular Fedora machine that is not behind a VPN, using my ISP’s name servers, not my VPN name servers. I would have tried querying with the machine behind the VPN but it was faster to do it on this one. And it did resolve the second time around.
I will check with the Sonarr machine if I am quick enough and this happens at another RSS sync.
Could be the record expired and your ISP’s DNS server didn’t update it/took a while to update it (though really that shouldn’t happen when there is a valid record to get). RARBG’s entry looks to have a TTL of 5 minutes, which isn’t too aggressive and really shouldn’t be a problem.
Personally I avoid my ISPs DNS, google does a better job (as do other public DNS servers), it seems ISPs setup DNS servers because they want their customers to have one available, but it’s not their focus.