Skip to content

GeoIP wrongly leads to NXDOMAIN when different rrtype would be synthesized

Hello knot developer team!

In 2016 year a new RFC 2080 was created in which the algorithm for processing DNS requests was changed. New RFC contains major change in DNS iterative resolution algorithm:

The DNS iterative resolution algorithm precisely interprets the NXDOMAIN signal in this manner. If it encounters an NXDOMAIN response code from an authoritative server, it immediately stops iteration and returns the NXDOMAIN response to the querier.

I have many zones with GeoIP module configured with subnet mode, records located in this zone have only IPv4 records. If I try to resolve the record from this zone, I have those respnoses:

[god@sky ~]$ dig git.example.com -t AAAA

; <<>> DiG 9.16.15 <<>> git.example.com -t AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62739
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;git.example.com.                 IN      AAAA

;; AUTHORITY SECTION:
example.com.              46      IN      SOA     ns1.example.com. admin.example.com. 2021021801 900 900 1800 60

;; Query time: 123 msec
;; SERVER: 10.134.7.11#53(10.134.7.11)
;; WHEN: Ср июн 16 14:25:59 +07 2021
;; MSG SIZE  rcvd: 88

[god@sky ~]$ dig git.example.com -t A

; <<>> DiG 9.16.15 <<>> git.example.com -t A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24912
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;git.example.com.                 IN      A

;; ANSWER SECTION:
git.example.com.          160     IN      A       10.128.194.31

;; Query time: 66 msec
;; SERVER: 10.134.7.11#53(10.134.7.11)
;; WHEN: Ср июн 16 14:26:22 +07 2021
;; MSG SIZE  rcvd: 58

In Alpine 3.13.0 release this RFC applied to libmusl. Our servers support both ipv4 and ipv6 protocols, if any software tries to resolve any records, we send A and AAAA requests to the DNS server. As a result, the resolve completely stops working when receiving an NXDOMAIN for an AAAA record, and even an ipv4 response is not returned.

Now we cannot resolve any records located in this zone using alpine 3.13.+ Can we change the behavior of the GeoIP module to comply with this RFC8020?

Thx for your help.

Edited by Libor Peltan