Bind9 changes RCODE
Sonal Pahuja
sonal.s.pahuja at oracle.com
Wed Sep 29 07:43:18 UTC 2021
Hi All,
We have configured a forward zone in bind9 for e164.arpa, and we have our application to resolve e164 domain queries (NS, NAPTR, CNAME queries).
But our application is sending RCODE=4 (NOT implemented) to bind9. But bind9 at their side, changing it to "ServerFail" Error.
But we want on dig/dnsperf error code should come RCODE=4 only. Bind9 should not translate the original error code.
Bind 9 should send the original RCODE=4 to the requester.
Below are the snapshot of named/conf file. Wireshark is also attached with this mail.
options {
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named.stats";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; !blocked; allowed; };
//allow-query { any; };
recursion yes;
zone-statistics yes;
dnssec-enable yes;
dnssec-validation no;
// additional-from-auth no;
// additional-from-cache no;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};
zone "e164.arpa" IN {
type forward ;
forwarders { 127.0.0.1 port 49153; 139.165.24.21 port 49153;};
forward only;
};
Dig output:-
[root at ukp2-so1mp1 admusr]# dig -t naptr 4.0.4.5.2.4.1.4.2.0.2.4.7.8.9.5.7.9.e164.arpa @localhost
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.0.2.el6_10.8 <<>> -t naptr 4.0.4.5.2.4.1.4.2.0.2.4.7.8.9.5.7.9.e164.arpa @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31801 //expecting RCODE=4 here
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;4.0.4.5.2.4.1.4.2.0.2.4.7.8.9.5.7.9.e164.arpa. IN NAPTR
;; Query time: 97 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Sep 29 03:29:23 2021
;; MSG SIZE rcvd: 63
Application Wireshark snapshot:
[cid:image003.jpg at 01D7B533.C16C78B0]
Bind9 Wireshark:-
[cid:image004.jpg at 01D7B533.C16C78B0]
Kindly share your views on this.
Regards,
Sonal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210929/522f401b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 36142 bytes
Desc: image003.jpg
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210929/522f401b/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 36176 bytes
Desc: image004.jpg
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210929/522f401b/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RCODE_query.pcap
Type: application/octet-stream
Size: 830 bytes
Desc: RCODE_query.pcap
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210929/522f401b/attachment-0001.obj>
More information about the bind-users
mailing list