Cloaking rules also block MX and TXT records

[imol-ai]

THE TRACKER IS DEDICATED TO KEEPING TRACK OF BUGS, preferably after they have been already discussed and confirmed to be reproducible.

FOR ASSISTANCE, PLEASE CLOSE THIS FORM AND USE THE DISCUSSIONS SECTION INSTEAD: https://github.com/DNSCrypt/dnscrypt-proxy/discussions/categories/q-a

Reported bugs must reproducible in the context described in the "Context" section.

Installation and configuration issues are not bugs, but individual assistance request.

Context: the LATEST version of `dnscrypt-proxy` (precompiled binaries downloaded from this repository) is correctly installed and configured on your system, but something doesn't seem to produce the expected result.

If the bug is not trivial to reproduce on any platform, please include ALL the steps required to reliably duplicate it, on a vanilla, generic install of macOS, Windows, OpenBSD or Ubuntu Linux system, in their most current version.

If you don't have any clear understanding of the issue or can't enumerate the steps to reproduce it, open a discussion instead:
https://github.com/DNSCrypt/dnscrypt-proxy/discussions

## Output of the following commands:

./dnscrypt-proxy -version
2.1.5
./dnscrypt-proxy -check
[2024-07-17 05:20:09] [NOTICE] dnscrypt-proxy 2.1.5
[2024-07-17 05:20:09] [NOTICE] Service is not usable yet
[2024-07-17 05:20:09] [NOTICE] Resolving server host [raw.githubusercontent.com] using bootstrap resolvers over udp
[2024-07-17 05:20:09] [NOTICE] Source [public-resolvers] loaded
[2024-07-17 05:20:09] [NOTICE] Configuration successfully checked

./dnscrypt-proxy -resolve example.com
Resolving [example.com] using 127.0.0.1 port 53

Resolver      : 66.185.117.249 (res720.vie.rrdns.pch.net.)

Canonical name: example.com.

IPv4 addresses: 93.184.215.14
IPv6 addresses: 2606:2800:21f:cb07:6820:80da:af6b:8b2c

Name servers  : a.iana-servers.net., b.iana-servers.net.
DNSSEC signed : yes
Mail servers  : 1 mail servers found

HTTPS alias   : -
HTTPS info    : -

Host info     : -
TXT records   : v=spf1 -all, wgyf8z8cgvm2qmxpnbnldrcltvk4xqfn

- [ ] Initially raised as discussion #...

## *What* is affected by this bug?
Requesting MX or TXT records.

## *When* does this occur?
When requesting MX or TXT records.

## *Where* does it happen?
???

## *How* do we replicate the issue?
create cloaking rules for example.com: ''
  example.com 10.1.1.1
  example.com fd11:11
''
dig example.com MX and dig example.com TXT or host example.com return "this query has been blocked"

## Expected behavior (i.e. solution)
Defining A and AAAA records shouldn't block MX and TXT records.

## Other Comments

[jedisct1]

This is intentional.

If a name has been configured to be handled locally, I don't expect it to sometimes still send DNS requests to upstream servers.

dnscrypt-proxy is not meant to be used exclusively with web browsers. If I want to redirect a name to a local server, this includes emails.

Maybe that can be made configurable, but the current behavior is not going to change.

[imol-ai]

Thanks for the fast reply. For example, blocky solves this by adding a filterUnmappedTypes flag, which if set to false, doesn't block requests to MX, TXT, etc.

[jedisct1]

Yes, maybe we can introduce an option to set an explicitly list of record types that will be forwarded. So that people can prevent cloaking PTR records for example, although I can't find of any valid use case for this.