implement reserved domains properly

Best practice for local domains: https://tools.ietf.org/html/rfc6303#section-3 (we're close to that already)

assigned to @vkriz

This is candidate Vita as well as he got some experience with hints already :-)

changed milestone to %1.3.x

We'll need some larger redesign of the overall approach. Notes:

It's a bit painful that the hints module runs in produce phase whereas policy module runs in begin phase already. Therefore, reverse queries to local names get blocked before hints look at them. RFCs oblige us to block PTR queries to local IPs by default; this only motivates the users (e.g. on Omnia) to delete that rule, and all PTR queries then get through...

This is also related to whether policy/hint rules are supposed to be run only on incoming requests or also (1) on internal requests and (2) whenever following a CNAME. I think the begin phase isn't enough and we should extend the module API by a phase that's also ran on CNAME jumps (i.e. whenever a kr_query is started).

mentioned in merge request !325 (merged)

@vcunat If I understand this correctly, the problem you mentioned is tracked as #217 (closed) and can be addresses separatelly. Is that right?

removed milestone

The improved support is now merged; the two paragraphs in OP still apply, but I don't consider them too important.

The first one: it seems even questionable whether hints or policy should get precedence.

@vkriz Please make sure we did not break Omnia use-cases. I.e. we should recommend a configuration where hints actually work and PTR queries are answered from them.

We need to coordinate this with @jpavlinec as well.

added major usability labels

removed assignee

changed the description

removed major label

mentioned in merge request !573 (closed)

added major label

The default policy rules are not turned off for cases where a "policy" from view matches, and that's rather inconvenient at least in some use cases. We might consider some kind of unification of the two modules, as they really do very similar things.

Eww, there's a significant configuration inconvenience for the reserved names. The default rules are applied if no custom rule applies – that sounds good but it doesn't work well: the default way to configure forwarding is via policy.all(...), i.e. it keeps forwarding even the queries that should be served locally.

That's all made worse by the fact that those names get often "blocked" by the forwarder without providing a valid proof and by the fact that kresd doesn't cache BOGUS/SERVFAIL yet. Example consequence: very slow luci on Turris Omnia.

My long-term feeling from hints, policy, view, etc. is that we should try to design a completely new configuration approach for these matters, possibly a more declarative one.

The current approach doesn't seem to work well as it is. We're attempting to patch it with these defaults for locally-served zones, re-running on xNAME jumps, zone forwarding, and some issues from the thread above don't even have a proposal how to alleviate them.

I think the main advantage of the current approach is that it has relatively straightforward implementation and thus quite predictable behavior (in a sense) – it's just on a couple pages of relatively simple code – but it does not seem to match the way people usually think about DNS and what they want to do with it. (And the resulting patching will likely destroy the simplicity in time.)

@vcunat

The default rules are applied if no custom rule applies – that sounds good but it doesn't work well: the default way to configure forwarding is via policy.all(...), i.e. it keeps forwarding even the queries that should be served locally.

Funnily enough this is behavior which is expected by users who use forwarding and reverse zones at the same time. Typically in networks larger than single "home network" users have reverse zone hosted somewhere, and forwarding is expected to forward query up the chain until it reaches an authoritative response (be it STUB policy on end-of-chain forwarder or BIND which is recursive and authoritative at the same time).

If we removed this default behavior we would get ton of complains that "kresd is blocking queries when it should not" + we would have to invent a mechanism to declare what empty zones should be forwarded and what not ... This is a nightmare to manage.

Let me wonder out loud:

One problem is that private reverse zones cannot have sensible trust anchor for them, so one crazy options is to list them as negative trust anchors by default...
Looking at query 10.in-addr.arpa. DS, it has an insecure delegation in the public tree.
Maybe we should improve our the policy somehow so it does not catch DS queries and validation can work properly even if forwarding is happening. I.e. end-of-chain forwarder would return correct proof of non-existence for DS query + empty zone, which will not be validated anymore.

What do you think?

Well, not I realized that we have even more generic question: Should policy.suffix() apply to DS queries as well? I'm not sure, maybe we should have a switch to change this behavior like `policy.suffix({}, true) or something.

We patched the behavior and that fixed some use cases while slightly breaking others. The forward-all rule seems that typically should be the last one, after any other custom rules and also after these "reserved domains". The least hacky config for current kresd I see would be:

table.insert(policy.special_names, { count = 0, cb = policy.all(
    policy.TLS_FORWARD({ -- or FORWARD or STUB (the same way)
        -- list of servers
    })
)})

Right, DS semantically belongs one level higher than indicated by its owner, so perhaps we should change the defaults.

For people wanting reverse mappings in their LAN I currently recommend to add

policy.add(policy.suffix(policy.PASS, {todname('1.168.192.in-addr.arpa.')}))

(adapted to your address range) Perhaps Turris could add this rule automatically, but I don't know... this case is just wrong and I can't see a good simple solution, as we currently can only evaluate hints after policy.

It's unfortunate that aggressive caching won't work here, as that would mostly solve the issues. For example, 168.192.in-addr.arpa is served as an empty unsigned zone, and we don't really implement RFC 8020 for unsigned names, so only exactly matched names get answered from cache (and the served TTL isn't long).

mentioned in issue #535

For reference, this special_names hack stopped working since kresd 4.3.0, due to an optimization.

Note for #535 and other systematic changes: We probably need two versions of special handling:

forward-only-after-special-name-processing - suitable for forwarding to public resolvers (or generally resolvers outside of local network)
forward-without-special-name-processing - suitable when forwarding inside internal network - NXDOMAIN generation etc. should be done at the end of forwarding chain (e.g. the reverse zone might actually exist on the remote server)

What is the expected behavior when querying Knot Resolver for "localhost"? With a pretty plain configuration, I receive:

Query and response:

[jon@fedora ~]$ drill localhost @127.0.0.1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 14789
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; localhost.	IN	A

;; ANSWER SECTION:
localhost.	900	IN	A	127.0.0.1

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 1 msec
;; SERVER: 127.0.0.1
;; WHEN: Wed Dec  8 22:25:42 2021
;; MSG SIZE  rcvd: 43

I don't have a localhost entry defined in the hosts file that kresd is configured to load (hosts.kresd). Is this expected default behavior? As you can see in the configuration below I was exploring ways to ensure NXDOMAIN is returned instead of 127.0.0.1.

Configuration:

-- vim:syntax=lua:set ts=4 sw=4:
-- Refer to manual: https://knot-resolver.readthedocs.org/en/stable/

-- Listen for udp/tcp on all interfaces
net.listen('0.0.0.0', 53, { kind = 'dns', freebind = true })
net.listen('::', 53, { kind = 'dns', freebind = true })

-- Listen for DoT on all interfaces
net.listen('0.0.0.0', 853, { kind = 'tls', freebind = true })
net.listen('::', 853, { kind = 'tls', freebind = true })

-- Load useful modules
modules = {
        'hints > iterate',       -- Load /etc/hosts and allow custom root hints
        'stats',                 -- Track internal statistics
        'predict',               -- Prefetch expiring/frequent records
}

-- Load local host definitions
hints.config('/etc/knot-resolver/hosts.kresd')

-- Don't resolve localhost
--policy.add(policy.suffix(policy.DENY, {todname('localhost.')}))

-- Load local RPZ blocklist
policy.add(
    policy.rpz(policy.DENY_MSG('Domain blocked by local resolver policy'),
               '/etc/knot-resolver/blocklist.rpz',
               true))

-- Cache size
cache.size = 2 * GB

Yes, that's expected. Resolvers SHOULD generate immediate positive response to localhost. A/AAAA queries, by default. You can override that with usual policy tools, e.g. that RPZ or the line you commented out. (DNS clients or libs might expand it themselves before asking a resolver, but that's another matter. The linked RFC requires it for them as well.)

I believe this can be closed now. See #535 (comment 295494)

closed

implement reserved domains properly

Child items 0

Activity

Query and response:

Configuration:

Admin message

implement reserved domains properly

Activity

Query and response:

Configuration: