Domains fail to resolve in "vz" VMs when TLD exists in hostResolver

[anomalousitem]

Description

I'm seeing NXDOMAIN responses for domains under the same TLD that exists in hostResolver.hosts. Here's how I've been able to reproduce this. My machine is an Apple M1 Max MacBook Pro (2021) running Sonoma 14.5.

Template

---
images:
  - location: "https://cloud.debian.org/images/cloud/bookworm/20240429-1732/debian-12-genericcloud-amd64-20240429-1732.qcow2"
    arch: "x86_64"
    digest: "sha512:6cc752d71b390c7fea64b0b598225914a7f4adacd4a33fa366187fac01094648628e0681a109ae9320b9a79aba2832f33395fa13154dad636465b7d9cdbed599"

  - location: "https://cloud.debian.org/images/cloud/bookworm/20240429-1732/debian-12-genericcloud-arm64-20240429-1732.qcow2"
    arch: "aarch64"
    digest: "sha512:59afc40ad0062ca100c9280a281256487348c8aa23b3e70c329a6d6f29b5343b628622e63e0b9b4fc3987dd691d5f3c657233186b3271878d5e0aa0b4d264b06"

mounts: []

vmType: vz

hostResolver:
  hosts:
    local.example.dev: host.lima.internal

Create the VM, start it, and log in.

$ limactl create --name dns-issue dns-issue.yml
$ limactl start dns-issue
$ limactl shell dns-issue

Inside the VM, domains like .com and .io TLDs resolve successfully.

james@lima-dns-issue:~$ nslookup google.com
Server:         192.168.5.2
Address:        192.168.5.2#53

Non-authoritative answer:
Name:   google.com
Address: 142.251.179.113
Name:   google.com
Address: 142.251.179.138
Name:   google.com
Address: 142.251.179.139
Name:   google.com
Address: 142.251.179.101
Name:   google.com
Address: 142.251.179.102
Name:   google.com
Address: 142.251.179.100
james@lima-dns-issue:~$ nslookup kubernetes.io
Server:         192.168.5.2
Address:        192.168.5.2#53

Non-authoritative answer:
Name:   kubernetes.io
Address: 147.75.40.148

james@lima-dns-issue:~$ nslookup lima-vm.io
Server:         192.168.5.2
Address:        192.168.5.2#53

Non-authoritative answer:
Name:   lima-vm.io
Address: 3.212.91.35
Name:   lima-vm.io
Address: 44.217.247.226

However, I noticed that .dev TLDs (other than the one configured) respond with NXDOMAIN results.

james@lima-dns-issue:~$ nslookup local.example.dev
Server:         192.168.5.2
Address:        192.168.5.2#53

Non-authoritative answer:
Name:   local.example.dev
Address: 192.168.5.2

james@lima-dns-issue:~$ nslookup go.dev
Server:         192.168.5.2
Address:        192.168.5.2#53

** server can't find go.dev: NXDOMAIN

james@lima-dns-issue:~$ nslookup taskfile.dev
Server:         192.168.5.2
Address:        192.168.5.2#53

** server can't find taskfile.dev: NXDOMAIN

If I set the vmType to "qemu" instead, it doesn't appear to be a problem. If I create a new vm with "local.example.org" in hostResolver.hosts then the .dev domains resolve successfully and the .org domains start failing. In fact, I can't even install the dns utils (or any package for that matter) from apt to use nslookup any more.

I stumbled on this discussion and learned that the host resolver is a stub resolver that runs on the host. But I'm afraid I'm struggling with my limited knowledge on this topic now to know how and where to debug this further. Of course, feel free to let me know if you'd like me to try some other test cases and/or configs.