Table of Contents

DNS tricks for Omnia and knot-resolver

Adding custom configuration

Knot-resolver's configuration file is (re)generated from your settings, but you can add an additional file, put your changes inside, and include it by adding e.g. option include_config '/etc/kresd/custom.conf' into section 'kresd' of /etc/config/resolver.

Negative trust anchors

When a domain's DNSSEC causes problems, you often want to access it without turning of validation for other domains. At knot-resolver level this is simple config line, e.g.:

trust_anchors.negative = { '' }

Adding static address records

Extend section 'kresd' of /etc/config/resolver by

list hostname_config '/etc/hosts'

and fill that file in the usual format. You may of course use a different file, which is handy e.g. if you want some bindings only for the router's DNS and not served to other devices in the network.

Forwarding or not?

Knot-resolver upstream recommends to go without forwarding by default, assuming you want DNSSEC validation. It's more reliable and closer to how the protocol was originally meant. If it's a choice of forwarding to ISP's server or not, both with validation, I can't see a significant difference in security or privacy.

Security: signed records are validated either way, so no difference. Unsigned records go through similar paths either way, though there's possibly a small difference – which resolver implementation is more resilient to spoofing attempts from outside the ISP's network.

Privacy: all requests and answers go in cleartext either way. Outside the ISP's network the requests are seen with the resolver's IP, so in this sense forwarding may provide better privacy as requests of more users are sharing the same IP. On the other hand, forwarding probably makes it a tiny bit easier for the ISP to analyze where you connect to.

Speed: the difference is highly dependent on the particular network setup and the queries, IMHO. Note that local DNSSEC validation kills a part of the speed advantage of forwarding (maybe a significant one), because a single answer from a resolver won't contain all information to verify the whole chain from the root (or to verify that the chain is broken at some point and the record is correctly unsigned).