DNSvizor - run your own DHCP and DNS MirageOS unikernel - gets some testing
2025-04-10TL;DR: We worked on testing the DNS layer, please let us know about strange DNS setups. You can also help us by sharing with us your dnsmasq configuration, so we can prioritize the configuration options to support.
Testing
As mentioned last year in our blog article, we are working on DNSvizor (repository).
We recently worked a lot on testing thereof. One part is unit testing for the pure API, and figuring out the coverage of our tests. This brings us quite some confidence in the behaviour - especially since we test as well the core functions "scrub" (which entries of a DNS reply to trust and use in our cache), and the cache itself (to avoid having loops in the lookup, even if there are cyclic scenarios).
Another layer we worked on is a Unix application that exposes the resolver code as a network service (code). This helps us to quickly compile and start this process and interact with common command-line utilities, such as dig or nslookup with it. The advantage over our DNSvizor unikernel is the quick edit, compile, run cycle.
DNS in the wild
As mentioned above, DNS out on the Internet may be wild - and we would like to avoid infinite resource consumption in our resolver - by checking for well-behavedness of constructions that may (or may not) exist in the wild. One construction are cycles, which we will go in more detail here.
Alias (CNAME) cycles
One way to have a cycle in DNS is using the alias (CNAME) entry, which expresses: instead of looking at this domain name, please look at the other one - i.e. "www.ocaml.org CNAME ocaml.org" would tell a DNS client that asked for "www.ocaml.org" to look for "ocaml.org" instead.
Now, there's nothing preventing us from adding an entry of the form "www.ocaml.org CNAME www.ocaml.org", and of course this should not lead to an infinite loop. A more complex construction is to use 2 (or n) entries: "www.ocaml.org CNAME www2.ocaml.org" and "www2.ocaml.org CNAME www.ocaml.org".
We fix this situation by constructing a set of domain names that we visited while looking for CNAME chains. And once we hit a cycle, we reply with the accumulated records.
Name server (NS) cycles
Another way is to use NS records and not providing additional data. So, one domain may specify their name server to be in a different zone ("ocaml.org NS ns.robur.coop"), and that other zone may specify a similar name server entry ("robur.coop NS ns.ocaml.org"). Now, if there's nothing more known, there is no chance to resolve either domain. In this case we used to have non-termination in our resolver code, which is fixed now.
Our fix for this situation is two-fold: we remove the cyclic record from our cache, and leave it to the resolver to request it again. In addition, our resolver has a limit of 30 DNS queries that is the maximum to be sent out for a single incoming DNS request. This means such a cycle will be detected and we will use up our 30 queries. It is related to the issue below (missing glue), since the DNS resolver may recover when it receives also some address glue.
Missing glue
A separate and related issue is if there's information about the name server for a domain which resides in the domain, and the address of that nameserver has a shorter time to live -- now while the information which name server to use may persist, the address may be out of the cache - and the only way to recover is asking the name servers responsible for the parent domain to share the name server and address information.
The address information is not authoritative, and only delivered in the additional section of the DNS reply. But it is crucial that this is delivered. Some domain registrars every now and then fail to deliver such additional information, which makes the domain then unresolvable.
Conclusion
DNSvizor provides DNS resolution and DHCP service for your network, and already exists :). Please report issues you encounter and questions you may have. Also, if you use dnsmasq, please show us your configuration.
If you're interested in MirageOS and using it in your domain, don't hesitate to reach out to us (via eMail: team@robur.coop) - we're keen to deploy MirageOS and find more domains where it is useful.
Our work is only partially funded, we cross-fund our work by commercial contracts and public (EU) funding. We are part of a non-profit company, you can make a (in the EU tax-deductible) donation (select "DONATION robur" in the dropdown menu), or sponsor us via the GitHub sponsor button.