Multi-character subdomain is not resolved by wildcard "*" record when using Split Horizon - SimpleAddress

[shalinmakadia]

I am having a weird issue that I have tried to rectify using all the resources available on the internet, with no avail.

When I configure a wildcard * record to catch-all non defined subdomains on a primary domain AND use split horizon app on that record, it matches the * to a single character (as if a . in a regex).

For example, when I create a record *.abc.com for Split Horizon App - SimpleAddress, it can resolve a.abc.com or b.abc.com or 3.abc.com etc, but cannot resolve aa.abc.com or ab.abc.com or 123.abc.com (multi-character subdomains).

Below info is from test scenario that I used to recreate the issue I have in live:-

"nslookup a.abc.com" results in:-
Name: a.abc.com
Address: 192.168.3.11

"nslookup ab.abc.com" results in:-
*** UnKnown can't find ab.abc.com: Non-existent domain

Not sure is dnsApp.config will affect the record above, so posting the contents below.
dnsApp.config:-
{
"networks": {
"vlan1001": ["192.168.1.0/24"],
"vlan1003": ["192.168.3.0/24"],
"vlan1004": ["192.168.4.0/24"],
"vlan1005": ["192.168.5.0/24"]
},
"enableAddressTranslation": false,
"networkGroupMap": {
"10.0.0.0/8": "local1",
"172.16.0.0/12": "local2",
"192.168.0.0/16": "local3"
},
"groups": []
}

[ShreyasZare]

Thanks for the post. Please share a screenshot of your abc.com zone which shows all records in the zone. That will help me to try to replicate the issue better.

[shalinmakadia]

All defaults except for the TTL

[ShreyasZare]

Thanks for the screenshot. I tried the same and its working well here so not sure what could be the issue there. Are you using the latest version of the DNS server?

I would also suggest that you test the domain names using the DNS Client tool on the admin panel. You can add 127.0.0.0/8 network to your APP record to return a specific IP for the test.

[shalinmakadia]

I have further tested this and noted below points:-

1. The issue is for any APP record - belonging to any app, not just Split Horizon (tested with What Is My DNS app).
2. The root cause is Advanced Forwarding app.

Testing steps:-

• Brand new Technitium DNS server for testing purposes

• All defaults - exception: TTL defaults changed to 300

• installed App: What Is My DNS - no config required

• added primary zone "xyz.com" - all default

• added record "*.xyz.com" - As per screenshot below

• test: nslookup a.xyz.com - result as expected - screenshot below

• test: nslookup ab.xyz.com - result as expected - screenshot below

• installed App: Advanced Forwarding with below config:-

{
  "enableForwarding": true,
  "forwarders": [
    {
      "name": "primary",
      "proxy": null,
      "dnssecValidation": true,
      "forwarderProtocol": "Https",
      "forwarderAddresses": [
        "https://1.1.1.2/dns-query",
        "https://1.0.0.2/dns-query",
        "https://9.9.9.9/dns-query",
        "https://149.112.112.112/dns-query"
      ]
    },
    {
      "name": "cloudflare-google",
      "proxy": null,
      "dnssecValidation": true,
      "forwarderProtocol": "Tls",
      "forwarderAddresses": [
        "1.1.1.1",
        "1.0.0.1",
        "8.8.8.8",
        "8.8.4.4"
      ]
    }
  ],
  "networkGroupMap": {
    "192.168.1.0/24": "test_1",
    "192.168.5.0/24": "test_5"
  },
  "groups": [
    {
      "name": "test_1",
      "enableForwarding": true,
      "forwardings": [
        {
          "forwarders": [
            "primary"
          ],
          "domains": [
            "*"
          ]
        }
      ]
    },
    {
      "name": "test_5",
      "enableForwarding": true,
      "forwardings": [
        {
          "forwarders": [
            "cloudflare-google"
          ],
          "domains": [
            "*"
          ]
        }
      ]
    }
  ]
}

• test: nslookup a.xyz.com - result as expected - screenshot below

• test: nslookup ab.xyz.com - result unexpected - forwarded to external DNS - screenshot below

I suppose I have made a mistake somewhere in Advanced Forwarding config. My intention was to have specific VLANs use specific forwarder, but only for records that cannot be resolved by Technitium's defined zones & records.

Finally, 2 questions:-

1. Is there a better way to achieve what I want?
2. This does not sit right with me that when * record is created it provides different results for single char subdomain and multi char subdomain to the same client. Is this expected behaviour or a bug? Any references that I can check out to get a deeper understanding of what is happening ?

[ShreyasZare]

Thanks for the detailed steps to reproduce the issue. I am able to reproduce it on my setup. This is actually a bug in how the app responses are compared. The current implementation logic checks for more specific response to use and it is considering the response from Advanced Forwarding app to be more specific in this case.

Will get this issue fixed soon in the next update.