ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-10-25T10:20:14Zhttps://gitlab.isc.org/isc-projects/kea-docker/-/issues/31Adjust kea-compose to use ipvlan network2023-10-25T10:20:14ZMarcin GodzinaAdjust kea-compose to use ipvlan networkMarcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/stork/-/issues/1188Fix hook build2023-10-12T08:09:12ZSlawek FigielFix hook buildAddresses:
- [Wrong go version](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408726)
- [Missing files in tarball](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408734)
- [Incompatible hooks](https://gitlab...Addresses:
- [Wrong go version](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408726)
- [Missing files in tarball](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408734)
- [Incompatible hooks](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408753)1.13Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3107ping-check-hook implement ST mode in PingCheckMgr2023-12-13T15:44:38ZThomas Markwalderping-check-hook implement ST mode in PingCheckMgrExtend PingCheckMgr, created in #3083, to support ST mode. The basic steps are:
1. PingCheckMgr::start()
- Skip creating the thread-pool
- Create an WatchSocket and pass it into PingChannel::open(). PingChannel::asyncSend() would ...Extend PingCheckMgr, created in #3083, to support ST mode. The basic steps are:
1. PingCheckMgr::start()
- Skip creating the thread-pool
- Create an WatchSocket and pass it into PingChannel::open(). PingChannel::asyncSend() would invoke WatchSocket::markReady() and socketWriteCallback() would invoke WatchSocket::clearReady()
- After the PingChannel is created, manager would crate an external socket, via IfaceMgr::addExternalSocket(), for the channel's socket.
2. PingCheckMgr::stop() would need to remove the sockets added abovekea2.5.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4360Undefined behaviours detected by LLVM 17 (noop_accept_cb, dns__nta_shutdown_cb)2023-10-13T11:27:34ZMichal NowakUndefined behaviours detected by LLVM 17 (noop_accept_cb, dns__nta_shutdown_cb)Job [#3708760](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3708760) failed for d730f635d34b0f8a6a517c6ae58a4c5a8b816480.
Unit tests `tcp_test`, `tcpdns_test`, and `tls_test` failed with:
```
[ RUN ] tcp_noop
../../lib/isc/netm...Job [#3708760](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3708760) failed for d730f635d34b0f8a6a517c6ae58a4c5a8b816480.
Unit tests `tcp_test`, `tcpdns_test`, and `tls_test` failed with:
```
[ RUN ] tcp_noop
../../lib/isc/netmgr/tcp.c:898:11: runtime error: call to function noop_accept_cb through pointer to incorrect function type 'enum isc_result (*)(struct isc_nmhandle *, enum isc_result, void *)'
/builds/isc-projects/bind9/tests/isc/netmgr_common.c:239: note: noop_accept_cb defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../lib/isc/netmgr/tcp.c:898:11 in
```
`keytable_test` unit test failed with:
```
[ RUN ] add
async.c:111:3: runtime error: call to function dns__nta_shutdown_cb through pointer to incorrect function type 'void (*)(void *)'
/builds/isc-projects/bind9/lib/dns/nta.c:582: note: dns__nta_shutdown_cb defined here
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior async.c:111:3 in
```
Core dumps and backtraces were preserved in the CI job.November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/stork/-/issues/1187Sanity checks for Stork 1.13.0 rc12024-01-29T14:02:52ZWlodzimierz WencelSanity checks for Stork 1.13.0 rc1We are now at step SANITY CHECKS of Stork 1.13.0 rc1.
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
2. Get the apk, deb & rp...We are now at step SANITY CHECKS of Stork 1.13.0 rc1.
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
2. Get the apk, deb & rpm packages, place them in the tarball location, run tests with `rake system_tests` and `rake system_tests_ui`.
3. Start demo locally with `rake demo:up` and follow the steps from the demo wiki: https://gitlab.isc.org/isc-projects/stork/-/wikis/Demo
4. Install server and agent locally e.g. in VMs from apk, deb & rpm packages
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is.
This way we know what is covered upfront and we can avoid repeating ourselves.
* tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/3706020/artifacts/browse
* apk, deb & rpm packages: https://gitlab.isc.org/isc-projects/stork/-/jobs/3706018/artifacts/browse1.13https://gitlab.isc.org/isc-projects/stork/-/issues/1186bump up version to 1.132023-10-18T09:50:10ZWlodzimierz Wencelbump up version to 1.131.13https://gitlab.isc.org/isc-projects/kea/-/issues/3106Ground work in the HA Service and Network State to support the hub-and-spoke ...2023-12-06T15:32:09ZMarcin SiodelskiGround work in the HA Service and Network State to support the hub-and-spoke modelThis issue extends the `HAService`, `HAImpl`, `HAConfig` and `NetworkState` to allow co-existence of multiple HA relationships in a single Kea server. It doesn't introduce any logic for the hub-and-spoke use case. It is just a ground wor...This issue extends the `HAService`, `HAImpl`, `HAConfig` and `NetworkState` to allow co-existence of multiple HA relationships in a single Kea server. It doesn't introduce any logic for the hub-and-spoke use case. It is just a ground work to eliminate the code that assumes existence of a single relationship.
See the [design](https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/hub-and-spoke-ha-mode#ground-work) for details.kea2.5.4Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3105RADIUS reply message2023-10-31T19:52:48ZFrancis DupontRADIUS reply messageThe RADIUS protocol defines a Reply-Message (18) attribute which carries human readable text in responses from a server. The freeRADIUS client library collects them but the old RADIUS hook does nothing about these attributes. I propose t...The RADIUS protocol defines a Reply-Message (18) attribute which carries human readable text in responses from a server. The freeRADIUS client library collects them but the old RADIUS hook does nothing about these attributes. I propose to fix that i.e. to log them at the INFO level.kea2.5.4Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3104RADIUS integer constants2023-11-07T14:21:32ZFrancis DupontRADIUS integer constantsRADIUS dictionaries used by freeRADIUS client library define attributes (`ATTRIBUTE` keyword) with attribute name, type code point (unfortunately not limited to 8 bits) and content type (including date), and integer constants (`VALUE` ke...RADIUS dictionaries used by freeRADIUS client library define attributes (`ATTRIBUTE` keyword) with attribute name, type code point (unfortunately not limited to 8 bits) and content type (including date), and integer constants (`VALUE` keyword, enum in IANA attribute registry which defines symbolic names for possible attribute values) with attribute name (one IANA registry per attribute), name and value (32 bits but usually a small unsigned integer).
Other keywords as `$INCLUDE` or `VENDOR` is parsed but not used so we choose to not support them, nor the capability to specify more than one dictionary.
In freeRADIUS client library dictionaries are implemented as lists and new items are pushed in front. The dictionary for values provides two functions: rc_dict_findval which returns an entry by value name, and rc_dict_getval which returns an entry by value and attribute names. findval is used by the from text attribute function, getval by the to text attribute function.
There are some possible choices here:
- check or not check when reading a dictionary if the attribute name is for an already defined attribute
- check or not check if a value was already defined with a different value
- consider that the use of findval in the from text function is a bug and use getval instead: this is far more consistent but not compatible with freeRADIUS client library (i.e. should we be "bug compatible" or just compatible with a note in the ARM? we already have some points where the second option was taken)
So my proposal is:
- check if the attribute name was already defined (this allows to use the type in value data structure and also to verify the attribute is an integer attribute)
- allows a different value for another attribute
- use the equivalent of getval in from text method so allows only symbolic values for the current attribute
- consider to return symbolic values in the to text method
A related point is to check (i.e. throw) or not (i.e. silently skip) if an attribute code point is greater than 255 (i.e. the attribute is a 'not protocol' one as the protocol field is on 8 bits).kea2.5.4Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/stork/-/issues/1184Don't use the directory name in the hook filename2023-10-10T07:07:41ZSlawek FigielDon't use the directory name in the hook filenameThe LDAP hook uses the root directory name in the output hook filename.
It should be a fixed value instead.The LDAP hook uses the root directory name in the output hook filename.
It should be a fixed value instead.1.13https://gitlab.isc.org/isc-projects/kea/-/issues/3101hardcode ICMP header len2023-10-11T11:49:03ZPiotrek Zadrogahardcode ICMP header len`struct icmphdr` is different for BSD and GNU libc:
BSD code:
```c++
/*
* Structure of an icmp header.
*/
struct icmphdr {
u_char icmp_type; /* type of message, see below */
u_char icmp_code; ...`struct icmphdr` is different for BSD and GNU libc:
BSD code:
```c++
/*
* Structure of an icmp header.
*/
struct icmphdr {
u_char icmp_type; /* type of message, see below */
u_char icmp_code; /* type sub code */
u_short icmp_cksum; /* ones complement cksum of struct */
};
```
GNU code:
```c++
struct icmphdr
{
uint8_t type; /* message type */
uint8_t code; /* type sub-code */
uint16_t checksum;
union
{
struct
{
uint16_t id;
uint16_t sequence;
} echo; /* echo datagram */
uint32_t gateway; /* gateway address */
struct
{
uint16_t __glibc_reserved;
uint16_t mtu;
} frag; /* path mtu discovery */
} un;
};
```
Because of that calculations of ICMP message header len vary on different systems, and also some UTs related to ping-check hook fail on FreeBSD.
ICMP header len could be defined inside of `ICMPMsg` class.kea2.5.3Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea-docker/-/issues/30Add cloudsmith image instructions to readme2023-10-11T11:28:15ZMarcin GodzinaAdd cloudsmith image instructions to readmeAdd instructions about pulling and using Kea images published on cloudsmith.Add instructions about pulling and using Kea images published on cloudsmith.Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/stork/-/issues/1183LDAP hook: Minor issues in README2023-10-09T08:46:01ZSlawek FigielLDAP hook: Minor issues in README- Path to `stork-agent` hook directory instead of `stork-server`
- $ at the beginning
- Improperly commented lines (lines stated with % )- Path to `stork-agent` hook directory instead of `stork-server`
- $ at the beginning
- Improperly commented lines (lines stated with % )1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/kea/-/issues/3099compilation error on FreeBSD2023-10-05T17:34:58ZPiotrek Zadrogacompilation error on FreeBSDThere is compilation error on FreeBSD distros 12 and 13 detected.
This is related to #3055 .
This issue will be fixed in premium MR only.There is compilation error on FreeBSD distros 12 and 13 detected.
This is related to #3055 .
This issue will be fixed in premium MR only.kea2.5.3Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/stork/-/issues/1180Support for common app-specific hook filename prefix2023-10-05T13:27:03ZSlawek FigielSupport for common app-specific hook filename prefixIt adds support for the app-specific prefix name in hook filenames.
The prefix should be trimmed to simplify the CLI namespaces.
Original discussion: [link](https://gitlab.isc.org/isc-projects/stork-hook-ldap/-/merge_requests/1#note_403...It adds support for the app-specific prefix name in hook filenames.
The prefix should be trimmed to simplify the CLI namespaces.
Original discussion: [link](https://gitlab.isc.org/isc-projects/stork-hook-ldap/-/merge_requests/1#note_403065).1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/1179Hook naming convention2023-10-05T08:27:32ZSlawek FigielHook naming conventionCurrently, there are no strict requirements for the hook binaries.
Maybe we should include the application (server or agent) and its version in the filename?Currently, there are no strict requirements for the hook binaries.
Maybe we should include the application (server or agent) and its version in the filename?https://gitlab.isc.org/isc-projects/bind9/-/issues/4355Potential cache poisoning due to unexpected recursion instead of following de...2023-11-16T02:27:40ZCathy AlmondPotential cache poisoning due to unexpected recursion instead of following delegation when serve-stale is enabled### Summary
As reported in [Support ticket #22830](https://support.isc.org/Ticket/Display.html?id=22830)
The server is authoritative for some zones as well as supporting recursion for others. Some zones delegate subdomains to other na...### Summary
As reported in [Support ticket #22830](https://support.isc.org/Ticket/Display.html?id=22830)
The server is authoritative for some zones as well as supporting recursion for others. Some zones delegate subdomains to other nameservers. For those, the NS RRset in the delegation is unreachable/unresolvable.
With `stale-answer-enable no;` the expected SERVFAIL is returned to the clients querying for names in these subdomains.
With `stale-answer-enable yes;` the resolver appears not to follow the delegation but instead attempts resolution directly from the root nameservers instead, sometimes providing different answers to the client that those intended by the configuration and delegation (albeit broken).
### BIND version used
```
BIND 9.16.43-Ubuntu (Extended Support Version) <id:de6f1a0>
running on Linux x86_64 5.15.0-1041-aws #46~20.04.1-Ubuntu SMP Wed Jul 19 15:40:00 UTC 2023
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-FMDtLY/bind9-9.16.43=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
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): yes
TKEY mode 3 support (GSS-API): yes
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
Pasting here from the report to Support team:
Locally setup in-addr.arpa for private /16 network: 59.10.in-addr.arpa
with delegation for /24:
```
$ORIGIN 59.10.in-addr.arpa.
1 NS nss1.example.net.
NS nss2.example.net.
NS nss3.example.net.
```
As these NSs are fake, we can't contact them ever and without serve-stale enabled - we always receive SERVFAIL.
**But, as soon as serve-stale is enabled, named will start to try to run recursion from the root**, and we start getting NXDOMAIN (what is cacheable answer)
```
# dig 1.59.10.in-addr.arpa @127.0.0.1
; <<>> DiG 9.16.43-Ubuntu <<>> 1.59.10.in-addr.arpa @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 21068
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: c6da2a29e4d47c6a01000000651554607e40e4b8c2a75c00 (good)
;; QUESTION SECTION:
;1.59.10.in-addr.arpa. IN A
;; AUTHORITY SECTION:
10.in-addr.arpa. 10800 IN SOA prisoner.iana.org. hostmaster.root-servers.org. 1 604800 60 604800 604800
;; Query time: 156 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 28 10:24:32 UTC 2023
;; MSG SIZE rcvd: 172
```
The same thing with direct zones.
For example:
- Test zone: myctl.com
- Test record: test.myctl.com (on the external NSs it returns 127.0.0.1)
Delegation in the local zone file:
```
$ORIGIN myctl.com.
test NS nss1.example.net.
NS nss2.example.net.
NS nss3.example.net.
```
Without serve-stale enabled, I always have SERVFAIL answer.
With serve-stale enabled, I have SERVFAL twice, then recursion started from the root, and I will have answer from the external nameservers not specified in the localzone file:
```
# dig test.myctl.com. @127.0.0.1
; <<>> DiG 9.16.43-Ubuntu <<>> test.myctl.com. @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 29218
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 42aa29742ab548b00100000065155561f82a157e5a4464ae (good)
;; QUESTION SECTION:
;test.myctl.com. IN A
;; Query time: 60 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 28 10:28:49 UTC 2023
;; MSG SIZE rcvd: 71
```
```
# dig test.myctl.com. @127.0.0.1
; <<>> DiG 9.16.43-Ubuntu <<>> test.myctl.com. @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42780
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: c14a6db123fa69bc010000006515556372206781ce6b989d (good)
;; QUESTION SECTION:
;test.myctl.com. IN A
;; ANSWER SECTION:
test.myctl.com. 300 IN A 127.0.0.1
;; AUTHORITY SECTION:
test.myctl.com. 3600 IN NS nss2.example.net.
test.myctl.com. 3600 IN NS nss1.example.net.
test.myctl.com. 3600 IN NS nss3.example.net.
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 28 10:28:51 UTC 2023
;; MSG SIZE rcvd: 155
```
### What is the current *bug* behavior?
Unexpected recursion from root down (ignoring the delegation from the local auth parent zones) by the resolver when stale-answer-enable is 'yes'
### What is the expected *correct* behavior?
Consistent SERVFAIL (by following the delegation NS RRset and being unable to resolve the delegated nameserver names in the parent zone).
### Relevant configuration files
Relevant snippets from named.conf (for the full configuration, see the Support ticket):
```
options {
directory "/var/cache/bind";
listen-on-v6 {
"none";
};
dnssec-validation no;
minimal-responses no;
qname-minimization off;
stale-answer-enable yes;
stale-answer-client-timeout 1800;
stale-cache-enable yes;
stale-refresh-time 30;
masterfile-format text;
};
zone "59.10.in-addr.arpa" in {
type master;
file "zones/59.10.rev";
forwarders {
};
};
zone "myctl.com" in {
type master;
file "zones/myctl.com";
forwarders {
};
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
```
```
# cat /var/cache/bind/zones/myctl.com
$ORIGIN .
$TTL 3600 ; 1 hour
myctl.com IN SOA dc1.example.net. corporate.example.net. (
428210 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)
NS ns1.myctl.com.
NS ns2.myctl.com.
ns1.myctl.com. IN A 127.0.0.1
ns2.myctl.com. IN A 127.0.0.1
$ORIGIN myctl.com.
test NS nss1.example.net.
NS nss2.example.net.
NS nss3.example.net.
```
```
# cat /var/cache/bind/zones/59.10.rev
$ORIGIN .
$TTL 3600 ; 1 hour
59.10.in-addr.arpa IN SOA dc1.example.net. corporate.example.net. (
428210 ; serial
900 ; refresh (15 minutes)
600 ; retry (10 minutes)
86400 ; expire (1 day)
3600 ; minimum (1 hour)
)
NS ns1.example.net.
NS ns2.example.net.
$ORIGIN 59.10.in-addr.arpa.
1 NS nss1.example.net.
NS nss2.example.net.
NS nss3.example.net.
```
Notably, this server IS authoritative for the parent zones but delegates to an NS RRset that it's not authoritative for and where the names can't be resolved to anything useful.
Therefore the resolver should be attempting to use the delegation NS RRset for these internal-only zones and delegations from them, and not attempting resolution from the root down (but it *DOES* nevertheless attempt that with `stale-answer-enable yes;`
### Why this is potentially a security defect:
Quoting the reporter:
We expect that internal customers will get some internal IPs in answers, or didn’t get anything if something wrong (like broken internal NSs) or get answers from the cache when the NSs configured in the zone file are not available but answers already in the cache. But not external IPs or unexpected answers.
Lets assume something goes wrong with our internal NSs (nss[1-3].example.net, like in example above), and everyone inside the company get some sort of external IP (or loopback IP) for some requested record (like in example above). Let it be “supernewfeature.myctl.com” (this is only for example), and everyone inside the company start to run some sort of queries against that record with answer pointed to unexpected place, then service might be overload/unexpected responses replied/anything else.
When the serve-stale is disabled - everyone will get SERVFAIL, and external services will not be impacted.
Also I see this as a way of potential attack, when in the external nameservers place some sort of victim IP address what can cause to DDoS or pointing to some sort of fishing website.
That's why I evaluate that issue as security issue.November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/1178Build pipeline for LDAP hook2023-10-09T15:23:58ZSlawek FigielBuild pipeline for LDAP hook1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4354Checking zone transfer information in the statistics channel fails on OpenBSD2023-10-12T09:37:12ZMichal NowakChecking zone transfer information in the statistics channel fails on OpenBSDJob [\#3693319](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3693319) failed for 23b52fb6a04e49f079942bb23ad4a5f0fb13e8da.
There's a permanent test failure in the `statschannel` system test on OpenBSD on `main` after e92d1eeafca6e5a...Job [\#3693319](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3693319) failed for 23b52fb6a04e49f079942bb23ad4a5f0fb13e8da.
There's a permanent test failure in the `statschannel` system test on OpenBSD on `main` after e92d1eeafca6e5a75299bff6a90ce37848409e85 got merged, specifically the `Checking zone transfer information in the statistics channel` check (that worked before the change) and the `Checking zone transfer transports` check (that was added in the change).
```plaintext
2023-10-03 00:23:55 INFO:statschannel I:statschannel_tmp_2s8p6u20:Checking zone transfer information in the statistics channel (25)
2023-10-03 00:23:55 INFO:statschannel I:statschannel_tmp_2s8p6u20:... using xml
2023-10-03 00:23:56 INFO:statschannel I:statschannel_tmp_2s8p6u20:... using json
...
2023-10-03 00:25:28 INFO:statschannel I:statschannel_tmp_2s8p6u20:... using xml
2023-10-03 00:25:28 INFO:statschannel I:statschannel_tmp_2s8p6u20:... using json
2023-10-03 00:25:28 INFO:statschannel I:statschannel_tmp_2s8p6u20:failed
```
```plaintext
2023-10-03 00:25:28 INFO:statschannel I:statschannel_tmp_2s8p6u20:Checking zone transfer transports (26)
2023-10-03 00:25:28 INFO:statschannel cmp: EOF on xfrins.example.format26
2023-10-03 00:25:28 INFO:statschannel cmp: EOF on xfrins.example-tcp.format26
2023-10-03 00:25:28 INFO:statschannel cmp: EOF on xfrins.example-tls.format26
2023-10-03 00:25:28 INFO:statschannel I:statschannel_tmp_2s8p6u20:failed
```
[xfrins.xml.x25](/uploads/fb7a275e22d23fbe33fa5f158cafd91d/xfrins.xml.x25)
[xfrins.json.j26](/uploads/9e3c39332724d734cd6cb96fcfca3555/xfrins.json.j26)
[xfrins.json.j25](/uploads/b0f3f858e762257000fe4293140b890e/xfrins.json.j25)November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/stork/-/issues/1176Subnet, network, host and possibly other tabs are not shown2023-10-05T14:58:41ZMarcin SiodelskiSubnet, network, host and possibly other tabs are not shownI speculate that this is a regression after the most recent Primeng/Angular upgrade.
Open a tab with a list of subnets. Click on one of the subnets. The subnet contents are shown and the tab with the list of subnets is unselected, but t...I speculate that this is a regression after the most recent Primeng/Angular upgrade.
Open a tab with a list of subnets. Click on one of the subnets. The subnet contents are shown and the tab with the list of subnets is unselected, but the tab for the subnet is not visible. In other words, you always have only one (default) tab and no way to navigate between different tabs.
In the following picture you can see what happens after clicking on a subnet. The subnet contents are displayed but there is only one tab.
![Zrzut_ekranu_2023-10-3_o_21.28.07](/uploads/3159164320680fabd343a780fd7c8a2c/Zrzut_ekranu_2023-10-3_o_21.28.07.png)1.13Marcin SiodelskiMarcin Siodelski