[Dnsmasq-discuss] IoT devices are now using unpatched vulnerability in the address configuration of dnsmasq

[Buck Horn]

On 06.06.25 06:17, switching at riseup.net wrote:
>> Expected Result
> The result of "dig https" should return nothing, just like "dig
> anythinghere".
>
>> Actual Result
> Returns the list of ICANN NS servers.


This doesn't constitute a vulnerability.
Your observation is about dig's behaviour rather than dnsmasq's.

Note that if you run dig without any parameters, dig will default to 
requesting the NS type record for the root zone.


Your 'dig HTTP' will request an A record for a domain named 'HTTP':

$ dig HTTP

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> HTTP
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56167
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;HTTP.                IN    A

;; Query time: 27 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Mon Jun 09 10:07:07 CEST 2025
;; MSG SIZE  rcvd: 22


Now with your 'dig HTTPS', depending on the dig version you are using, 
dig will interpret HTTPS as the type of record you try to request - but 
since you didn't provide a domain, it will fall back to its default and 
request an NS record for '.' (the root zone), as can be seen from the 
question section:

$ dig HTTPS

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> HTTPS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61991
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;.                IN    NS

;; ANSWER SECTION:
.            316    IN    NS    l.root-servers.net.
.            316    IN    NS    h.root-servers.net.
.            316    IN    NS    j.root-servers.net.
.            316    IN    NS    m.root-servers.net.
.            316    IN    NS    i.root-servers.net.
.            316    IN    NS    g.root-servers.net.
.            316    IN    NS    k.root-servers.net.
.            316    IN    NS    d.root-servers.net.
.            316    IN    NS    a.root-servers.net.
.            316    IN    NS    e.root-servers.net.
.            316    IN    NS    b.root-servers.net.
.            316    IN    NS    c.root-servers.net.
.            316    IN    NS    f.root-servers.net.

;; Query time: 35 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Mon Jun 09 10:07:18 CEST 2025
;; MSG SIZE  rcvd: 239


You can prompt the same behaviour of dig if you supply any other record 
type instead of HTTPS, e.g. A or AAAA.

I agree that seems a bit unexpected, but you'd have to file an issue 
with dig developers if you want dig to behave differently.

In the meantime, to have dig correctly request a specific type of 
record, just supply a domain along with the type.

Kind regards,
      Buck