ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2018-03-18T10:25:34Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/123Support 64 RPZ zones by default from 9.13 onwards2018-03-18T10:25:34ZGhost UserSupport 64 RPZ zones by default from 9.13 onwardsSupport 64 RPZ zones by default from 9.13 onwards. Right now it's 32 or 64, and there doesn't seem to be any pressing need to have this choice going forward.Support 64 RPZ zones by default from 9.13 onwards. Right now it's 32 or 64, and there doesn't seem to be any pressing need to have this choice going forward.BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/124validation fails for rs.dns-oarc.net/TXT2023-10-31T09:44:05ZEvan Huntvalidation fails for rs.dns-oarc.net/TXTApparently caused by change 4859 - we're over-aggressively checking for validation deadlocks when a an apex CNAME is found.Apparently caused by change 4859 - we're over-aggressively checking for validation deadlocks when a an apex CNAME is found.https://gitlab.isc.org/isc-projects/bind9/-/issues/125in-view duplicate zone not detected by named-checkconf2018-03-19T22:16:09ZCathy Almondin-view duplicate zone not detected by named-checkconfIt doesn't seem that the configuration checker is applied effectively to zones of type 'in-view' that are declared referencing a copy of the zone that is being loaded in another view.
For example:
```
view "my-default" {
...
z...It doesn't seem that the configuration checker is applied effectively to zones of type 'in-view' that are declared referencing a copy of the zone that is being loaded in another view.
For example:
```
view "my-default" {
...
zone "yum.co.uk" IN {
type master;
file "yum.co.uk.zone";
};
...
};
```
```
view "another-one" {
match-clients { any; };
zone "yum.co.uk" IN {
type master;
file "yum.co.uk.zone";
};
zone "yum.co.uk" IN {
in-view "my-default";
};
};
```
There are no errors reported when it is run through named-checkconf, but when loading, named fails when parsing the second instance of "yum.co.uk" in the second view - having not previously detected that there might be a problem loading it.
The error message reported is not particularly helpful:
```
02-Mar-2018 18:37:43.266 automatic empty zone: view my-default: EMPTY.AS112.ARPA
02-Mar-2018 18:37:43.266 loading configuration: already exists
02-Mar-2018 18:37:43.266 exiting (due to fatal error)
```
Compare this with the scenario where the same zone has been declared identically in the view:
...
```
view "another-one" {
match-clients { any; };
zone "yum.co.uk" IN {
type master;
file "yum.co.uk.zone";
};
zone "yum.co.uk" IN {
type master;
file "yum.co.uk.zone";
};
```
```
$ named-checkconf /etc/named.conf
/etc/named.conf:180: zone 'yum.co.uk': already exists previous definition: /etc/named.conf:175
$
```
Which of course is repeated if you try to start named without checking the configuration first:
```
02-Mar-2018 18:51:24.689 loading configuration from '/etc/named.conf'
02-Mar-2018 18:51:24.690 /etc/named.conf:180: zone 'yum.co.uk': already exists previous definition: /etc/named.conf:175
02-Mar-2018 18:51:24.690 loading configuration: failure
02-Mar-2018 18:51:24.690 exiting (due to fatal error)
```
It would be helpful if the in-view zones were included in the same sanity checking as other zone types, and thus generate a more helpful error message (including the line number of named.conf) for the administrator to fix.BIND-9.13.0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/126"make distclean" fails.2018-03-19T22:18:27ZMark Andrews"make distclean" fails."make distclean" fails as some make cannot handle macros that end in '\' which is currently the case for SUBDIR in bin/tests if @PKCS11_TOOLS@ is empty. The last element gets repeated which causes the system directory to be entered twic..."make distclean" fails as some make cannot handle macros that end in '\' which is currently the case for SUBDIR in bin/tests if @PKCS11_TOOLS@ is empty. The last element gets repeated which causes the system directory to be entered twice. This can also cause timing issues when building.
<pre>
-SUBDIRS = atomic db dst master mem hashes names \
- net rbt resolver sockaddr tasks timers system \
- @PKCS11_TOOLS@
+SUBDIR = atomic db dst master mem hashes names net rbt resolver \
+ sockaddr tasks timers system @PKCS11_TOOLS@
</pre>BIND-9.13.0Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/127Add Code Coverage mechanism to BIND2021-09-15T08:30:48ZOndřej SurýAdd Code Coverage mechanism to BINDOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/128mkeys system test fails intermittently2018-03-08T13:09:18ZMichał Kępieńmkeys system test fails intermittentlyThe failure mode below has been observed once so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3026
```
S:mkeys:Tue Mar 6 07:42:47 UTC 2018
T:mkeys:1:A
A:mkeys:System test mkeys
I:mkeys:PORTRANGE:9600 - 9699
I:mkeys:check fo...The failure mode below has been observed once so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3026
```
S:mkeys:Tue Mar 6 07:42:47 UTC 2018
T:mkeys:1:A
A:mkeys:System test mkeys
I:mkeys:PORTRANGE:9600 - 9699
I:mkeys:check for signed record (1)
I:mkeys:check positive validation with valid trust anchor (2)
I:mkeys:check positive validation using delv (3)
I:mkeys:check for failed validation due to wrong key in managed-keys (4)
I:mkeys:check new trust anchor can be added (5)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check new trust anchor can't be added with bad initial key (6)
I:mkeys:ns3 refreshing managed keys for '_default'
I:mkeys:remove untrusted standby key, check timer restarts (7)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:restore untrusted standby key, revoke original key (8)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:refresh managed-keys, ensure same result (9)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:restore revoked key, ensure same result (10)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:reinitialize trust anchors, add second key to bind.keys
I:mkeys:check that no key from bind.keys is marked as an initializing key (11)
I:mkeys:reinitialize trust anchors, revert to one key in bind.keys
I:mkeys:check that standby key is now trusted (12)
I:mkeys:revoke original key, add new standby (13)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:revoke standby before it is trusted (14)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:wait 20 seconds for key add/remove holddowns to expire (15)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:revoke all keys, confirm roll to insecure (16)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check for insecure response (17)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:reset the root server
I:mkeys:reinitialize trust anchors
I:mkeys:check positive validation (18)
I:mkeys:revoke key with bad signature, check revocation is ignored (19)
I:mkeys:ns1 zone reload queued
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check validation fails with bad DNSKEY rrset (20)
I:mkeys:restore DNSKEY rrset, check validation succeeds again (21)
I:mkeys:ns1 zone reload queued
I:mkeys:reset the root server with no keys, check for minimal update (22)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:reset the root server with no signatures, check for minimal update (23)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:restore root server, check validation succeeds again (24)
I:mkeys:ns1 zone reload queued
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:check that trust-anchor-telemetry queries are logged (25)
I:mkeys:check that trust-anchor-telemetry queries are received (26)
I:mkeys:check 'rndc-managed-keys destroy' (27)
I:mkeys:ns2 destroying managed-keys database for '_default'
I:mkeys:check that trust-anchor-telemetry queries contain the correct key (28)
I:mkeys:check initialization fails if managed-keys can't be created (29)
I:mkeys:check failure to contact root servers does not prevent key refreshes after restart (30)
I:mkeys:check key refreshes are resumed after root servers become available (31)
I:mkeys:exceeded time limit waiting for 'Returned from key fetch in keyfetch_done()' in ns5/named.run
I:mkeys:failed
I:mkeys:exit status: 1
R:mkeys:FAIL
E:mkeys:Tue Mar 6 07:44:44 UTC 2018
```
Contents of `bin/tests/system/mkeys/` [attached](/uploads/1d49120036975b1478ae848ad3bc0689/mkeys.tar.gz).BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/129dnssec system test fails intermittently2019-03-11T12:02:07ZMichał Kępieńdnssec system test fails intermittentlyThe failure mode below has been observed 4 times so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3025
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3026
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3048
* https://g...The failure mode below has been observed 4 times so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3025
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3026
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3048
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3078
```
S:dnssec:Tue Mar 6 07:40:18 UTC 2018
T:dnssec:1:A
A:dnssec:System test dnssec
I:dnssec:PORTRANGE:7400 - 7499
I:dnssec:checking that zone transfer worked (1)
I:dnssec:checking AD bit asking for validation (2)
I:dnssec:checking that AD is not set without +adflag or +dnssec (3)
I:dnssec:checking for AD in authoritative answer (4)
I:dnssec:checking positive validation NSEC (5)
I:dnssec:checking postive validation NSEC using dns_client (6)
I:dnssec:checking positive validation NSEC3 (7)
I:dnssec:checking positive validation NSEC3 using dns_client (8)
I:dnssec:checking positive validation OPTOUT (9)
I:dnssec:checking positive validation OPTOUT using dns_client (10)
I:dnssec:checking positive wildcard validation NSEC (11)
I:dnssec:checking positive wildcard validation NSEC using dns_client (12)
I:dnssec:checking positive wildcard answer NSEC3 (13)
I:dnssec:checking positive wildcard answer NSEC3 (14)
I:dnssec:checking positive wildcard validation NSEC3 (15)
I:dnssec:checking positive wildcard validation NSEC3 using dns_client (16)
I:dnssec:checking positive wildcard validation OPTOUT (17)
I:dnssec:checking positive wildcard validation OPTOUT using dns_client (18)
I:dnssec:checking negative validation NXDOMAIN NSEC (19)
I:dnssec:checking negative validation NXDOMAIN NSEC using dns_client (20)
I:dnssec:checking negative validation NXDOMAIN NSEC3 (21)
I:dnssec:checking negative validation NXDOMAIN NSEC3 using dns_client (22)
I:dnssec:checking negative validation NXDOMAIN OPTOUT (23)
I:dnssec:checking negative validation NXDOMAIN OPTOUT using dns_client (24)
I:dnssec:checking negative validation NODATA NSEC (25)
I:dnssec:checking negative validation NODATA OPTOUT using dns_client (26)
I:dnssec:checking negative validation NODATA NSEC3 (27)
I:dnssec:checking negative validation NODATA NSEC3 using dns_client (28)
I:dnssec:checking negative validation NODATA OPTOUT (29)
I:dnssec:checking negative validation NODATA OPTOUT using dns_client (30)
I:dnssec:checking negative wildcard validation NSEC (31)
I:dnssec:checking negative wildcard validation NSEC using dns_client (32)
I:dnssec:checking negative wildcard validation NSEC3 (33)
I:dnssec:checking negative wildcard validation NSEC3 using dns_client (34)
I:dnssec:checking negative wildcard validation OPTOUT (35)
I:dnssec:checking negative wildcard validation OPTOUT using dns_client (36)
I:dnssec:checking 1-server insecurity proof NSEC (37)
I:dnssec:checking 1-server insecurity proof NSEC using dns_client (38)
I:dnssec:checking 1-server insecurity proof NSEC3 (39)
I:dnssec:checking 1-server insecurity proof NSEC3 using dns_client (40)
I:dnssec:checking 1-server insecurity proof OPTOUT (41)
I:dnssec:checking 1-server insecurity proof OPTOUT using dns_client (42)
I:dnssec:checking 1-server negative insecurity proof NSEC (43)
I:dnssec:checking 1-server negative insecurity proof NSEC using dns_client (44)
I:dnssec:checking 1-server negative insecurity proof NSEC3 (45)
I:dnssec:checking 1-server negative insecurity proof NSEC3 using dns_client (46)
I:dnssec:checking 1-server negative insecurity proof OPTOUT (47)
I:dnssec:checking 1-server negative insecurity proof OPTOUT using dns_client (48)
I:dnssec:checking 1-server negative insecurity proof with SOA hack NSEC (49)
I:dnssec:checking 1-server negative insecurity proof with SOA hack NSEC3 (50)
I:dnssec:checking 1-server negative insecurity proof with SOA hack OPTOUT (51)
I:dnssec:checking multi-stage positive validation NSEC/NSEC (52)
I:dnssec:checking multi-stage positive validation NSEC/NSEC3 (53)
I:dnssec:checking multi-stage positive validation NSEC/OPTOUT (54)
I:dnssec:checking multi-stage positive validation NSEC3/NSEC (55)
I:dnssec:checking multi-stage positive validation NSEC3/NSEC3 (56)
I:dnssec:checking multi-stage positive validation NSEC3/OPTOUT (57)
I:dnssec:checking multi-stage positive validation OPTOUT/NSEC (58)
I:dnssec:checking multi-stage positive validation OPTOUT/NSEC3 (59)
I:dnssec:checking multi-stage positive validation OPTOUT/OPTOUT (60)
I:dnssec:checking empty NODATA OPTOUT (61)
I:dnssec:checking failed validation (62)
I:dnssec:checking failed validation using dns_client (63)
I:dnssec:checking that validation fails with a misconfigured trusted key (64)
I:dnssec:checking that negative validation fails with a misconfigured trusted key (65)
I:dnssec:checking that insecurity proofs fail with a misconfigured trusted key (66)
I:dnssec:checking that validation fails when key record is missing (67)
I:dnssec:checking that validation fails when key record is missing using dns_client (68)
I:dnssec:checking that validation succeeds when a revoked key is encountered (69)
I:dnssec:checking that validation succeeds when a revoked key is encountered using dns_client (70)
I:dnssec:Checking that a bad CNAME signature is caught after a +CD query (71)
I:dnssec:Checking that a bad DNAME signature is caught after a +CD query (72)
I:dnssec:checking 2-server insecurity proof (73)
I:dnssec:checking 2-server insecurity proof with a negative answer (74)
I:dnssec:checking 2-server insecurity proof with a negative answer and SOA hack (75)
I:dnssec:checking security root query (76)
I:dnssec:checking cd bit on a positive answer (77)
I:dnssec:checking cd bit on a negative answer (78)
I:dnssec:checking positive validation RSASHA256 NSEC (79)
I:dnssec:checking positive validation RSASHA512 NSEC (80)
I:dnssec:checking positive validation with KSK-only DNSKEY signature (81)
I:dnssec:checking cd bit on a query that should fail (82)
I:dnssec:checking cd bit on an insecurity proof (83)
I:dnssec:checking cd bit on a negative insecurity proof (84)
I:dnssec:checking that validation of an ANY query works (85)
I:dnssec:checking that validation of a query returning a CNAME works (86)
I:dnssec:checking that validation of a query returning a DNAME works (87)
I:dnssec:checking that validation of an ANY query returning a CNAME works (88)
I:dnssec:checking that validation of an ANY query returning a DNAME works (89)
I:dnssec:checking that positive validation in a privately secure zone works (90)
I:dnssec:checking that negative validation in a privately secure zone works (91)
I:dnssec:checking that lookups succeed after disabling a algorithm works (92)
I:dnssec:checking privately secure to nxdomain works (93)
I:dnssec:checking privately secure wildcard to nxdomain works (94)
I:dnssec:checking a non-cachable NODATA works (95)
I:dnssec:checking a non-cachable NXDOMAIN works (96)
I:dnssec:checking dnssec-lookaside-validation works (97)
I:dnssec:checking that we can load a rfc2535 signed zone (98)
I:dnssec:checking that we can transfer a rfc2535 signed zone (99)
I:dnssec:checking that we can sign a zone with out-of-zone records (100)
I:dnssec:checking that we can sign a zone (NSEC3) with out-of-zone records (101)
I:dnssec:checking NSEC3 signing with empty nonterminals above a delegation (102)
I:dnssec:checking that dnsssec-signzone updates originalttl on ttl changes (103)
I:dnssec:checking dnssec-signzone keeps valid signatures from removed keys (104)
I:dnssec:checking dnssec-signzone -R purges signatures from removed keys (105)
I:dnssec:checking dnssec-signzone keeps valid signatures from inactive keys (106)
I:dnssec:checking dnssec-signzone -Q purges signatures from inactive keys (107)
I:dnssec:checking dnssec-signzone retains unexpired signatures (108)
I:dnssec:checking dnssec-signzone purges RRSIGs from formerly-owned glue (nsec) (109)
I:dnssec:checking dnssec-signzone purges RRSIGs from formerly-owned glue (nsec3) (110)
I:dnssec:checking dnssec-signzone output format (111)
I:dnssec:checking TTLs are capped by dnssec-signzone -M (112)
I:dnssec:checking dnssec-signzone -N date (113)
I:dnssec:checking validated data are not cached longer than originalttl (114)
I:dnssec:checking rndc secroots (115)
I:dnssec:checking RRSIG query from cache (116)
I:dnssec:checking RRSIG query not in cache (117)
I:dnssec:checking NSEC3 zone with mismatched NSEC3PARAM / NSEC parameters (118)
I:dnssec:checking optout NSEC3 referral with only insecure delegations (119)
I:dnssec:checking optout NSEC3 NXDOMAIN with only insecure delegations (120)
I:dnssec:checking optout NSEC3 nodata with only insecure delegations (121)
I:dnssec:checking that a zone finishing the transition from RSASHA1 to RSASHA256 validates secure (122)
I:dnssec:checking positive and negative validation with negative trust anchors (123)
I:dnssec:ns4 Negative trust anchor added: bogus.example/_default, expires 06-Mar-2018 07:43:35.000
I:dnssec:ns4 Negative trust anchor added: badds.example/_default, expires 06-Mar-2018 07:43:27.000
I:dnssec:ns4 Negative trust anchor added: secure.example/_default, expires 06-Mar-2018 07:43:28.000
I:dnssec:ns4 Negative trust anchor added: fakenode.secure.example/_default, expires 06-Mar-2018 07:43:29.000
I:dnssec:ns4 server reload successful
I:dnssec:dumping secroots
I:dnssec:waiting for NTA rechecks/expirations
I:dnssec:testing NTA removals (124)
I:dnssec:ns4 Negative trust anchor added: badds.example/_default, expires 06-Mar-2018 07:43:51.000
I:dnssec:remove non-existent NTA three times
I:dnssec:testing NTA with bogus lifetimes (125)
I:dnssec:check with no nta lifetime specified
I:dnssec:check with bad nta lifetime
I:dnssec:check with too long nta lifetime
I:dnssec:testing NTA persistence across restarts (126)
I:dnssec:ns4 Negative trust anchor added: bogus.example/_default, expires 06-Mar-2018 07:44:12.000
I:dnssec:ns4 Negative trust anchor added: badds.example/_default, expires 06-Mar-2018 07:43:53.000
I:dnssec:killing ns4 with SIGTERM
I:dnssec:waiting till 14s have passed since NTAs were added before restarting ns4
I:dnssec:restarted server ns4
I:dnssec:sleeping for an additional 4 seconds for ns4 to fully startup
I:dnssec:testing loading regular attribute from NTA file (127)
I:dnssec:killing ns4 with SIGTERM
I:dnssec:sleeping for an additional 4 seconds for ns4 to fully shutdown
I:dnssec:restarted server ns4
I:dnssec:waiting till 10s have passed after ns4 was restarted
I:dnssec:failed - NTA persistence: loading regular NTAs failed
I:dnssec:testing loading forced attribute from NTA file (128)
I:dnssec:killing ns4 with SIGTERM
I:dnssec:sleeping for an additional 4 seconds for ns4 to fully shutdown
I:dnssec:restarted server ns4
I:dnssec:waiting till 10s have passed after ns4 was restarted
I:dnssec:testing loading out of bounds lifetime from NTA file (129)
I:dnssec:killing ns4 with SIGTERM
I:dnssec:sleeping for an additional 4 seconds for ns4 to fully shutdown
I:dnssec:restarted server ns4
I:dnssec:sleeping for an additional 4 seconds for ns4 to fully startup
I:dnssec:completed NTA tests
I:dnssec:running DNSSEC update test
I:dnssec:Add a name
I:dnssec:Delete the name
I:dnssec:All update tests successful.
I:dnssec:checking managed key maintenance has not started yet (130)
I:dnssec:switching to automatic root key configuration
I:dnssec:checking managed key maintenance timer has now started (131)
I:dnssec:checking positive validation NSEC (132)
I:dnssec:checking positive validation NSEC3 (133)
I:dnssec:checking positive validation OPTOUT (134)
I:dnssec:checking negative validation (135)
I:dnssec:checking that root DS queries validate (136)
I:dnssec:checking that DS at a RFC 1918 empty zone lookup succeeds (137)
I:dnssec:checking expired signatures remain with "allow-update { none; };" and no keys available (138)
I:dnssec:checking expired signatures do not validate (139)
I:dnssec:checking that the NSEC3 record for the apex is properly signed when a DNSKEY is added via UPDATE (140)
I:dnssec:checking that the NSEC record is properly generated when DNSKEY are added via auto-dnssec (141)
I:dnssec:checking that the NSEC3 record is properly generated when DNSKEY are added via auto-dnssec (142)
I:dnssec:checking that signing records have been marked as complete (143)
I:dnssec:check that 'rndc signing' without arguments is handled (144)
I:dnssec:check that 'rndc signing -list' without zone is handled (145)
I:dnssec:check that 'rndc signing -clear' without additional arguments is handled (146)
I:dnssec:check that 'rndc signing -clear all' without zone is handled (147)
I:dnssec:check that 'rndc signing -nsec3param' without additional arguments is handled (148)
I:dnssec:check that 'rndc signing -nsec3param none' without zone is handled (149)
I:dnssec:check that 'rndc signing -nsec3param 1' without additional arguments is handled (150)
I:dnssec:check that 'rndc signing -nsec3param 1 0' without additional arguments is handled (151)
I:dnssec:check that 'rndc signing -nsec3param 1 0 0' without additional arguments is handled (152)
I:dnssec:check that 'rndc signing -nsec3param 1 0 0 -' without zone is handled (153)
I:dnssec:check that 'rndc signing -nsec3param' works with salt (154)
I:dnssec:check that 'rndc signing -nsec3param' works without salt (155)
I:dnssec:check that 'rndc signing -nsec3param' works with 'auto' as salt (156)
I:dnssec:check that 'rndc signing -nsec3param' with 'auto' as salt again generates a different salt (157)
I:dnssec:check rndc signing -list output (158)
I:dnssec:clear signing records (159)
I:dnssec:checking that a insecure zone beneath a cname resolves (160)
I:dnssec:checking that a secure zone beneath a cname resolves (161)
I:dnssec:checking dnskey query with no data still gets put in cache (162)
I:dnssec:check that a split dnssec dnssec-signzone work (163)
I:dnssec:check that a smart split dnssec dnssec-signzone work (164)
I:dnssec:check that NOTIFY is sent at the end of NSEC3 chain generation (165)
I:dnssec:sleeping ....
I:dnssec:sleeping ....
I:dnssec:check dnssec-dsfromkey from stdin (166)
I:dnssec:check dnssec-dsfromkey error message when keyfile is not found (167)
I:dnssec:testing soon-to-expire RRSIGs without a replacement private key (168)
I:dnssec:testing new records are signed with 'no-resign' (169)
I:dnssec:testing expiring records aren't resigned with 'no-resign' (170)
I:dnssec:testing updates fail with no private key (171)
I:dnssec:testing legacy upper case signer name validation (172)
I:dnssec:testing that we lower case signer name (173)
I:dnssec:testing TTL is capped at RRSIG expiry time (174)
I:dnssec:ns3 zone reload queued
I:dnssec:testing TTL is capped at RRSIG expiry time for records in the additional section (175)
I:dnssec:testing TTL of about to expire RRsets with dnssec-accept-expired yes; (176)
I:dnssec:testing TTL of expired RRsets with dnssec-accept-expired yes; (177)
I:dnssec:testing TTL is capped at RRSIG expiry time for records in the additional section with dnssec-accept-expired yes; (178)
I:dnssec:testing DNSKEY lookup via CNAME (179)
I:dnssec:testing KEY lookup at CNAME (present) (180)
I:dnssec:testing KEY lookup at CNAME (not present) (181)
I:dnssec:testing DNSKEY lookup via DNAME (182)
I:dnssec:testing KEY lookup via DNAME (183)
I:dnssec:check that named doesn't loop when all private keys are not available (184)
I:dnssec:check against against missing nearest provable proof (185)
I:dnssec:check that key id are logged when dumping the cache (186)
I:dnssec:check KEYDATA records are printed in human readable form in key zone (187)
I:dnssec:check dig's +nocrypto flag (188)
I:dnssec:check simultaneous inactivation and publishing of dnskeys removes inactive signature (189)
I:dnssec:check that increasing the sig-validity-interval resigning triggers re-signing (190)
I:dnssec:check insecure delegation between static-stub zones (191)
I:dnssec:check the acceptance of seconds as inception and expiration times (192)
I:dnssec:check the correct resigning time is reported in zonestatus (193)
I:dnssec:check that split rrsigs are handled (194)
I:dnssec:check that 'dnssec-keygen -S' works for all supported algorithms (195)
I:dnssec:check that CDS records are signed using KSK by dnssec-signzone (196)
I:dnssec:check that CDS records are not signed using ZSK by dnssec-signzone -x (197)
I:dnssec:checking that positive unknown NSEC3 hash algorithm does validate (198)
I:dnssec:check that CDS records are signed using KSK by with dnssec-auto (199)
I:dnssec:check that a lone non matching CDS record is rejected (200)
I:dnssec:check that CDS records are signed using KSK when added by nsupdate (201)
I:dnssec:check that CDS records are signed only using KSK when added by
I:dnssec:nsupdate when dnssec-dnskey-kskonly is yes (202)
I:dnssec:checking that positive unknown NSEC3 hash algorithm with OPTOUT does validate (203)
I:dnssec:check that a non matching CDS record is accepted with a matching CDS record (204)
I:dnssec:checking that negative unknown NSEC3 hash algorithm does not validate (205)
I:dnssec:check that CDNSKEY records are signed using KSK by dnssec-signzone (206)
I:dnssec:check that CDNSKEY records are not signed using ZSK by dnssec-signzone -x (207)
I:dnssec:checking that negative unknown NSEC3 hash algorithm with OPTOUT does not validate (208)
I:dnssec:check that CDNSKEY records are signed using KSK by with dnssec-auto (209)
I:dnssec:checking that unknown DNSKEY algorithm validates as insecure (210)
I:dnssec:check that a lone non matching CDNSKEY record is rejected (211)
I:dnssec:checking that unknown DNSKEY algorithm + unknown NSEC3 has algorithm validates as insecure (212)
I:dnssec:check that CDNSKEY records are signed using KSK when added by nsupdate (213)
I:dnssec:check that CDNSKEY records are signed only using KSK when added by
I:dnssec:nsupdate when dnssec-dnskey-kskonly is yes (214)
I:dnssec:checking initialization with a revoked managed key (215)
I:dnssec:check that a non matching CDNSKEY record is accepted with a matching CDNSKEY record (216)
I:dnssec:check that RRSIGs are correctly removed from apex when RRset is removed NSEC (217)
I:dnssec:check that RRSIGs are correctly removed from apex when RRset is removed NSEC3 (218)
I:dnssec:check that a named managed zone that was signed 'in-the-future' is re-signed when loaded (219)
I:dnssec:check that trust-anchor-telemetry queries are logged (220)
I:dnssec:check that _ta-XXXX trust-anchor-telemetry queries are logged (221)
I:dnssec:check that _ta-AAAA trust-anchor-telemetry are not sent when disabled (222)
I:dnssec:check that KEY-TAG trust-anchor-telemetry queries are logged (223)
I:dnssec:check that the view is logged in messages from the validator when using views (224)
I:dnssec:exit status: 1
R:dnssec:FAIL
E:dnssec:Tue Mar 6 07:46:29 UTC 2018
```
Contents of `bin/tests/system/dnssec/` from the first 3 jobs listed above are [attached](/uploads/0c726aec02894931d792e765804347b9/dnssec.tar.gz).BIND 9.13.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/130Use ccache to speed-up Gitlab CI builds2018-03-08T14:22:12ZOndřej SurýUse ccache to speed-up Gitlab CI buildsOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/131Add util/check-changes to CI for master2018-03-08T02:24:42ZMark AndrewsAdd util/check-changes to CI for masterhttps://gitlab.isc.org/isc-projects/bind9/-/issues/132fix changes entry2018-03-08T01:57:39ZMark Andrewsfix changes entryhttps://gitlab.isc.org/isc-projects/bind9/-/issues/133Update util/check-changes to work on release branches.2018-03-08T10:16:40ZMark AndrewsUpdate util/check-changes to work on release branches.https://gitlab.isc.org/isc-projects/bind9/-/issues/134Crash in BIND 9.12.0-RedHat-9.12.0-1.el7.02019-04-26T09:49:56ZJakob DhondtCrash in BIND 9.12.0-RedHat-9.12.0-1.el7.0I'd like to report a crash on a production host (ns2.switch.ch).
All the necessary info can be found here: [REDACTED]
Thanks,
JakobI'd like to report a crash on a production host (ns2.switch.ch).
All the necessary info can be found here: [REDACTED]
Thanks,
JakobMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/135Add basic unit tests for update_sigs()2018-05-10T16:50:52ZMichał KępieńAdd basic unit tests for update_sigs()The static [`update_sigs()`](https://gitlab.isc.org/isc-projects/bind9/blob/c9f4bdde949dd337f900f47995537076d2370d1d/lib/dns/zone.c#L7345-7391) function could use some basic unit tests so that it can be safely [refactored](!10).The static [`update_sigs()`](https://gitlab.isc.org/isc-projects/bind9/blob/c9f4bdde949dd337f900f47995537076d2370d1d/lib/dns/zone.c#L7345-7391) function could use some basic unit tests so that it can be safely [refactored](!10).BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/136cds system test fails intermittently2018-03-19T22:15:52ZMichał Kępieńcds system test fails intermittentlyThe failure mode below has been observed 2 times so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3108
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3340
```
S:cds:Tue Mar 6 15:58:36 UTC 2018
T:cds:1:A
A:cds:System test...The failure mode below has been observed 2 times so far:
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3108
* https://gitlab.isc.org/isc-projects/bind9/-/jobs/3340
```
S:cds:Tue Mar 6 15:58:36 UTC 2018
T:cds:1:A
A:cds:System test cds
I:cds:PORTRANGE:6200 - 6299
I:cds:usage (1)
I:cds:need a DS file (2)
I:cds:name of dsset in directory (3)
I:cds:load a file (4)
I:cds:load DS records (5)
I:cds:missing DNSKEY (6)
I:cds:sigs too old (7)
I:cds:sigs too old, verbosely (8)
I:cds:old sigs are allowed (9)
I:cds:no CDS/CDNSKEY records (10)
I:cds:no child records, verbosely (11)
I:cds:unsigned CDS (12)
I:cds:correct signature inception time (13)
I:cds:in-place reads modification time (14)
I:cds:in-place output correct modification time (15)
D:stderr did not match ''
D:bad mtime 3610 at checkmtime.pl line 15.
I:cds:failed
D:exit status does not match 0
I:cds:failed
I:cds:in-place backup correct modification time (16)
D:stderr did not match ''
D:bad mtime 7210 at checkmtime.pl line 15.
I:cds:failed
D:exit status does not match 0
I:cds:failed
I:cds:in-place correct output (17)
I:cds:in-place backup unmodified (18)
I:cds:one mangled DS (19)
I:cds:other mangled DS (20)
I:cds:both mangled DS (21)
I:cds:mangle RRSIG CDS by ZSK (22)
I:cds:mangle RRSIG CDS by KSK (23)
I:cds:mangle CDS 1 (24)
I:cds:inconsistent digests (25)
I:cds:inconsistent algorithms (26)
I:cds:add DS records (27)
I:cds:update add (28)
I:cds:remove DS records (29)
I:cds:update del (30)
I:cds:swap DS records (31)
I:cds:update swap (32)
I:cds:TTL from -T (33)
I:cds:update TTL from -T (34)
I:cds:update TTL from dsset (35)
I:cds:TTL from -T overrides dsset (36)
I:cds:stable DS record order (changes) (37)
I:cds:CDNSKEY default algorithm (38)
I:cds:CDNSKEY SHA1 (39)
I:cds:CDNSKEY two algorithms (40)
I:cds:CDNSKEY two algorithms, reversed (41)
I:cds:CDNSKEY and CDS (42)
I:cds:prefer CDNSKEY (43)
I:cds:exit status: 4
R:cds:FAIL
E:cds:Tue Mar 6 15:59:05 UTC 2018
```
Contents of `bin/tests/system/cds/` from both jobs listed above are [attached](/uploads/9472df3aa2bfa776e40e1a8ae20737c6/cds.tar.gz).BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/137Remove support for systems without ftello/fseeko2018-03-19T22:14:27ZOndřej SurýRemove support for systems without ftello/fseeko`fseeko` and `ftello` conforms to SUSv2, POSIX.1-2001. The `configure.in` says:
```
# BSDI doesn't have ftello fseeko
AC_CHECK_FUNCS(ftello fseeko)
```
The last version of BSD/OS was released in 2003, henceforth I believe it's safe to...`fseeko` and `ftello` conforms to SUSv2, POSIX.1-2001. The `configure.in` says:
```
# BSDI doesn't have ftello fseeko
AC_CHECK_FUNCS(ftello fseeko)
```
The last version of BSD/OS was released in 2003, henceforth I believe it's safe to remove this workaround.BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/138Tweak CI settings2018-03-09T17:13:27ZMichał KępieńTweak CI settingsOur current CI configuration has two issues described below.
# ccache is used ineffectively
`gitlab-runner` cache is effectively a ZIP file passed between jobs. Creating a ZIP archive containing a ccache directory, potentially contain...Our current CI configuration has two issues described below.
# ccache is used ineffectively
`gitlab-runner` cache is effectively a ZIP file passed between jobs. Creating a ZIP archive containing a ccache directory, potentially containing hundreds of thousands of files taking up several gigabytes of storage space is a bad idea.
Our current CI configuration also causes the ccache directory to be treated as a build artifact, which only makes things worse.
What we should do instead is to stop using the `cache` directive altogether, create a ccache directory on each runner and mount it inside containers. This will allow ccache data to persist between jobs without requiring it to be packed into a ZIP file at the end of each job.
As a side note for posterity, it is critical for `/etc/gitlab-runner/config.toml` to contain `volumes = ["/cache"]` for the `cache` directive to actually work, at least with Docker. Otherwise, `gitlab-runner` will just create a ZIP file when a job is finished, store it in `/cache/<namespace>/<project>` and then tear the container down, obliterating the cache it just created. Adding the `volume` line mentioned above causes `/cache` to be persisted.
# `make` uses fixed concurrency settings
Our CI jobs currently always use `make -j6` for building and `make -j8` for running system tests. Meanwhile, concurrency settings need to be tweaked separately for each runner to ensure stability. We should modify our `.gitlab-ci.yml` to fetch the number of parallel `make` jobs to use from environment variables which will subsequently be set by each runner through its configuration file.
There are three rules I can think of for tweaking concurrency-related settings:
1. With ccache being used, building becomes more (though not fully, of course) I/O-bound than CPU-bound.
1. As a rule of thumb, it should be assumed that each parallel system test being executed uses about 0.5 GB of RAM.
1. Currently, total system test execution time plateaus around `make -j8` because some tests just take a *long* time to run.
Apart from the above, the number of concurrent jobs `make` is allowed to use while building and testing has to be considered together with the `concurrent` setting in `/etc/gitlab-runner/config.toml` which limits the number of CI jobs allowed to be run concurrently at any time on a given runner.
Considering the above, an optimal CI machine would have:
* **8+ CPU cores**: 8 cores allow concurrent compilation for two OS images using `make -j4` without putting to much strain on the host (ccache storage is not infinite, so we cannot rely on everything being cached beforehand), which sounds like a bare minimum; more cores would enable quicker pipeline completion in case multiple branches and/or more OS images are to be processed concurrently,
* **fast storage** (or lots of RAM, so that ramdisks can be used for ccache data and/or compilation), to let ccache shine,
* **more than 8 GB of RAM**: with tests for two OS images running concurrently, each image using `make -j8`, top RAM utilization around 8 GB may occur (2 * 8 * 0.5), which would lead to swapping; the more RAM the machine has, the more concurrent test phase jobs (e.g. for different branches and/or different OS images) it will be able to handle (though more RAM itself will not cause system tests to complete faster because increasing the number of parallel jobs used while testing beyond 8 has virtually no effect).
In any case, there are a few trade-offs to consider here, so allowing runner-specific concurrency settings in our `.gitlab-ci.yml` sounds like a good idea no matter what machine(s) we will be using for CI in the end.Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/139Tests for IDNA2008 (libidn2)2018-04-04T13:52:44ZOndřej SurýTests for IDNA2008 (libidn2)The following discussion from !56 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/56#note_4595):
> This mostly looks fine to me (after the nits being fixed), but t...The following discussion from !56 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/56#note_4595):
> This mostly looks fine to me (after the nits being fixed), but the biggest issue before merging the code would be having tests for the code.
>
> Could you come up with couple of tests cases (IDNA2008 compliant, and also some tests that should "fail" because the encoding is broken, etc.) and either write the tests yourself (preferred :)), or just shove it to us and we'll take care of the tests. But they need to be present before the final merge.BIND-9.13.0Stephen MorrisStephen Morrishttps://gitlab.isc.org/isc-projects/bind9/-/issues/140Add safeguards to dnssec key utilities2021-10-04T12:31:48ZBrian ConryAdd safeguards to dnssec key utilitiesWarn when generating DS records for new keys with a different set of algorithm types than the current set of DS recordsWarn when generating DS records for new keys with a different set of algorithm types than the current set of DS recordshttps://gitlab.isc.org/isc-projects/bind9/-/issues/141RT 43435 - Upload BIND Python module to pypi, package for BIND users2021-10-04T12:33:06ZVicky Riskvicky@isc.orgRT 43435 - Upload BIND Python module to pypi, package for BIND usersRT 43435 - text below is migrated from bugsRT
On Wed, May 3, 2017 at 1:04 PM, Vicky Risk via RT <bind9-bugs@isc.org> wrote:
We discussed uploading a python module for BIND to the pypi repository in our development meeting today. ... ...RT 43435 - text below is migrated from bugsRT
On Wed, May 3, 2017 at 1:04 PM, Vicky Risk via RT <bind9-bugs@isc.org> wrote:
We discussed uploading a python module for BIND to the pypi repository in our development meeting today. ... The open question we are considering is whether to submit just the RNDC components, or <more>. I think Evan is wondering whether it might cause user confusion having multiple different copies of the python library (assuming they are also running BIND).
.......
I wasn't aware the python library was going to be distributed with BIND... but here are some thoughts on that:
A very common (nearly standard) way of operating with python is to work inside what's referred to as a "python virtual environment," or virtualenv/venv. In this environment, libraries and other python packages required by one's work can be installed without interfering with the system packages.. this is very important, for example, when working on tools that have conflicting package (version) requirements.
The packages inside a venv are typically installed using 'pip'.. the python package manager that uses pypi as its back-end.
Getting something installed into a venv that is not on pypi is irritating at best, and occasionally difficult to do. This is especially true for automated deployments where the virtualenv is used in production operations.
For a real-world example, the ldns python bindings are only shipped with the ldns source code, and not in pypi, and as a result I need to have a very compelling reason to need them over any other DNS library (and over just shelling out to an ldns binary) in order to deal with the complexities of working with them.
To view this from another angle: If BIND's 'make install' places the RNDC python libraries on the system in such a way that they're visible to/registered with pip, then end users aren't going to find anything confusing .. because as far as pip is concerned it doesn't matter where the library came from. If the RNDC python library is not visible to/registered with pip, then BIND shouldn't be installing it that way.. it will cause confusion regardless of whether the library is available on pypi or not.
--------
Adding Matt Pounsett as stakeholder, because he has offered us a package that includes just the python RNDC stuff that is ready to upload.
Matt, I can’t find the email from you about the Python package for the BIND RNDC interface. Did you submit it to bind-bugs@isc.org? If you want to reply to this ticket and attach it, it will be easier for us to find it to work on.
I didn't.. this started as a conversation with Ray, and so I emailed him about it. The work I've done so far is in a private repo on github. Github, because it seemed a reasonable place to work on it, and private so that I don't inadvertently share it with anyone other than ISC prior to ISC applying a license to it.
My email to Ray included an offer to add ISC employees' accounts to access the repository and/or hand over full ownership of the repository. Whichever you like. The repo is at <https://github.com/mpounsett/rndc> but that won't be accessible until we do something with access.
There are still a few small steps to be taken before it's ready for upload: notably decisions I couldn't make on behalf of ISC about licensing, development status indicators, etc.https://gitlab.isc.org/isc-projects/bind9/-/issues/142add more checks to precheck CI stage2018-08-24T20:18:53ZEvan Huntadd more checks to precheck CI stageIt should also call util/checklibs.sh, to make sure that needed include files are present and .def files are up to date.
It could also check xmllint when documentation is updated, look for $Id$ tags that haven't been removed, etc.It should also call util/checklibs.sh, to make sure that needed include files are present and .def files are up to date.
It could also check xmllint when documentation is updated, look for $Id$ tags that haven't been removed, etc.