Default DNS resolver (192.168.5.2) is not supporting SOA records in a VZ VM in macOS

### Description

With a VZ VM in macOS (Apple silicon) created like this:

```
limactl start --name=debian-vz --vm-type=vz template:debian-12
```

The default DNS resolver (192.168.5.2) is not supporting SOA records at all:

```
$ dig under-the-apex.example.org soa

; <<>> DiG 9.18.41-1~deb12u1-Debian <<>> under-the-apex.example.org soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47294
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;under-the-apex.example.org. IN SOA

;; Query time: 0 msec
;; SERVER: 192.168.5.2#53(192.168.5.2) (UDP)
;; WHEN: Fri Jan 09 18:43:33 -05 2026
;; MSG SIZE rcvd: 44

$ dig example.org soa

; <<>> DiG 9.18.41-1~deb12u1-Debian <<>> example.org soa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47004
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.org. IN SOA

;; Query time: 0 msec
;; SERVER: 192.168.5.2#53(192.168.5.2) (UDP)
;; WHEN: Fri Jan 09 18:43:51 -05 2026
;; MSG SIZE rcvd: 29
```

But I think an RFC compliant resolver should support these RR types. From RFC 1123:

> 6.1.3.5 Extensibility
> DNS software MUST support all well-known, class-independent formats [DNS:2], and SHOULD be written to minimize the trauma...
> ....
> 6.1.4.2 DNS User Interface
> ...
> At a minimum, the basic interface MUST support a request for all information of a specific type and class associated with a specific name... When there is no error, the basic interface returns the complete response information without modification, deletion, or ordering, so that the basic interface will not need to be changed to accommodate new data types.

This lack of support for SOA RR type brings real problems with things like cert-manager, that, under its default configuration, relies on SOA records and failing to find them produces:

```
[2026-01-09 19:03:24] E0110 00:03:24.203186 12 sync.go:176] "propagation check failed" err="Could not determine the zone for \"_acme-challenge.example.org.\": Could not find the SOA record in the DNS tree for the domain '_acme-challenge.example.org.' using nameservers [10.43.0.10:53]" logger="cert-manager.controller" resource_name="mycert-1-4077333573-1153400402" resource_namespace="default" resource_kind="Challenge" resource_version="v1" dnsName="example.org" type="DNS-01"
```

In my opinion, this is confusing to say the least and I can only wonder the pain it is causing to people not very familiar with SSL certificates, ACME or DNS.

Is this behavior by design or is it a bug?

Note: Originally posted at https://cloud-native.slack.com/archives/C043N6ZFV9S/p1768003954582759