DNS Resolver Design

When a program such as a web browser is instructed by the computer user to visit a web page, a lot happens "under the hood".

The browser (typically) provides the operating system with a name, and expects an address.

Let's say that, when this happens (dnsapi.dll in windows; query.c in reactos source code, function DnsQuery_A or DnsQuery_W), the name is checked against a "rule" file or registry setting.

The structure of that file might look like this:

Code:
Block host1.domain1.example.com
Block *.domain2.example.com
Log Block malware.domain.net
Allow *

This would work the way firewall rules typically work: the code checks the current requested name against each item on the list, going down, until it finds a match, at which point it follows the directions.

A "blocked" request could be returned some sort of "permission denied" error.

Overall, the goal is to give computer administrators greater control over DNS. Would it be useful? I would appreciate such functionality on my OS.

How difficult would this be to implement? I've looked into doing this on Windows, but as Windows is closed source, getting something like this to function reliably (hooking anyone?) seems difficult.
 
You typically don't want to filter this on the client but on the DNS server. That's basically how OpenDNS works.
 
It is possible to do something alike your example with the default DNS resolver on FreeBSD, unbound(8), see dns/void-zones-tools and https://github.com/cyclaero/void-zones-tools.

I didn't realize there was a DNS server available that could function this way. Cool!

However, this isn't perfect. I'd prefer the blocking happen in the operating system or the resolver if possible. I also don't like the use of NXDOMAIN, because that's technically not true: the domain does exist; we just don't have the administrator's permission to access it.
 
You typically don't want to filter this on the client but on the DNS server. That's basically how OpenDNS works.

You're right, typically such filtering would take place on the DNS server rather than the client. Certainly, from an administration perspective, it is more of a nightmare to try to control filtering on a decentralized vs a centralized system. And sure, you can force the use of a VPN for remote users, to get the security needed.

One advantage of doing things this way is the reduced network overhead (reduction of spurious DNS requests).
 
Going along with the idea of client vs server control of DNS:

Suppose multiple rule files were used, one for each user on the system (and one for the system itself). Now you've allowed controlling which users can make which DNS requests without having to modify DNS as a protocol.
 
... I'd prefer the blocking happen in the operating system or the resolver if possible. ...
Unbound can be installed and run as a daemon on client machines the same way as you would run it on a server. You would only need to point the DNS settings of the network interface to the loopback address 127.0.0.1.

... I also don't like the use of NXDOMAIN, because that's technically not true: the domain does exist; we just don't have the administrator's permission to access it.
Well, you need to take into account the DNS return codes which are defined by a bunch of RFC's, otherwise clients using your DNS resolver won't know what to do about special codes. For an exhaustive list of codes have a look at:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6
 
I think nsdispatch(3) (name-service switch dispatcher) is the code that I'd want to modify, which isn't technically part of the resolver; it is part of the FreeBSD operating system.

Am I barking up the right tree?
 
Back
Top