Search... ⌘ K
Get Started Contact Sales

How to Fix Empty Responses from Empty Non-Terminals

Last updated

Table of Contents

If you are experiencing unexpected empty responses for certain domain names, they might be caused by Empty Non-Terminals (ENTs). This guide walks you through the steps to identify and fix these issues.

Understanding the problem

An Empty Non-Terminal (ENT) is an intermediate domain name that exists only because it is a path to a deeper name, but has no records of its own. When you query an ENT, you get an empty response (NODATA) even if a wildcard record exists that would otherwise match.

For example, if you have:

*.prod.example.com.        IN  A   192.168.0.11
app.us.prod.example.com.   IN  A   192.168.0.41

The record app.us.prod.example.com creates an ENT at us.prod.example.com. Queries to us.prod.example.com will return empty, even though the wildcard *.prod.example.com would normally match.

Step 1: Identify the ENT

First, check if there are any records beneath the name that is returning empty responses. Use dig to query your zone:

$ dig @ns1.dnsimple-edge.com us.prod.example.com A +short
(empty)

If you get an empty response but the name exists (status: NOERROR), it is likely an ENT. To confirm, check if there are child records:

$ dig @ns1.dnsimple-edge.com app.us.prod.example.com A +short
192.168.0.41

If child records exist, the parent name is an ENT.

To see the full hierarchy, export your zone file and look for records that are deeper in the hierarchy than the name returning empty responses. DNSimple’s name servers do not allow zone transfers (AXFR) from dig.

Step 2: Create an explicit record

To fix the empty response, add a record at the ENT name in the record editor. You have two options:

Option A: Add a specific value

If you want the name to return a specific value, add that record:

us.prod.example.com.   IN  A   192.168.0.50

Option B: Match the wildcard value

If you want the name to behave like the wildcard, add the same record type and value as the wildcard:

us.prod.example.com.   IN  A   192.168.0.11

This ensures consistent behavior with other names that match the wildcard.

Step 3: Verify the change

After adding the explicit record, verify that the name now returns the expected response:

$ dig @ns1.dnsimple-edge.com us.prod.example.com A +short
192.168.0.11

The name is no longer an ENT. It now has its own record and returns that value when queried.

Common scenarios

Fixing ENT created by ACME challenge

If a Let’s Encrypt certificate provision created an ENT (e.g., _acme-challenge.app.us.prod.example.com), you may need to add explicit records at the intermediate names:

us.prod.example.com.   IN  A   192.168.0.11
app.us.prod.example.com.   IN  A   192.168.0.11

ENTs created by DKIM and SRV records

DKIM records like selector._domainkey.example.com create an ENT at _domainkey.example.com, and SRV records like _sip._tcp.example.com create one at _tcp.example.com. These are normal and usually need no fix: mail servers and SIP clients query the full names, never _domainkey.example.com or _tcp.example.com themselves.

Alternative: Remove the record creating the ENT

If the record creating the ENT is no longer needed (such as an old ACME challenge record), you can remove it instead of adding explicit records. This will eliminate the ENT and restore wildcard matching.

Warning

Only remove records if you are certain they are no longer needed. Do not delete _acme-challenge records while a certificate is being issued. DNSimple removes them automatically once Let’s Encrypt’s validation for them expires.

Have more questions?

If you have additional questions or need any assistance with fixing Empty Non-Terminal issues, just contact support, and we will be happy to help. You can also read more about DNS hosting at DNSimple.