Bind9 --> Lokinet DNS not working

[CyberPingU]

Hello all, I have lokinet installed on my border firewall (linux) with multiple interfaces (one's IP is 192.168.151.1):

My DNS is a bind9 server on a linux machine (IP 192.168.151.2) with a zone foward to gateway's resolver for .loki tlds. This is the bind9 block:

        zone "loki" {
                type forward;
                forward only;
                forwarders { 192.168.151.1;};
                };

        zone "snode" {
                type forward;
                forward only;
                forwarders { 192.168.151.1;};
                };

If I query bind9's port I get this:

$ host q5uwxdhttwne7rpz8e87r5gr3esbwn13hq7unf9p1gaqemueiz5o.snode  192.168.151.2
;; communications error to 192.168.151.2#53: timed out
Using domain server:
Name: 192.168.151.2
Address: 192.168.151.2#53
Aliases: 

Host q5uwxdhttwne7rpz8e87r5gr3esbwn13hq7unf9p1gaqemueiz5o.snode not found: 2(SERVFAIL)

For other domains it works, even if forwarded to a border DNS:

$ host www.google.it 192.168.151.2
Using domain server:
Name: 192.168.151.2
Address: 192.168.151.2#53
Aliases: 

www.google.it has address 142.250.179.227
www.google.it has IPv6 address 2a00:1450:4009:81d::2003

On the other hand if I query directly the gateway's lokinet DNS it answers:

$ host q5uwxdhttwne7rpz8e87r5gr3esbwn13hq7unf9p1gaqemueiz5o.snode  192.168.151.1
Using domain server:
Name: 192.168.151.1
Address: 192.168.151.1#53
Aliases: 

q5uwxdhttwne7rpz8e87r5gr3esbwn13hq7unf9p1gaqemueiz5o.snode has address 172.16.0.2
q5uwxdhttwne7rpz8e87r5gr3esbwn13hq7unf9p1gaqemueiz5o.snode name server localhost.loki.
q5uwxdhttwne7rpz8e87r5gr3esbwn13hq7unf9p1gaqemueiz5o.snode mail is handled by 1 q5uwxdhttwne7rpz8e87r5gr3esbwn13hq7unf9p1gaqemueiz5o.snode

How can I make Lokinet's bundled DNS answer even to forwarded queries by another DNS server (in this case bind9)?

[ainsly]

Not sure I can help much, but I ran into similar issues on macOS which I was able to resolve. My problem was that Lokinet macOS client was totally overriding all my DNS resolutions, even though my network/vpn management program, (far more powerful and configurable - Surge if you're interested but macOS & iOS only), was taking care of it and supposedly had full takeover.

But Lokinet was overriding that by having higher specificity due to the "Search Domains". I wrote a script to startup the (limited and in-configurable macOS client) and remove the dynamically created additions to my network setup created by Network Extension using scutil (mac only)

As far as I know, for the linux version which is ACTUALLY configurable, it sets the DNS resolver to 172.3.2.1 (or 127.0.0.1) - but you can easily check /etc/resolv.conf to see what it actually sets it to.

On my Mac the config it adds is (where the device ID is randomized on each launch):

I'm not familiar with bind9, is 192.168.151.1 where it's DNS resolver lies in order to provide a 'fake' DNS IP to forward to requests to? If so, judging by your example that actually worked, you could probably just replace 192.168.151.2 with 192.168.151.1 - or is it a lokinet thing.
I assume that would delegate any .loki or .snode domains to be handled by lokinet's DNS resolver.

If not you could try pointing it to the actual provider lokinet DNS provider at, think it's on linux 127.3.2.1. But I assume that would sidestep any rules (if any that bind9 would have)

The address 172.16.0.2 is the subnet created by lokinet which it pipes the DNS requests matching .loki/.snode to. All other domains get resolved by it's DNS resolver and returns an IP ready for use by the OS as usual.

This setup for me (even though I'm using macOS) was super troublesome, because since it handed back a resolved IP, it broke all my domain/protocol/process rules that I had in place for Surge and Little Snitch. So I had to sidestep that mess completely and simply use Surge to set the DNS resolver for loki/snode domains to 127.0.0.1 (not sure why on macOS it's not 127.3.2.1, but hey).

If bind9 is anything as powerful as dnscrypt-proxy, you should easily be able to do that, you'd just need to make sure that the DNS resolver IP is actually correct (ie. either 192.168.151.1 or 192.168.151.2, just have a fiddle).
I wouldn't ever try hardcode 192.168..... or 172.16.... since I read that lokinet just looks for unused local subnets for it to operate on.

I just started my lokinet client and was able to successfully run those host commands you posted (on Mac):

I can only assume that maybe the lokinet hadn't fully initialised it's pathways before running the failed query, hence the timeout.

ALTHOUGH, worth noting, that the lokinet DNS resolver DOES NOT resolve domains which are not .loki or .snode, which would explain why trying to resolve google.com using the lokinet DNS resolver failed - tested this myself.
So again - not familiar with bind9 or your set up, but if there's no backup DNS resolver after failing to resolve the loki/snode domains, then yes, it would fail.

You can check your /etc/rseolv.conf to view how your DNS resolution will be handled. No point in changing it though, because that file gets overwritten all the time when changes occur.

But somehow I've managed to successfully set up Surge (with no broken rulesets due to only having pre-resolved IPs [without the choice of resolver]) AND dnscrypt-proxy on my Mac in harmony, without a hitch. And Surge allows me to use the lokinet DNS resolver for loki/snode domains (much like dnscrypt-proxy also has the option, and seemingly bind9). Only thing I needed to change with dnscrypt-proxy was to listen to a different port, because the resolver runs on 127.0.0.1.

Anyway, check your lokinet config, might be a way to fix your issue. But note that lokinet DNS is ONLY supposed to handle loki/snode resolution, nothing else; so you may need to do some kind of re-ordering of resolvers or set up a backup resolver for them.

Let me know how it goes, would love to hear; or even if you just gave up on it