Additional sections for NAPTR records

Question

Additional sections for NAPTR records

Closed this issue 6 months ago · 1 comments

Hello, colleagues!

I have specific setup in which my Unbound acts as resolver for NAPTR records (in telephony infra). And i have some nuances with handling of NAPTR record by Unbound. Below i will try to show the problem.

"Good" answer:
dig -t naptr m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org @xxx.yyy.81.66

; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> -t naptr m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org @xxx.yyy.81.66
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24732
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org. IN NAPTR

;; ANSWER SECTION:
m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org. 86400 IN NAPTR 10 10 "S" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp:x-3gpp-ggsn:x-gn:x-gp" "" gtp-mcc-new.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org.
m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org. 86400 IN NAPTR 20 10 "A" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp:x-3gpp-ggsn:x-gn:x-gp" "" topon.mccXXX2.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org.
m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org. 86400 IN NAPTR 20 10 "A" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp:x-3gpp-ggsn:x-gn:x-gp" "" topon.mccXXX1.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org.

;; AUTHORITY SECTION:
apn.epc.mncYYY.mccZZZ.3gppnetwork.org. 86400 IN NS grxdnsXXX1p.mncYYY.mccZZZ.gprs.
apn.epc.mncYYY.mccZZZ.3gppnetwork.org. 86400 IN NS grxdnsXXX2p.mncYYY.mccZZZ.gprs.

;; ADDITIONAL SECTION:
topon.mccXXX1.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. 86400 IN A xxx.yyy.115.0
topon.mccXXX2.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. 86400 IN A xxx.yyy.157.0
grxdnsXXX1p.mncYYY.mccZZZ.gprs. 86400 IN A xxx.yyy.156.9
grxdnsXXX2p.mncYYY.mccZZZ.gprs. 86400 IN A xxx.yyy.156.10
gtp-mcc-new.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. 86400 IN SRV 10 50 2123 topon.mccXXX.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org.
gtp-mcc-new.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. 86400 IN SRV 10 50 2123 topon.mccXXX.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org.
[...]

There is full set of records in additional section: A-recods for SRV, A-records and SRV-records themselves.
And this is the answer from BIND.

Now there is "problem" answer (with Unbound-1.21.0, latest version):
dig -t naptr m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org @10.221.138.2

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> -t naptr m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org @10.221.138.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56460
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;m.xxxxx.apn.epc.mncXXX.mccZZZ.3gppnetwork.org. IN NAPTR

;; ANSWER SECTION:
m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org. 31574 IN NAPTR 20 10 "A" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp:x-3gpp-ggsn:x-gn:x-gp" "" topon.mccXXX1.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org.
m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org. 31574 IN NAPTR 20 10 "A" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp:x-3gpp-ggsn:x-gn:x-gp" "" topon.mccXXX2.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org.
m.xxxxx.apn.epc.mncYYY.mccZZZ.3gppnetwork.org. 31574 IN NAPTR 10 10 "S" "x-3gpp-pgw:x-s5-gtp:x-s8-gtp:x-3gpp-ggsn:x-gn:x-gp" "" gtp-mcc-new.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org.

;; AUTHORITY SECTION:
apn.epc.mncYYY.mccZZZ.3gppnetwork.org. 31574 IN NS grxdnsXXX1p.mncYYY.mccZZZ.gprs.
apn.epc.mncYYY.mccZZZ.3gppnetwork.org. 31574 IN NS grxdnsXXX2p.mncYYY.mccZZZ.gprs.

;; ADDITIONAL SECTION:
grxdnsXXX1p.mncYYY.mccZZZ.gprs. 31574 IN A xxx.yyy.156.9
grxdnsXXX2p.mncYYY.mccZZZ.gprs. 31574 IN A xxx.yyy.156.10
gtp-mcc-new.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. 31574 IN SRV 10 50 2123 topon.mccXXX2.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org.
gtp-mcc-new.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. 31574 IN SRV 10 50 2123 topon.mccXXX1.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org.
[...]

And there we have no full set of records oin additional section: A-records, SRV-records. But there are no A-records for SRV just like it was done in "Good" answer above.

If i resolve the A-records as usual:
dig topon.mccXXX2.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. @10.221.138.2

; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> topon.mccXXX2.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. @10.221.138.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55964
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;topon.mccXXX2.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. IN A

;; ANSWER SECTION:
topon.mccXXX2.msk.xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. 86400 IN A xxx.yyy.157.0

;; AUTHORITY SECTION:
xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. 84562 IN NS grxdnsXXX2p.mncYYY.mccZZZ.gprs.
xxxxx.node.epc.mncYYY.mccZZZ.3gppnetwork.org. 84562 IN NS grxdnsXXX1p.mncYYY.mccZZZ.gprs.

;; ADDITIONAL SECTION:
grxdnsXXX1p.mncYYY.mccZZZ.gprs. 31592 IN A xxx.yyy.156.9
grxdnsXXX2p.mncYYY.mccZZZ.gprs. 31592 IN A xxx.yyy.156.10
[...]

Unbound normally resolves these records and stores them in cache.

So my question is:
Is it possible to return the answer with single additional section just like in the "Good" example, i.e. without additional iterative queries? This is importnant nuance coused by our equipment operation features.

In the code, exactly in iterator/iter_scrub.c i found something similar with NAPTR records handling, for ex. in has_additional() function:
case LDNS_RR_TYPE_NAPTR:
/* TODO: NAPTR not supported, glue stripped off */
return 0;

And same lines in get_additional_name() function. Does it relate to my problem?

Also in google i found problem description around 14 years ago:
https://unbound-users.unbound.narkive.com/zhXlVqIB/unbound-1-4-6-does-not-seem-to-have-support-of-additional-sections-for-naptr-records
Don't know is this tha same problem, but it would be interesting is there any upcoming solution for resolving of NAPTR-records by means of single DNS-query.

Thanks a lot in advance!

Answer 1 · 2024-10-11T12:31:41.000Z

Hello!

Are there any thoughts on this issue?