Stub zones return unexpected NS records
Summary
BIND server B with a static-stub zone configured with a server address of BIND
server A, a secondary for that zone, may return unexpected NS records.
BIND version affected
I tested with BIND 9.19.21, but I believe this behaviour probably goes back to BIND 9.11.x
named -V
BIND 9.19.21 (Development Release) <id:c030a67>
running on Linux x86_64 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023
built by make with '--enable-fixed-rrset' '--enable-dnstap' '--enable-querytrace=yes' '--with-openssl' '--with-libxml2' '--with-json-c' '--enable-full-report' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/'
compiled by GCC 12.3.1 20230508 (Red Hat 12.3.1-1)
compiled with OpenSSL version: OpenSSL 3.0.9 30 May 2023
linked to OpenSSL version: OpenSSL 3.0.9 30 May 2023
compiled with libuv version: 1.44.2
linked to libuv version: 1.46.0
compiled with liburcu version: 0.15.0-pre
compiled with jemalloc version: 5.2.1
compiled with libnghttp2 version: 1.51.0
linked to libnghttp2 version: 1.51.0
compiled with libxml2 version: 2.10.3
linked to libxml2 version: 21004
compiled with json-c version: 0.15
linked to json-c version: 0.17
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
compiled with protobuf-c version: 1.4.1
linked to protobuf-c version: 1.4.1
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): no
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /usr/local/etc/named.conf
rndc configuration: /usr/local/etc/rndc.conf
nsupdate session key: /usr/local/var/run/named/session.key
named PID file: /usr/local/var/run/named/named.pid
Steps to reproduce
-
set up servers A and B with the configurations below.
-
Query Server B repeatedly for an RR from the static-stub zone:
While true do dig hgw.ddi.com @127.0.0.1
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27748
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 23cb1ccef98f3bf00100000065df1c8b908417789e893016 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 300 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 260 IN NS bialistock.ddi.com.
ddi.com. 260 IN NS haparanda.ddi.com.
;; ADDITIONAL SECTION:
haparanda.ddi.com. 300 IN A 10.0.0.237
bialistock.ddi.com. 300 IN A 10.0.0.49
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 11:44:11 UTC 2024
;; MSG SIZE rcvd: 165
What is the current bug behavior?
When the NS records in the authority section expire, Server B add the server-names
from its static-stub configuration as NS records plus a NS record in the name of
the domain itself
...
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50265
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 88424ea83ed9b09d0100000065df1d8b76b871a0c1e4d1e7 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 44 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 4 IN NS bialistock.ddi.com.
ddi.com. 4 IN NS haparanda.ddi.com.
;; ADDITIONAL SECTION:
haparanda.ddi.com. 44 IN A 10.0.0.237
bialistock.ddi.com. 44 IN A 10.0.0.49
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Feb 28 11:48:27 UTC 2024
;; MSG SIZE rcvd: 165
; <<>> DiG 9.19.21 <<>> hgw.ddi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39703
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 329a1ed8e54b28d30100000065df1d90545987c64fe602f2 (good)
;; QUESTION SECTION:
;hgw.ddi.com. IN A
;; ANSWER SECTION:
hgw.ddi.com. 39 IN A 10.0.0.1
;; AUTHORITY SECTION:
ddi.com. 86400 IN NS StaticStubZoneNS-1.org.
ddi.com. 86400 IN NS ddi.com.
ddi.com. 86400 IN NS StaticStubZoneNS-2.org.
What is the expected correct behavior?
I expect to see the NS records from the domain or none at all.
Relevant configuration files
Server A config:
options {
directory "/home/named";
pid-file "named.pid";
listen-on-v6 { none; };
dnssec-validation auto;
recursion yes;
allow-recursion { any; };
};
zone "ddi.com" IN {
type secondary;
primaries { 10.0.0.4;};
file "s/db.ddi.com";
allow-transfer {any;};
notify false;
};
Server B config:
options {
directory "/home/named";
pid-file "named.pid";
listen-on-v6 { none; };
dnssec-validation no;
minimal-responses no;
recursion yes;
max-cache-size 90%;
allow-recursion { any; };
};
zone "ddi.com" IN {
type static-stub;
server-addresses {
10.0.0.182;
};
server-names {
"StaticStubZoneNS-1.org";
"StaticStubZoneNS-2.org";
};
};
Zone file:
ddi.com. 86400 IN SOA haparanda.ddi.com. support.ddi.com. 2024021733 1800 900 604800 86400
ddi.com. 260 IN NS haparanda.ddi.com.
ddi.com. 260 IN NS bialistock.ddi.com.
alice-laptop.ddi.com. 600 IN A 10.0.0.149
bag-local-lyset.ddi.com. 300 IN A 10.0.0.15
bialistock.ddi.com. 300 IN A 10.0.0.49
haparanda.ddi.com. 300 IN A 10.0.0.237
hgw.ddi.com. 300 IN A 10.0.0.1
...
Relevant logs
Server B has no IPV6 connectivity the following was logged at startup:
Feb 28 11:44:11 bialistock named[235198]: network unreachable resolving 'StaticStubZoneNS-1.org/AAAA/IN': 2001:500:c::1#53
Feb 28 11:44:11 bialistock named[235198]: network unreachable resolving 'StaticStubZoneNS-2.org/A/IN': 2001:500:c::1#53