Conditional Forwarder Zone does not forward TXT records that start with underscore _

[tziuhtli]

I am unsure if this is a bug and I should post this as an issue, or if I just not have the correct configuration on my Technitium instance.

Problem

Technitium does not seem to forward TXT records that start with an underscore. For example:

dig @technitium.local TXT _acme-challenge.mydomain.com

will not return the TXT record, but

dig @1.1.1.1 TXT _acme-challenge.mydomain.com

will return the txt record. I have been prepending both commands with watch side-by-side.

Setup

1. Install new instance.
2. Configure it to be a recursive resolver (not sure if relevant).
3. Create conditional forward zone for mydomain.com
4. Configure the FWD record for @ with forwarder: Use "This Server".
5. Create a TXT record upstream (I'm using cloudflare) that starts with underscore, e.g. _test TXT "hello"
6. Run both dig commands above.

• technitium does not resolve.
• cloudflare resolves.

On the other hand, if the TXT record does not start with underscore, there is no problem.

help (?)

In reality I'm trying to set up the ACME DNS-01 challenge, and _acme-challenge.mydomain.com records are failing to resolve.

[ShreyasZare]

Thanks for the post. I tried the steps you have provided and not able to reproduce the issue. Its working very well here.

I would suggest that you share a screenshot of the zone to show all records. You can also export the zone and share the records in text format instead of screenshot.

I would also recommend that you use the built in DNS Client tool on the admin panel to do these tests and share the complete output you see in there for both the This Server and Cloudflare tests.

[tziuhtli]

Thanks for the reply and for taking the time to look at this.

I ran the DNS queries using the client tool and I discovered something else. When using "This Server {this-server}" and "Recursive Query {recursive-resolver}", a (newly created) TXT record starting with underscore created in cloudflare resolves just fine. But when selecting "System DNS {system-dns}" it doesn't resolve. Here is the output:

{
  "Metadata": {
    "NameServer": "127.0.0.11",
    "Protocol": "Udp",
    "DatagramSize": "107 bytes",
    "RoundTripTime": "1.64 ms"
  },
  "EDNS": {
    "UdpPayloadSize": 1232,
    "ExtendedRCODE": "NoError",
    "Version": 0,
    "Flags": "None",
    "Options": []
  },
  "Identifier": 0,
  "IsResponse": true,
  "OPCODE": "StandardQuery",
  "AuthoritativeAnswer": false,
  "Truncation": false,
  "RecursionDesired": true,
  "RecursionAvailable": true,
  "Z": 0,
  "AuthenticData": false,
  "CheckingDisabled": false,
  "RCODE": "NoError",
  "QDCOUNT": 1,
  "ANCOUNT": 0,
  "NSCOUNT": 1,
  "ARCOUNT": 1,
  "Question": [
    {
      "Name": "_test.mydomain.com",   ### obfuscated :)
      "Type": "TXT",
      "Class": "IN"
    }
  ],
  "Answer": [],
  "Authority": [
    {
      "Name": "mydomain.com",    ### obfuscated
      "Type": "SOA",
      "Class": "IN",
      "TTL": "1416 (23m36s)",
      "RDLENGTH": "50 bytes",
      "RDATA": {
        "PrimaryNameServer": "xxxx.ns.cloudflare.com",  ### obfuscated
        "ResponsiblePerson": "dns@cloudflare.com",
        "Serial": 2409311188,
        "Refresh": "10000 (2h46m40s)",
        "Retry": "2400 (40m)",
        "Expire": "604800 (1w)",
        "Minimum": "1800 (30m)"
      },
      "DnssecStatus": "Disabled"
    }
  ],
  "Additional": [
    {
      "Name": "",
      "Type": "OPT",
      "Class": "1232",
      "TTL": "0 (0s)",
      "RDLENGTH": "0 bytes",
      "RDATA": {
        "Options": []
      },
      "DnssecStatus": "Disabled"
    }
  ]
}

Also, here is the forward zone.

$ORIGIN mydomain.com.
@                     0         IN  SOA           technitium.local. invalid. 12 900 300 604800 900
@                     0         IN  FWD           Udp "this-server" True DefaultProxy 0

When a (newly created) TXT record does not start with underscore, there all three "This Server {this-server}", "Recursive Query {recursive-resolver}" and "System DNS {system-dns}" include the txt data in the answer section.

"Answer": [
    {
      "Name": "_test.mydomain.com",      ### obfuscated
      "Type": "TXT",
      "Class": "IN",
      "TTL": "300 (5m)",
      "RDLENGTH": "5 bytes",
      "RDATA": {
        "Text": "hello world!",
        "CharacterStrings": [
          "hello world!"
        ]
      },
      "DnssecStatus": "Disabled"
    }
  ],

I think there is something I don't understand entirely, but my guess is that my problem is related to a propagation issue into the System DNS. Ultimately, this affects the rest of the clients in my local network.

--- some minutes later

I waited a bit and tried the test again without deleting the records. Now "System DNS {system-dns}" resolves it too. But, this slow propagation into the System DNS is making my DNS-01 acme challenges fail. So, any further advice is appreciated.

The dig commands keep failing to resolve regardless of this tests. I'm quite puzzled by this.

[ShreyasZare]

Thanks for the details. The System DNS option is whatever DNS you have configured on the system's network adapter. It has no relation with Technitium DNS Server. It could be that the system DNS is some stub resolver on the same system and it has data cached for the domain name and takes a while for the data in cache to expire so that it returns expected response.

Since you are getting correct response with This Server, the DNS server is working as expected.

The "Recursive Resolver" option is not really part of the DNS Server but part of the DNS Client tool. This option uses the same recursive resolver codebase to resolve the domain name just like the DNS server does it internally.

[tziuhtli]

Alright, I spent some more time trying to figure out what is happening. I think I misdiagnosed myself in my first post. I am now able to reproduce the issue I'm having consistently. Here is what (I think) I know.

• The problem is the cache of empty TXT records (?).
• Underscores are irrelevant (as they should!).
• I had the forwarder turned on too, which contributed to the issue of propagation. But, I tried testing with (forwarding & recursiveness), with (no forwarding & recursiveness), with (forwarding & no recursiveness). It was all reproducible as below.

---

To reproduce:

1. Run the dig command on a non-existent TXT record.
2. Create a TXT record upstream. I'm using cloudflare.
3. Run the dig command again, and again, and again....

• The TXT record does not appear.

In technitium's cache browser, I can see the response for the TXT record is empty, it includes the SOA record, and it has a TTL of 30m. <---------

Below is an example of the cache for foo.mydomain.com after step 1.

[
  {
    "name": "foo.mydomain.com",
    "type": "TXT",
    "ttl": "1601 (26m41s)", <----------- 
    "rData": {
      "dataType": "DnsSpecialCacheRecordData",
      "data": "NegativeCache: NoError; mydomain.com.           1620      IN  SOA           xxxx.ns.cloudflare.com. dns.cloudflare.com. 2409342407 10000 2400 604800 1800, mydomain.com.           1620      IN  RRSIG         6 13 2 1800 1783946710 1783766710 34505 mydomain.com. xxxxxxxxx, foo.mydomain.com.       1620      IN  NSEC          \u0000.foo.mydomain.com. RRSIG NSEC NXNAME, foo.mydomain.com.       1620      IN  RRSIG         47 13 3 1800 1783946710 1783766710 34505 mydomain.com. xxxxxxxxx"
    },
    "dnssecStatus": "Unknown",
    "responseMetadata": {
      "nameServer": "dns.adguard-dns.com (94.140.14.14)",
      "protocol": "Udp",
      "datagramSize": "366 bytes",
      "roundTripTime": "5.26 ms"
    },
    "lastUsedOn": "2026-07-12T11:48:19.1292762Z"
  }
]

---

So, in the particular case of the ACME DNS-01 challenge, if the first request for the TXT record of _acme-challenge.mydomain.com happens to be empty because of propagation or timing issues, then it stays like that for 30 min in technitium's cache. The ACME DNS-01 challenge fails much earlier than that, after about 5 min.

---

Finally, something interesting is that when using the dns client tab in the web app, after step 1. above. I see the following:

For "Recursive Query {recursive-resolver}"

  "EDNS": {
    "UdpPayloadSize": 1232,
    "ExtendedRCODE": "NxDomain", <-------- expected :)
    "Version": 0,
    "Flags": "None",
    "Options": []
  },

For "This Server {this-server}" and "System DNS {system-dns}".

  "EDNS": {
    "UdpPayloadSize": 1232,
    "ExtendedRCODE": "NoError", <-------- comes from cache, right?
    "Version": 0,
    "Flags": "None",
    "Options": []
  },

is it ok that the ExtendedRCODE are not the same?

[ShreyasZare]

Thanks for the details. This is how DNS is expected to work. If you query the DNS server when no TXT record exists then that gets cached as a negative cache record. The time the data gets cached is what the zone tells the DNS server. So, in this case, your zone is configured to tell the DNS server to cache negative response for 30 mins.

Thus, you should avoid querying the DNS server before you attempt the DNS challenge.

The "Recursive Query" option is part of the DNS Client and has no relation to the DNS server itself. It uses the same codebase and resolves the domain recursively so you get the latest response from the name servers. While the "This Server" will query the DNS server and it is correctly answering data from its cache.

[tziuhtli]

Hey! thanks so much for your clear responses.

Unfortunately, I am not manually querying the DNS server. I use an ACME client which creates the TXT record and then looks for them to resolve the DNS-01 challenge. I think that the only solution for me is to tell the ACME client to query directly the authoritative name servers, without asking technitium at all.

I'll mark your latest reply as an answer.
Cheers!

[ShreyasZare]

You're welcome. All ACME clients provide an option to add a delay to verify the TXT record. This option exist precisely for this reason since if you add a TXT record on your primary name server, it may take a while for the secondary name servers to sync that record. Thus it prevents your local DNS resolver from caching a negative response when it queries a secondary name server which is yet to sync the TXT record from the primary name server.

I would suggest to add a delay of about 30 sec and see if that works. If not then increase it to say 1 min and test again.

[tziuhtli]

That solves my problem and keeps me from going around my internal technitium DNS server. Thanks again!

[ShreyasZare]

You're welcome!