Fetched sources are empty when leng is the host's nameserver

[negatethis]

I'm using the leng v1.7.0 NixOS module with flakes. Whenever the leng service restarts, it fetches the default block sources without any errors in the logs and places them in /var/lib/leng-sources. However, each of the files is empty. I tried again, this time changing sourcesStore to /mnt/leng/sources and adding that path to the systemd service ReadWritePaths option. The same thing happens. leng downloads the sources without any errors in the logs, but they are empty.

[cottand]

Hi @negatethis !

Thanks for reporting this. Unfortunately, I could not reproduce this. I tried starting a brand new VM (see its config at #90) and I can see lists being populated:

$  nix run '.#nixosConfigurations.aarch-darwin-leng-test.config.system.build.vm'
# ...
[root@nixos:~]# tail -n 100 /var/lib/leng-sources/gitlab.com.1.list
webtrendslive.com #WebTrends - Tracker
webvisor.com #Yandex - Tracker
webvisor.org #Yandex - Tracker
weekli.systems #Weekli - Advertising
wesmallproclaim.com #AdMeasures - Advertising
wgplayer.com #WG Player - Advertising
whairtoa.com #Unknown - Advertising
whiteinflammablejaws.com #AdMeasures - Advertising
who.nie.easebar.com #First Party - Tracker
whoisvisiting.com #Unknown - Tracker

...

I suspect some other setting in your NixOS config might have broken DNS resolution or internet connection, which in turn might prevent leng from fetching the sources. leng might not display any errors in this scenario if it is just stuck on a query that is not timing out.

It would be helpful if you could provide an example. Thank you!

[negatethis]

I suspect some other setting in your NixOS config might have broken DNS resolution or internet connection, which in turn might prevent leng from fetching the sources.

In that case, this may be related to issue #75. I'm using leng as my machine's only nameserver, so after leng restarts, there's likely no mechanism for DNS resolution while it tries to pull the sources. Also, I was mistaken that no errors appeared in the logs. I'm attaching a copy of the logs after restarting leng. At the end are these lines (I'm using Tailscale so 100.95.94.104 and100.100.100.100 both resolve to the same machine running leng):

leng-logs.txt

Mar 11 00:36:57 nixos leng[524840]: 00:36:57.887 DEBU resolver.go:44 ▶ 0f8 Lookup tcp, timeout: 5000, interval: 200, nameservers: [1.1.1.1:53 1.0.0.1:53], Using DoH: true
Mar 11 00:37:00 nixos leng[524840]: error downloading source: Get "https://gitlab.com/quidsup/notrack-blocklists/raw/master/notrack-blocklist.txt": dial tcp: lookup gitlab.com on 100.100.100.100:53: read udp 100.95.94.104:49935->100.100.100.100:53: i/o timeout
Mar 11 00:37:00 nixos leng[524840]: error downloading source: Get "https://sysctl.org/cameleon/hosts": dial tcp: lookup sysctl.org on 100.100.100.100:53: read udp 100.95.94.104:54990->100.100.100.100:53: i/o timeout
Mar 11 00:37:00 nixos leng[524840]: error downloading source: Get "https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt": dial tcp: lookup s3.amazonaws.com on 100.100.100.100:53: read udp 100.95.94.104:39753->100.100.100.100:53: i/o timeout
Mar 11 00:37:00 nixos leng[524840]: error downloading source: Get "https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt": dial tcp: lookup s3.amazonaws.com on 100.100.100.100:53: read udp 100.95.94.104:39753->100.100.100.100:53: i/o timeout
Mar 11 00:37:00 nixos leng[524840]: error downloading source: Get "https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts": dial tcp: lookup raw.githubusercontent.com on 100.100.100.100:53: read udp 100.95.94.104:52534->100.100.100.100:53: i/o timeout
Mar 11 00:37:00 nixos leng[524840]: 00:37:00.880 DEBU updater.go:106 ▶ 0f9 loading blocked domains from 1 locations...
Mar 11 00:37:00 nixos leng[524840]: 00:37:00.881 ERRO updater.go:111 ▶ 0fa directory sources not found, skipping
Mar 11 00:37:00 nixos leng[524840]: 00:37:00.881 DEBU updater.go:132 ▶ 0fb 0 domains loaded from sources

And this is my NixOS config:

{ config, ... }:
     
{
  services.leng = {
    enable = true;
    configuration = {
      bind = "0.0.0.0:53";
      api = "127.0.0.1:5300";
      blocking.sourcesStore = "/var/lib/leng-sources";
    };
  };
  networking.nameservers = [ "127.0.0.1" ];
} 

[cottand]

Thank you - can confirm I am seeing the same with that option.

The issue is due to leng looking up DNS in order to download blocklists query DoH upstream (which is enabled by default), effectively querying itself if you make leng your local nameserver.

An immediate fix for this is setting

services.leng.configuration.upstream.doh = "https://1.1.1.1/dns-query";

so that DoH does not require bootstrapping DNS. I have verified this work on my test environment.

I think it would also be a sane default change to use this address as the default DoH, as opposed to https://cloudflare-dns.com/dns-query. In the meantime, can you confirm this fixes it for you?

[negatethis]

Adding

services.leng.configuration.upstream.doh = "https://1.1.1.1/dns-query";

does fix downloading the block sources. However, now I've come upon another issue where leng is not loading the downloaded block lists.

Mar 11 22:50:12 nixos leng[564257]: 22:50:12.991 DEBU updater.go:106 ▶ 06a loading blocked domains from 1 locations...
Mar 11 22:50:12 nixos leng[564257]: 22:50:12.992 ERRO updater.go:111 ▶ 06b directory sources not found, skipping
Mar 11 22:50:12 nixos leng[564257]: 22:50:12.992 DEBU updater.go:132 ▶ 06c 0 domains loaded from sources

I thought that the issue may be blocking.sourcesdir being set to [ "./sources" ] by default, so I set it to [ "/var/lib/leng-sources" ], but then I get this error:

Mar 11 22:35:13 nixos leng[562476]: 22:35:13.789 DEBU updater.go:106 ▶ 052 loading blocked domains from 1 locations...
Mar 11 22:35:13 nixos leng[562476]: 22:35:13.789 CRIT updater.go:190 ▶ 053 error walking location error parsing hostfile error scanning hostfile: read /var/lib/leng-sources: is a directory

[cottand]

Thanks, this I could reproduce. You were right to add that directory to sourcedirs.

The problem was that sourcedirs did not know how to follow a symlink. I have added a fix for that in #93 which fixes it for me.

Can you confirm it works for you? If using flakes, it's github:cottand/leng/fix-follow-symlink

[negatethis]

I can confirm that #93 fixes the problem. Thanks a ton!