Knot resolver with local fqdn hostnames

Hello, this is my first post!

I’ve recently changed my Netgear Nighthawk R7800 (openwrt on it) with a Turris Omnia 6 router and I’m pretty satisfied so far with it.

One doubt that came up yesterday is how to use local fqdn in knot-resolver? In my old setup I just added them in the hostnames list and done. I try to use the same approach in the new router and, to be honest, it took me some a while to find out that the dns in dnsmasq was disabled.

There is a wiki document about it but without an actual solution:

Welcome :slight_smile:

Take a look at this page:

1 Like

The names you set up via luci should appear as hostname.lan I think. The suffix is overridable in reForis/DNS.

Hmm, sorry for my previous post. -ENOTENOUGHCOFFEE :slight_smile:

I’ll try the solution from @protree. Thanks!

As a suggestion, maybe a feature that makes knot resolver read the content from the Hostnames list.

If you mean /etc/hosts and similar, that’s also described in the linked article.

I’m also having issues resolving local hostnames; I’ve taken a look at the links above but they don’t address my issue.

(To avoid off-topic discussion, I’m using as my TLD because RFC 8375 explicitly creates for this purpose and RFC 6762 explicitly discourages the use of .local. as a private TLD.)

reForis config:


config resolver 'kresd'
        option rundir '/tmp/kresd'
        option log_stderr '1'
        option log_stdout '1'
        option keep_cache '1'
        list rpz_file '/etc/kresd/adb_list.overall'
        list hostname_config '/tmp/testhosts'


modules = {
    'hints > iterate'
  , 'policy'
  , 'stats'
  , predict = { window = 0, period = 0 }
policy.add(policy.rpz(policy.DENY, '/etc/kresd/adb_list.overall'))
net.listen('', 53, { kind = 'dns' })
net.listen('',   853, { kind = 'tls' })
net.listen('::', 53, { kind = 'dns' })
net.listen('::',   853, { kind = 'tls' })


Looking up the test host works fine:

; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44671
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


However, looking up my actual hosts does not:

; <<>> DiG 9.18.12-0ubuntu0.22.04.1-Ubuntu <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35765
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; AUTHORITY SECTION:    10800   IN  SOA nobody.invalid. 1 3600 1200 604800 10800

explanation.invalid.    10800   IN  TXT "Blocking is mandated by standards, see references on"

I’m running TOS 6.3.2, kernel 5.15.96, kresd 5.6.0

If I’m understanding correctly, you block the resolution of any queries here, and this has been an issue for years with no update?

For what it’s worth I tried adding a custom policy to allow queries but they seemed to be sent out to the internet without looking at the hints file.

1 Like

I see, thanks and I’m sorry for the trouble.

I suggested unblocking in Local name resolving not working if using '' DNS suffix for LAN - #2 by vcunat but it was a mistake not to really test it, as the hints module has an unexpected bug blocking any **.arpa forward hints (trying just reverse ones).

So, if you want just explicitly listed data for *, for the short-term I’d suggest this simple workaround:

  • in /etc/config/resolver, section config resolver 'kresd' you add a line
    list rpz_file '/etc/some/file.rpz'
  • you fill that file with lines in standard zone format, e.g. A
  • other changes should be unnecessary (custom policies or anything)

OK, the bug is simple, so let me fix it: hints: fix names inside (!1406) · Merge requests · Knot projects / Knot Resolver · GitLab

Nothing’s got posted on that issue ticket yet, but many weeks have been spent on designing and implementing a new approach to policies, hints, forwarding and configuration (from scratch, basically). Right now it’s in something like an alpha stage and we’ll soon be inviting people to test these new approaches to get feedback, but Turris most likely won’t be in the very first wave of that. (In the next couple months I don’t think we’ll be confident for more than opt-in testing, too.)

Thanks for this, I managed to finagle my DHCP leases into the right format and everything appears to be working now. That said, I am noticing a lot of latency when I try to resolve these addresses in a browser; do you have any idea why?

When I try to look up an address with dig or resolve it with ping it’s near-instantaneous, but I notice up to 5 seconds of latency between when I click on a link and when my page updates that goes away when I navigate by IP address.

For anyone in the future who needs this, you can use sed -E 's/([0-9\.]+) ([0-9a-zA-Z\.-]+)/\2. A \1/g' /tmp/dhcp.leases.dynamic > /etc/kresd/arpa_leases

I don’t know, off the top of my head. But if ping does it immediately… perhaps it gets delayed by IPv6 attempts?