@dredmorbius @freakazoid @dch I can hear a lot of frustration :-| but it also sounds like although you suspect the problem to be kresd's config, you haven't proven that yet (or of course, you have done all that and just haven't told the fediverse that you've done it, because ... well, probably to avoid just the sort of distracting "trying to help without really knowing whats going on" conversations you're actually getting!) I suspect all of us in the conversation at the moment are also not specifically familiar with kresd either ...

Here's some pointers on how to suck eggs ...

Dump 100% of the DNS network traffic while you do an experiment, and analyse it to see if queries went to the places you expected, and had the correct questions & answers.

If the packets are encrypted, then strace the processes that should be handling the data; it won't tell you everything but it can really help.

Increase log levels to the max. Prove that you know why the things that work, work; then move on to the things that don't work.

kresd apparently uses a shared cache by default, which suggests that you can configure it to not do that, so you know every time you restart the process it has no knowledge of previous runs. This makes experiments much more possible.

Get a repeatable proof of the fault (e.g. "kresd config says do X, but observed behaviour is Y"), then you can fiddle with the config.

@dredmorbius @freakazoid @dch Reading the kresd documentation, you are hopefully looking at something like https://knot-resolver.readthedocs.io/en/stable/modules-policy.html#replacing-part-of-the-dns-tree ...

So, you need a DNS server that will return authoritative answers for the domains you wish to remap, let's call that {FakeDNS} ...

policy.add(
policy.suffix(
policy.STUB({FakeDNS}), policy.todnames({"youtube.com."})
)))

I think policy.STUB only works if there's a cache miss; i.e. make sure your cache is cleared before playing with this, otherwise the 'real' answer will arrive and this rule will be bypassed.

policy.FORWARD will be validating DNSSEC and you might not want to play that game. There's also RPZ, which I know too little about, but https://jpmens.net/2011/04/26/how-to-configure-your-bind-resolvers-to-lie-using-response-policy-zones-rpz/ @jpmens post might help you out.