CoreDNS / ZTE - Can it do allow list only for domains and block everything else?

Jim Coogan

Hi, exciting work being done here. I wanted to clarify if I am missing something on a huge use case for me which would be to setup CoreDNS rules saying certain clients can only access certain domains and nothing else.

This is similar to current firewall rules using destination alias but solving the problem where the clients actual DNS responses don't perfectly align with what the alias table stores for alias domains when it updates every x minutes. ie a client tries to reach a valid IP for the domain but it fails because it doesn't match IPs alias saved when it last updated 10 minutes ago.

From looking at it it seems this use case isn't really intended with Zero Trust Egress, at least so far?

It doesn't seem like this in anyway impacts the traditional firewall alias table so best I could tell is maybe using the CoreDNS group Forwards section as the allow group and have only that get a valid upstream resolver and then set the Group DNS server to an invalid one that will always fail so things have to match in Forwards section to get tagged for egress allowed. This would be a bit janky though.

Lastly, feature request if allow list only egress did become a feature- it would be so incredibly useful to have built in DNS query logging per client that could be enabled with viewable results that can easily transferred into an allow or block list. With aliases, I currently use tcpdump but is quite tedious and a much smaller window of watching than I'd prefer.

Thanks and keep up the great work.

jimp

You should be able to do that with ZTE without entering anything invalid.

Add a group to match you and other trusted clients that can go anywhere, add DNS servers, set it to forward * and disable "allow fallback" -- this makes sure you can still resolve.
Set the default group to block everything (Blocklist entry for *)
Make a new group to match the restricted clients, add one or more DNS servers, add only what you want them to resolve under forwards (e.g. *.example.com)
Enable "allow fallback" on the restricted group(s).

When someone in the restricted group tries to resolve, if it matches your forward list entries it'll forward and resolve. If it doesn't match it will fall back to the default group and be blocked.

There's an open request already for logging, so that's in the works, but no ETA.

Jim Coogan

@jimp Thanks for the reply and looking into this.

Messed around with this some more and it seems the key is that on the CoreDNS group for restricted clients you have to not define a DNS server. That way only the domains under FW get resolved. Otherwise if the group has a specified DNS server than everything gets resolved that isn't explicitly blocked. With this setup I also do not need to rely on the fallback to default.

However, I have only been able to prove this from a DNS resolution standpoint because for some reason it seems like the traffic is not getting tagged with coredns_allow because my corresponding firewall rule for allowing the traffic does not match and I have checked it 5 times to ensure the rule is correct.

It is basically allow TCP/UDP ANY ANY ANY ANY tagged:coredns_allow on the interface of the client in question. ZERO TRUST EGRESS is enabled and the client can only resolve the domains I put in group forward section and the IPs I get from a dig are exactly the same that curl then tries in my test.
@264 pass in log quick on igc2.60 inet proto tcp from 192.168.77.41 to any flags S/SA keep state (if-bound) label "id=1788994054" label "tags=user_rule" label "descr=[COREDNS] allow coredns allowed internet hosts" ridentifier 1788994054 tagged coredns_allow

Ultimately the firewall logs for the test traffic show it match for default deny on the interface. Seems to be quite similar to issue reported here https://forum.netgate.com/topic/201102/zero-trust-egress-with-coredns-can-t-get-it-working/

On another note, I had not fully considered one downside of using coreDNS allow listing like this which is that inheirently the firewall rules have to allow anything tagged coredns_allow so all clients subject to this, at least within the same group, end up being allowed to access all of the same domains.

Not the end of the world, but I guess what Im really looking for as a feature request is CoreDNS backed aliases that could be used in firewall rules which hopefully this lays the ground work for someday.

In the meantime I am still curious to get the tagged allow rules working like they are supposed to now.

Running 26.07-RELEASE (amd64) on Netgate 4200.