BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-06T18:18:23Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4593Deprecate sortlist2024-03-06T18:18:23ZMichal NowakDeprecate sortlistThe following discussion from !8684 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8684#note_433409): (+1 comment)
> Can we also deprecate the feature? It's su...The following discussion from !8684 should be addressed:
- [ ] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8684#note_433409): (+1 comment)
> Can we also deprecate the feature? It's such an obscure thing ...
- @ondrej commented:
> That would be 9.21+May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4427Various improvements to hashing and hash table management2024-02-24T08:19:32ZMichał KępieńVarious improvements to hashing and hash table managementThis is a meta issue to keep track of various improvements to hashing
and hash table management that were implemented since ~"v9.18".
Sparked by a [Mattermost discussion][1].
---
- [x] #4306/!8288 Implement incremental hashing
---
...This is a meta issue to keep track of various improvements to hashing
and hash table management that were implemented since ~"v9.18".
Sparked by a [Mattermost discussion][1].
---
- [x] #4306/!8288 Implement incremental hashing
---
[1]: https://mattermost.isc.org/isc/pl/rsyemrkwhtfcbxhtyxddhkn58yMay 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/3878Missing and undocumented statistics from the HTTP stats channel in the ARM2023-11-02T16:30:30ZPieter LexisMissing and undocumented statistics from the HTTP stats channel in the ARMHi folks,
I'm implementing a new monitoring solution and adding a bunch of stats from the HTTP-based stats channel to said monitoring solution. I'm basing the descriptions on what I can find in the ARM section 8.5 (I'm using the one fro...Hi folks,
I'm implementing a new monitoring solution and adding a bunch of stats from the HTTP-based stats channel to said monitoring solution. I'm basing the descriptions on what I can find in the ARM section 8.5 (I'm using the one from 9.18 and 9.19), but some stats are missing there. Some of them are self-evident based on the name, but some are not. I've compiled a list here, the naming is based on the JSON from the webserver:
* nsstats.TCPConnHighWater
* nsstats.SynthNXDOMAIN
* nsstats.CookieNew
* nsstats.CookieIn
* in view.NAME.resolver.stats
* BucketSize
* ClientCookieOut
* ServerCookieOut
* CookieIn
* CookieClientOk
* BadCookieRcode
* NextItem
* Priming
* traffic
The following stats are mostly unclear:
* view.NAME.resolver.cachestats - none of these statistics are described
* view.NAME.resolver.adb - none of these statistics are described
* opcodes.CODE - Are these the counts of received opcodes from clients?
* rcodes.CODE - Are these the counts of rcodes sent to clients?
* qtypes.CODE - Are these the counts of qtypes that were queried by clients?
* view.NAME.resolver.qtypes - what do these numbers mean?
* view.NAME.resolver.cache - Are the current cache entries for these types?
Cheers,
PieterNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3775update-policy documentation confuses2023-01-09T11:29:01ZTimothe Littupdate-policy documentation confusesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3763rndc documentation misses a feature; rndc-confgen still uses md52023-01-05T21:28:34ZTimothe Littrndc documentation misses a feature; rndc-confgen still uses md5The code is (mostly) willing, but the documentation is weak :-(
I finally noticed that the rndc [documentation](https://bind9.readthedocs.io/en/v9_18_10/manpages.html#rndc-conf-rndc-configuration-file) describes rndc.conf as
> "has a si...The code is (mostly) willing, but the documentation is weak :-(
I finally noticed that the rndc [documentation](https://bind9.readthedocs.io/en/v9_18_10/manpages.html#rndc-conf-rndc-configuration-file) describes rndc.conf as
> "has a similar structure and syntax to `named.conf`".
This is true, but omits a valuable feature:
`include` works in `rndc.conf`.
It turns out that this is useful if you ever need (or want) to rotate keys, since a (suitably protected) .key file can be `include`d in `rndc.conf` and likewise `include`d in `named.conf`.
In any case, this structure avoids duplication of the secret key; makes updating the key simpler, and allows `rndc.conf` to have read permissions - thus making the `options` clause visible, which may be desirable. It also means that if you use unique keys for more than one `named` instance, you can simply move the key file to your management stations, but retain the default-server without editing each station's `rndc.conf`.
For example:
```sh
named.conf
# Define the rndc control key
include "rndc.key";
cat >/etc/named/rndc.conf
include "rndc.key";
options {
default-server: 2001:0db8::53;
default-port: 953;
};
# Now, updating and initial key creation becomes simply:
touch /etc/named/rndc.key
chmod 600 /etc/named/rndc.key
tsig-keygen -a sha256 rndc-key >/etc/named/rndc.key
rndc reconfig
```
No more copying the `key` clause into both files, or including in `named.conf` but copying into `rndc.conf`.
For extra credit - `rndc-confgen` should probably produce this structure, since it's better than the current suggestions.
`rndc-confgen` should definitely be updated to default to SHA256 rather than MD5, since MD5 is deprecated and the documentation says (under the `key` statment) that SHA256 is now the default...
Happy New Year.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3434Define grammar for duration (and other elements) in the ARM2022-07-30T13:31:23ZPetr Špačekpspacek@isc.orgDefine grammar for duration (and other elements) in the ARMThe ARM does not define all grammar elements used through the text. I think the most complicated one which is missing is duration (TTL + ISO 8601 styles). ACL is defined in its own chapter so that one is somehow covered.
Terms missing i...The ARM does not define all grammar elements used through the text. I think the most complicated one which is missing is duration (TTL + ISO 8601 styles). ACL is defined in its own chapter so that one is somehow covered.
Terms missing in the ARM at the moment (commit 788aa4b12f0af3dae08c07dc79a6a13d2d768806):
```
$ diff -U0 <(grep --no-filename --only '<[^>]*>' doc/misc/options doc/misc/*.zoneopt | sort -u | tr -d '<>') <(grep '^ ``[^`]*``$' doc/arm/reference.rst | tr -d ' `' | sort -u) | grep '^-'
-address_match_element
-class
-duration
-duration_or_unlimited
-log_severity
-quoted_string
-rrtypelist
-string
-syslog_facility
-unspecified-text
```
Elements used by grammar:
```
$ grep --no-filename --only '<[^>]*>' doc/misc/options doc/misc/*.zoneopt | sort -u | tr -d '<>'
address_match_element
boolean
class
duration
duration_or_unlimited
fixedpoint
integer
ipv4_address
ipv6_address
log_severity
netprefix
percentage
portrange
quoted_string
remote-servers
rrtypelist
server_key
size
sizeval
string
syslog_facility
unspecified-text
```
Terms defined in the ARM (roughly!):
```
$ grep '^ ``[^`]*``$' doc/arm/reference.rst | tr -d ' `' | sort -u
acl_name
address_match_list
any
boolean
domain_name
dscp
fixedpoint
integer
ip_address
ipv4_address
ipv6_address
localhost
localnets
masters
netprefix
none
percentage
port
portrange
remote-servers
server_key
size
sizeval
tls_id
```https://gitlab.isc.org/isc-projects/bind9/-/issues/3169Proposal for changes to the BIND ARM (meta)2023-11-13T14:52:56ZVicky Riskvicky@isc.orgProposal for changes to the BIND ARM (meta)
Following is a list of ideas about how we could make the BIND ARM more user-friendly, written by Ron Aitchinson. It is copied from an email thread, apologies in advance for anything that doesn't make sense. I am putting this into an is...
Following is a list of ideas about how we could make the BIND ARM more user-friendly, written by Ron Aitchinson. It is copied from an email thread, apologies in advance for anything that doesn't make sense. I am putting this into an issue for transparency, and to allow for feedback and input - presumably actual changes would have separate issues associated with them.
- fix the red-colored text styling for commands (anti-accessibility). NB this is part of the ReadTheDocs theme. We could deviate from the theme, but it is surprising to me nobody else is upset about this, because there are accessibility people poking at Sphinx. There is also a specific 'accessibility' theme.....)
- (I) below, means 'do these first'
Chapter 1 - About the DNS, or Terminology or Background....
=========
1. Addition of some diagrams in section 1.4. (We need to discuss how to make diagrams that will be editable/maintainable.)
1. (I) Section 1.4 could usefully discuss the query process (brings in the whole DNS hierarchy thing).
1. (I) Specifically the functional difference between name serving and resolving (maybe with a diagram) should be brought out - a lot of understanding flows from this and a lot of poor configuration is due to user failure to understand the key differences.
1. Too many people get confused over the primary and secondary since the terms imply an order of access - this needs to be noted and explained. I cannot count the number of emails on this topic I have answered over the years.
1. (I) Addition of section 1.5 titled DNS Security and Threat Considerations or something similar (with diagram). Section to overview the various threats to an operational system and the methods used to mitigate them. No detail just links to appropriate sections. Includes Open Resolvers, DDoS, MiM, cache pollution etc, etc, 1 (classic) page max.
Chapter 2 - Installation or Getting Started
=========
1. Remove section 2.7 to Chapter 10 (or make an appendix) this a vital section specifically for those with non-standard requirements. Residual text should refer to packages RPMs, ports etc and link to build chapter. The reason for the move - if a newbie hits this early on it may scare the beejesus out of them which can suppress learning speed drastically.
Chapter 3 (DNS Configurations and Zone Files?)
=========
1. (I) named.conf as far as I can tell automagically appears in the ARM - it is never explained (I still recall my problems with this trivial point when the world was very young.) Either the intro here or 1.4 should be modified (trivially) to cover the basic files used by BIND.
1. (I) Separation of authoritative server examples into primary and secondary. There is some useful text in 1.4 that will help. Copy here.
1. (I) Move NOTIFY (5.1) to this chapter - unchanged (maybe).
1. (I) Add a forwarding example
1. Stealth servers? (move 5.4 unchanged)
1. Essential zone files (local loopback, RFC1918 IPs rtc.) for both authoritative and resolver to reduce mal-configuration? Hints file? or do we drop the pretense that it is even necessary these days.
1. Move all the material on zone files (4.3) in here unchanged? Current chapter 4 is already huge and since we are not covering RRs entirely it is not, technically, a reference (picky, picky).
Chapter 4 (new) DNS Operations.
==============================
1. (I) Move and renumber 3.3 and 3.4 here unchanged.
1. I note that the tools man pages are also maintained in sphinx (and presumably in the copy provided for release as well as online). I think either we just list all the utilities with a link or better still copy the description section of the man page for each tool with a link (how often does the description change though better if we could automate the process).
1. Think Dig and RNDC should be in here as well as the man pages (maybe nslookup) as frequently used tools.
Chapter 5 (Renumbered) Advanced DNS
=========
1. (I) add reference to chapter 10 to current 5.11 (or move whole section to 10).
1. add DNS over TLS or to chapter 6?
1. DDDS Emun example?
1. RPZ (two pages here on this topic that may be helpful are https://www.zytrax.com/books/dns/ch7/rpz.html and https://www.zytrax.com/books/dns/ch9/rpz.html)
- which RA is happy to contribute as a starting point - Evan can do the extensive editing required!!
- rate-limiting
Chapter 6 New - Securing DNS Operations (or something)
=========
1. Hardening DNS configurations (some stuff along NIST lines/RA book)
1. (I) move 5.5, 5.6 and 5.7 here
Chapter 7 New - DNSSEC
=========
1. (I) 5.9 and 5.10 here or move DNSSEC appendix here or both! Your call entirely. Tactically I would like to see all DNSSEC material here since appendices are typically regarded as afterthoughts or of lesser importance. Impressions matter.
Chapter 8 Configuration Reference
=================================
1. (I) Intro to named.conf. Grammer layout rules etc. with and without views etc.
1. (I) In named.conf there are only three things (highly technical term)
i. directive - really only one 'include' which causes BIND to perform an action during its parameter file building phase.
ii. entities or statements or commands or items (check a dictionary - don't care which term is used as long as there is only one term used for everything (currently defined as clause, a statement, an option, a substatement and a phrase) - definition is as entity modifies bind behavior, may contain parameters that affect its operation and which cannot contain other entities (or statements or...).
iii. clause (see no alternative to this, possibly container but that has specific OO connotations) - definition is that clauses do not affect bind behavior, may have an associated name, have no parameters and can be either empty or contain statements (or entities or...)
1. (I) Clauses - simple list with brief explanation of use and link to detailed explanation. Largely as present.
1. (I) Layout of statements (or whatever the damned name is) (see my original Bind9 book page 302 onward for an implementation
My categories were (2/3 char code possibly for space)
- Queries - statements relating to query operations
- Transfers- statements relating to zone transfer operations
- Logging - statements relating to logging operations
- Server - bit flakey, typically statements that can only appear in a server clause which tend to be pretty unique
- Zone - statements used to define zone properties or characteristics
- Security - statements that affect or control BIND security
- Views - statements that control the use of view clauses (only three)
- Resolver - statements that relate to the resolver library (may now be redundant view, ndots and search)
- Controls - only one (inet) in this category but the purest in me would not let me categorize it under operations and security which may be more sensible.
- Operations - (a.k.a. the bucket) statements that affect BIND operational characteristics or control its use of resources.
So, there are 5 bits of data that should be associated with each statement in the initial index table
1. the statement name (alphabetic order)
1. the category,
1. what clause(s) it can be used in ( 1 o2 2 char clause codes can be used)
1. a brief explanation and the default value (due to the constraints of my publisher I had to use two tables, one just for clauses - real maintenance pain).
Here is a single example to illustrate (life is too short to do two) it would appear as a single line in a table with clickable links on name, category, each of the clauses (lotta links):
allow-transfer | Transfers | O, V, Z | Defines an address_match_list (linked) that is allowed to transfer the zone information from this server. The default behavior is to allow zone transfer to any host.
Clicking the name link will take you directly to the statement description (statements are defined in alphabetic order under category so the user can browse). Clicking the category link will take you to either the first entry in the alphabetic order under category - least effort or to a simple list of statement names which can be clicked to go to the statement (too much work?). Clicking on the clause code(s) will go to the clause definition.
This structure works for raw text and hyperlinked documents - clearly navigation is trivial with hyperlinks.
Statement description should progressively have examples added. See specimen of my web descriptions here:
top level reference:https://www.zytrax.com/books/dns/ch7/
Queries list: https://www.zytrax.com/books/dns/ch7/queries.html
Descriptions include the formal syntax, may include one or more specific example(s) and additional text which can vary from a couple of lines to very lengthy text (see sortlist) depending on complexity or the statement nuances.
I did not use the tabular index of my book for my web pages (it's a brutal job) primarily because of the difficulty in keeping it up to date. You have significant advantages here since the developers know when they change something and can automatically update or add material to the source document. I was simply a passive recipient of BIND data which had, in my experience, variable quality of 'changes from previous release' material - the only way for me to be safe method for me to maintain the index would have been to look at every statement every release - meh.
My take here is that I could contribute my web material for the initial release and that each release adds some more where necessary (many are perfectly OK now).
Chapter 9 Renumbered TroubleShooting
====================================
1. (I) Reference to Dig/nslookup and documenting all config files (?)
1. some log examples
1. logging statement reference (with link)
Chapter 10 Building Bind 9
===========================
1. (I) ex 2.7 unchanged
**Appendices** - unchanged except for a decision about DNSSEC
I am conflicted about whether to separate out Dynamic DNS (currently 5.2) into a separate chapter since more people are using the capability. It may well grow and DNSSEC plus DDNS is a bit of a game changer - certainly people may look for it at the top level (chapter) names. (Chapter names are important since its the first level search (and read the docs does a first rate job here).) Certainly a really good index would overcome many problem but we do not currently have one and it would be brutal work if there is no good tool. I tried typing in dynamic update to the search feature in readthedocs and got ..... squat.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3758Revisit BIND features to prevent the scenario where a second BIND instance is...2023-01-02T14:18:27ZCathy AlmondRevisit BIND features to prevent the scenario where a second BIND instance is running accidentallyAs discussed with Engineering, but not relating to a specific customer issue, although Support team regularly encounter sites with unintentional multiple running instances of named, so I'm tagging this one as 'Customer'.
With newer BIND...As discussed with Engineering, but not relating to a specific customer issue, although Support team regularly encounter sites with unintentional multiple running instances of named, so I'm tagging this one as 'Customer'.
With newer BIND using SO_REUSEPORT (`reuseport yes;`) there is no longer anything to stop multiple instances of running named from listening on the same sockets - the kernel will distribute incoming queries to the listening threads/processes per however the kernel and NICs implement and support rx-flow-hash.
This could be seen as a 'feature' by some. But for others, it allows accidental launching of multiple instances of named, and then much confusion and pain troubleshooting ensuing problems, if, for example, the intent was to restart named with a different version or different configuration. Having different instances fielding different queries could produce different outcomes!
This new behaviour (mostly) negates this change, introduced in BIND 9.11.0:
4022. [func] Stop multiple spawns of named by limiting number of
processes to 1. This is done by using a lockfile and
checking whether we can listen on any configured
TCP interfaces. [RT #37908]
Of significance is that with the introduction of reuseport, the TCP listen check will now no longer work, and that lock-file is not enabled by default.
```
lock-file
This is the pathname of a file on which named attempts to acquire a file lock when starting for the first time; if
unsuccessful, the server terminates, under the assumption that another server is already running. If not specified,
the default is none.
Specifying lock-file none disables the use of a lock file. lock-file is ignored if named was run using the
-X option, which overrides it. Changes to lock-file are ignored if named is being reloaded or reconfigured;
it is only effective when the server is first started.
```
This is distinct from pid-file, whose purpose is to identify the pid of the running named instance, so that signals can be sent to it:
```
pid-file
This is the pathname of the file the server writes its process ID in. If not specified, the default is /var/run/
named/named.pid. The PID file is used by programs that send signals to the running name server. Specifying
pid-file none disables the use of a PID file; no file is written and any existing one is removed. Note that
none is a keyword, not a filename, and therefore is not enclosed in double quotes.
```
---
What to do? I'm not sure - I think this is a 'gotcha' rather than a bug at this point, but I think it's so subtle that it has the potential to derail the unwary who aren't aware that it could happen. Should we perhaps change the default for the existence of the lock-file?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3192[ISC-support #20070] Wildcards, literal asterisk labels, and RPZ zones2024-02-14T14:54:18ZChuck Stearns[ISC-support #20070] Wildcards, literal asterisk labels, and RPZ zones### Summary
A literal asterisk in a RR label can be used to bypass RPZ records.
### BIND version used
9.11.33-S1 (though I think this also affects 9.16 and 9.18)
### Steps to reproduce
RPZ entries:
```
test.com CNAME .
*.test.com C...### Summary
A literal asterisk in a RR label can be used to bypass RPZ records.
### BIND version used
9.11.33-S1 (though I think this also affects 9.16 and 9.18)
### Steps to reproduce
RPZ entries:
```
test.com CNAME .
*.test.com CNAME .
```
AND
test.com zone containing `*.test.com {type} {value}` (must not be delegated)
OR
sub.*.test.com zone definition
Example test:
```
$ dig @0 test.sub.\*.test.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> @0 test.sub.*.test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62448
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.sub.*.test.com. IN A
;; ANSWER SECTION:
test.sub.*.test.com. 3600 IN A 127.0.0.1
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(0.0.0.0)
;; WHEN: Wed Jan 26 16:47:19 EST 2022
;; MSG SIZE rcvd: 64
```
### What is the current *bug* behavior?
Queries containing a literal asterisk (such as `sub.*.test.com` or `*.test.com`) will be answered, rather than caught by RPZ.
### What is the expected *correct* behavior?
RPZ expected to catch the query, like so:
```
$ dig @0 sub.test.com
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> @0 sub.test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31154
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sub.test.com. IN A
;; ADDITIONAL SECTION:
localhost.rpz. 1 IN SOA localhost. postmaster.localhost. 2004052401 3600 1800 604800 3600
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(0.0.0.0)
;; WHEN: Wed Jan 26 16:40:21 EST 2022
;; MSG SIZE rcvd: 110
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3681Benign build issues in doc/man on OpenBSD2023-03-20T09:19:18ZMichal NowakBenign build issues in doc/man on OpenBSDOpenBSD often (but not always) [produces](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2907771) the following benign errors on `v9_16`:
```
making all in /builds/isc-projects/bind9/doc/man
: -b man -d "./_build"/.doctrees/arpaname.1i...OpenBSD often (but not always) [produces](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2907771) the following benign errors on `v9_16`:
```
making all in /builds/isc-projects/bind9/doc/man
: -b man -d "./_build"/.doctrees/arpaname.1in -W -a -v -c "/builds/isc-projects/bind9/doc/man" -D version="@""BIND9_VERSION""@" -D today="@""RELEASE_DATE""@" -D release="@""BIND9_VERSIONSTRING""@" . "./_build"/man
for man in arpaname.1in ddns-confgen.8in delv.1in dig.1in dnssec-cds.8in dnssec-checkds.8in dnssec-coverage.8in dnssec-dsfromkey.8in dnssec-importkey.8in dnssec-keyfromlabel.8in dnssec-keygen.8in dnssec-keymgr.8in dnssec-revoke.8in dnssec-settime.8in dnssec-signzone.8in dnssec-verify.8in dnstap-read.1in filter-aaaa.8in host.1in mdig.1in named-checkconf.8in named-checkzone.8in named-compilezone.8in named-journalprint.8in named-nzd2nzf.8in named-rrchecker.1in named.conf.5in named.8in nsec3hash.8in nslookup.1in nsupdate.1in rndc-confgen.8in rndc.conf.5in rndc.8in tsig-keygen.8in pkcs11-destroy.8in pkcs11-keygen.8in pkcs11-list.8in pkcs11-tokens.8in; do [ -e "./_build"/man/"$(basename $man in)" ] && cp -f "./_build"/man/"$(basename $man in)" "$man"; done
*** Error 1 in target 'arpaname.1in' (ignored)
```
The CI job otherwise passes.
The `:` on second line of the output is the (missing) `$(SPHINXBUILD)` from the `$(MANPAGES_IN)` target, which is OK as `sphinx-build` command is not in the image.
I tried to reproduce it locally with the CI image, but failed. Perhaps a race issue with another target?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2772Update: Validation Easy Start Explained2023-11-02T16:26:07ZMark AndrewsUpdate: Validation Easy Start ExplainedThis section still references managed-keys as of 9.16.16. It needs to be updated to refer to `trust-anchors`.
Also `delv does not consult the managed-keys database maintained by named, which means that if either of the keys in /etc/bin...This section still references managed-keys as of 9.16.16. It needs to be updated to refer to `trust-anchors`.
Also `delv does not consult the managed-keys database maintained by named, which means that if either of the keys in /etc/bind.keys is revoked and rolled over, /etc/bind.keys must be updated to use DNSSEC validation in delv.` is out of date.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2666Document test only options2023-11-02T16:26:06ZMatthijs Mekkingmatthijs@isc.orgDocument test only optionsFrom the following discussion from !4925 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4925#note_209969): (+2 comments)
> I am not too fond on having `too-ma...From the following discussion from !4925 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4925#note_209969): (+2 comments)
> I am not too fond on having `too-many`. I would prefer an option that would disable the iteration value checking.
>
> Either way, this needs to be documented. Probably the manfile is the best place for it.
This option should be documented. There are more test options that should be documented.
1. Document `dnssec-signzone -H too-many`
2. Find other undocumented test options
3. Document those.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2995about PKCS11 document2022-03-01T09:43:12Zperlangabout PKCS11 documentFrom release note of 9.16.22, there is following line,
The use of native PKCS#11 for Public-Key Cryptography in BIND 9 has been deprecated in favor of the engine_pkcs11 OpenSSL engine from the OpenSC project.
but in section 5.11.2 Nati...From release note of 9.16.22, there is following line,
The use of native PKCS#11 for Public-Key Cryptography in BIND 9 has been deprecated in favor of the engine_pkcs11 OpenSSL engine from the OpenSC project.
but in section 5.11.2 Native PKCS#11 of Bv9ARM(9.16.22), there is one opposite meaning line,
(Note: Eventually, when more HSMs become capable of supporting native PKCS#11, it is expected that OpenSSL-based PKCS#11 will be deprecated.)
I guess the latter(5.11.2) should be outdated. But not too sure.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2206Revisit the DNS Flag Day 2020 documentation and release notes for 9.18.02021-10-07T08:41:45ZOndřej SurýRevisit the DNS Flag Day 2020 documentation and release notes for 9.18.0https://gitlab.isc.org/isc-projects/bind9/-/issues/1746Clarifications in ARM about catalog zones2023-11-02T17:00:02ZDan MahoneyClarifications in ARM about catalog zonesAt the bottom of the catalog zones syntax in the 9.14 ARM, the following example is listed for a catalog zone:
```
masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A 192.0.2.2
label.masters.5960775ba382e7a4e092...At the bottom of the catalog zones syntax in the 9.14 ARM, the following example is listed for a catalog zone:
```
masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A 192.0.2.2
label.masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN AAAA 2001:db8::2
label.masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN TXT "tsig_key"
allow-query.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN APL 1:10.0.0.0/24
```
This is a sort of uncommon usage which is basically like:
```
zone "hash" {
masters { 192.0.2.2; 2001:db8::2 key tsig_key; };
allow-query 10.0.0.0/24;
}
```
It's odd that a zone would be configured with one master with a TSIG key, and one without. I think the intent was to show the flexibility here, but if you want to show this it would be better to specify a second zone example that includes the TSIG key.
For the various examples given in this file, it would also be helpful to show the equivalent named.conf clause, to help understanding of a new concept.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1178udpsize anomalies2021-10-04T19:47:01Zreedjcudpsize anomaliesI was trying to understand dig +bufsize. (Reading today's master code.)
1) The dig manual says bufsize is rounded up to 0 if below.
See dighost.c's setup_lookup(). It has some code that if udpsize is 0, sets it to 4096. That appears t...I was trying to understand dig +bufsize. (Reading today's master code.)
1) The dig manual says bufsize is rounded up to 0 if below.
See dighost.c's setup_lookup(). It has some code that if udpsize is 0, sets it to 4096. That appears to be the behavior but I didn't trace or debug it. I may have misunderstood the manual. When I set to 0 its behaviour is as if it is at least 2481 (I assume 4096).
2) dighost.c add_opt() uses the dns_message_buildopt().
See lib/dns/message.c dns_message_buildopt() which has:
/*
* Set Maximum UDP buffer size.
*/
rdatalist->rdclass = udpsize;
Am I reading this right? how can "rdclass" and udpsize be related? (If this correct, please add documentation.)
3) Also see lib/ns/client.c process_opt() has:
/*
* Set the client's UDP buffer size.
*/
client->udpsize = opt->rdclass;
I am trying to understand that udpsize/rdclass relationship. I think is a bug. See right after updsize gets reset to 512 because of this.
Again the dig manual reads that bufsize (udpsize) can be less than 512. But if I set to 1, its behavior is as if is set to 512.https://gitlab.isc.org/isc-projects/bind9/-/issues/4544"primaries" block documentation issues2024-01-23T15:27:16ZRay Bellis"primaries" block documentation issuesI'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years ...I'm finding the documentation of the "primaries" block confusing.
The ARM claims a `primaries` zone setting is only permissible within mirror, redirect, secondary and stub zones. However I've been using them at least a couple of years within the `also-notify` section of primary zones.
There's no direct mention of `primaries` in the grammar of an `also-notify` block. I _suspect_ that it's covered by `<remote-servers>` but the only link between `primaries` and `remote-servers` is this text in the glossary:
> remote-servers: A named list of one or more ip_addresses with optional tls_id, server_key, and/or port. A remote-servers list may include other remote-servers lists. See primaries block.
If in fact a `<remote-servers>` reference _is_ a (named) `primaries` list, then that ought to be spelled out more explicitly, and the documentation updated to reflect that this can be used in *any* `allow-notify` block in any applicable zone type.
I'd also suggest that the top level grammar ought to actually be called `xfer-servers` instead of `masters` and then that term used in place of `remote-servers` in the ARM. In the NOTIFY case the listed servers are secondaries, not primaries, and it makes no sense to call them primaries.
[`remote-servers` also causes confusion with `server <prefix> { }` used to specify per-server EDNS overrides, etc]Long-termMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4489dnssec-guide should mention use of validate-except2023-12-13T12:29:01ZStacey Marshalldnssec-guide should mention use of validate-except### Description
Add use of `validate-except { string; }` to DNSSEC guide.
From discussion on bind9 users list, the recommendation to not use `dnssec-validation no` but instead use `validate-except { string; }` would ideally be mentione...### Description
Add use of `validate-except { string; }` to DNSSEC guide.
From discussion on bind9 users list, the recommendation to not use `dnssec-validation no` but instead use `validate-except { string; }` would ideally be mentioned in the DNSSEC guide (bind9/doc/dnssec-guide) within the ARM.
### Request
Within DNSSEC guide where `dnssec-validation` is discussed for troubleshooting, add some information about the use of `validate-except { string; }` with some examples.
Suggest too that dnssec-validation](https://bind9.readthedocs.io/en/v9.18.20/reference.html#namedconf-statement-dnssec-validation) statement also mention `validate-except`. Yes I see [validate-except](https://bind9.readthedocs.io/en/v9.18.20/reference.html#namedconf-statement-validate-except) is immediately below it, but without the dotted line it may not be seen.
### Links / references
https://lists.isc.org/pipermail/bind-users/2023-December/108172.htmlhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3482Clarify ACLs and their interaction in the ARM2022-10-06T10:22:09ZPetr Špačekpspacek@isc.orgClarify ACLs and their interaction in the ARMThings I noticed in the ARM which I think are in need of clarification:
- allow-query*/allow-recursion* descriptions are just confusing.
- Sections [8.1.4. Address Match Lists](https://bind9.readthedocs.io/en/v9_19_3/reference.html#addr...Things I noticed in the ARM which I think are in need of clarification:
- allow-query*/allow-recursion* descriptions are just confusing.
- Sections [8.1.4. Address Match Lists](https://bind9.readthedocs.io/en/v9_19_3/reference.html#address-match-lists) and [7.1. Access Control Lists](https://bind9.readthedocs.io/en/v9_19_3/chapter7.html#access-control-lists) overlap and really should be merged
## Summary how I believe ACLs work
**Proceed with caution!**
Different sets of ACLs affect different queries, depending on whether the server has data in cache or if the data are in an authoritative zone on the server. Caveats:
- `type mirror` zone still counts as cache (cache ACLs apply, I think)
- `type static-stub` zones are not queriable without recursion desired bit anyway
With this in mind, I _believe_ BIND checks this:
- blackhole acl checks client address and drops packets on the floor - highest priority
- for queries into authoritative zones check ONLY:
- allow-query
- allow-query-on
- for queries into cache
- for data present in the cache check:
- recursion (yes, even if no recursion is happening yet)
- allow-query-cache
- allow-query-cache-on
- _(no allow-query(-on) ACL here!)_
- for data NOT present in the cache **additionally** check (before a fetch is started):
- allow-recursion
- allow-recursion-on
- I.e. a query which triggers a fetch from elsewhere must match all the allow-query-cache(-on) and allow-recursion(-on)
Fun fact: Data stay in cache even if `recursion yes;` is changed to `recursion no;`. Subsequent `rndc reconfig` will create configuration with data in cache but without any means to access it. Turning it back on will provide access to the old cache content.
## Text problems/suggestions
- allow-query-cache(-on) does not "effectively control recursion". It control access to cache data WITHOUT doing recursion: I.e. queries allowed by these ACLs can get content of the cache but not necessarily trigger recursion for things which are missing in the cache. (equivalent of `dig +norecurse` queries)
- allow-recursion(-on) control what queries do trigger recursion for data not available in cache
- allow-query - also covers updates (must intersect with allow-update?)
Relevant log message:
```
update 'example.com/IN' denied due to allow-query
```
(Implementation wise it makes sense because of prerequisites in the update messages, but it is not mentioned in the ARM. Basically it is impossible to make write-only client - no big deal, but better to mention that the ACLs must intersect.)https://gitlab.isc.org/isc-projects/bind9/-/issues/3480unsupported optional libraries2022-08-05T11:42:43ZPeter Daviesunsupported optional librariesBased on the experiences of a user that experienced problems compiling the
BIND man pages with an older version of Sphinx.
There are a number of optional libraries that BIND can be compiled with and it
isn't always clear which v...Based on the experiences of a user that experienced problems compiling the
BIND man pages with an older version of Sphinx.
There are a number of optional libraries that BIND can be compiled with and it
isn't always clear which versions current BIND releases support.
In so far as the configure script doesn't check the versions of these we might
want to consider adding a note to the ARM, if one does not already exist.
I found the following:
sphinx, json-c, zlib, lmdb, libmaxminddb, libfstrm, libprotobuf-c, libidn2,
readline, libedit
There may be more