No worries. We'll deploy the workarounds mentioned in the meantime. Thanks!
Back when ISC decommissioned DLV, we committed to providing a signed, empty zone with no other deltas (short of NS records) "for the forseeable future". Now, with BIND 9.18 doing the inline-signing that was previously done by 9.11 and 9.16, the zone is changed: there is now a CDS option in place that was not there previously.
In a case where an organization (us, or someone else) is transitioning to new signing software, the ability to maintain the exact same signed setup without introducing new RRtypes should still be an option.
Note well that we still get occasional queries to dlv.isc.org -- and while the time may come to de-delegate it, we haven't made that decision yet.
No matter how much we announce that it's dead and that people should stop using it, they do, which indicates that they're using either very old or very misconfigured software that's still limping along. It's possible, albeit unlikely, that the presence of new records that were not defined when DLV was a thing could violate the principle of least astonishment. (I don't think a CDS record will crash anything, to be clear.)
An option in dnssec-policy for inline-signing to not insert CDS records. I didn't find anything in the ARM for this.
The named
process and dnssec-settime
(perhaps other tools) will take it upon themselves to change the permissions of a private key on certain changes.
However, we track our key-directory (and other configs) using git, with a group-shared repository.
Typical permissions on .private files are bind:bind with mode 660, but because a normal user (in the bind group) diffs/commits/pushes the repository, these keys can also be user:bind mode 660.
(Noting as well that our tooling is not more comfortable running git tasks as root, complaining of other permissions issues. Also, the less we can do as root, the better.)
With bind's usual permissions model, one cannot do a git diff/git log if the file is owned by bind. If the file is owned by user:bind, bind loses access to it on the permissions change.
Changing the umask under which the process runs doesn't seem to fix this, we tried.
Running a periodic cron job to fix this is a possible workaround, but feels like it shouldn't be necessary.
For command line tools, an option to not do this.
For named, an
options` statement that lets us turn this off.
Both retaining the current behavior by default.
Hi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
Before continuing, please select the appropriate issue template in the drop-down menu above, under the heading Description.
(There is no "doc" template. Maybe there should be.)
The current doc for parental-agents laid out in the 9.18 arm is, some formatting tweaks for gitlab aside:
Grammar zone (primary, secondary):
parental-agents [ port <integer> ] { ( <remote-servers> | <ipv4_address> [ port <integer> ] | <ipv6_address> [ port <integer> ] ) [ key <string> ] [ tls <string> ]; ... };
Grammar topmost:
parental-agents <string> [ port <integer> ] { ( <remote-servers> | <ipv4_address> [ port <integer> ] | <ipv6_address> [ port <integer> ] ) [ key <string> ] [ tls <string> ]; ... }; // may occur multiple times
Blocks: topmost, zone (primary, secondary)
Tags: zone
Defines a list of delegation agents to be used by primary and secondary zones.
8.2.10.
parental-agents
Block Definition and Usage
parental-agents
lists allow for a common set of parental agents to be easily used by multiple primary and secondary zones. A parental agent is the entity that is allowed to change a zone’s delegation information (defined in RFC 7344).
What is not apparent from the above:
If you define a "topmost" parental agent, you must still define it in a zone for it to be used. There is no way to configure a default parental agent, nor to have it apply to zones without stating it for each. The example cited in the 9.18 migration article in the KB only mentions the pure-zone-based version, and doesn't give a good example of how to do it with a globally-defined one.
The "usage" statement for the zone does not make it apparent how to specify an agent defined topmost -- this implies either two "zone" usage statements (Grammar zone with no defined topmost agent, grammar zone with the agent defined only in the zone statement), or a more complex definition of the "Grammar Zone" statement where it's either "parental-agents { "string"; } followed by the rest of the possible options. (I guess it's possible to use a topmost-defined parental agent but ALSO add others? -- I'm not sure how to properly bracket those options, depending on if that's the case.)
"A parental agent is the entity that is allowed to change a zone's delegation information" is untrue in this case. While that is one possible usage (for example, specifying "a0.org.afilias-nst.info." for an agent for example.org), The a0.org.afilias-nst.info. is not allowed to change the delegation information -- some hidden SRS server and a stealth master are, as part of the DNSSEC process. A parental-agent may also be set to 8.8.8.8 or any other TSIG-relationship-defined validating resolver, none of which are allowed to change anything about the delegation.
Also, the "allowed to change" wording implies that there is some nsupdate-like relationship required between our zone and it, that's to be configured, especially because things like TSIG keys are offered as options.
It isn't immediately clear that the only thing BIND does is send DS queries.
A better phrasing here might be:
"A parental agent is a trusted DNS server that can confirm that a zone's delegation information has been updated in the parent zone of the one being configured, as defined in (rfc foo section bar). [An optional statement about what is implied by "trusted" (TSIG/DNSSEC/ACLs on the parental-agent server) could go here.]"
A generic, inheritable, zone-policy statement that allows for a many of zone data to be simply included. (Inspired somewhat by apache24's mod_template).
In rolling out the new dnssec arguments in bind9.18, a number of items have come up where a number of statements are duplicated in each zone, that cannot be specified easily at the options
level.
Some examples:
Several other more "classic" options also exist for zones, like allow-query
, and allow-transfer
, that you can set globally, and that you may want to apply for many zones, but you may not want to inherit what's present in the global options
block (or you may in fact want the global options
block to list a conservative and restrictive default.)
This is in no way an exhaustive list of available statements that could be included.
While on its face this feels like an option that would complicate configuration, it stands to make configuration way shorter and easier to read as long as the options are well spelled out. It makes configuration audits easier as well, because rather than scanning each zone statement for typos and evaluations, you know for-sure that a policy has been applied.
I recognize that 9.20 or beyond may be where this happens, if at all.
Other parts of the ARM say the text:
"TTL-style time-unit suffixes may be used to specify the value. It also accepts ISO 8601 duration formats."
This would probably be sufficient here as a clue.
However, it really would be useful if there was an "Appendix" page that covered ttl-style time formats, such as https://www.zytrax.com/books/dns/apa/time.html, and durations, such as https://en.wikipedia.org/wiki/ISO_8601#Durations -- or if we linked to the same.
Looking through the ARM, see timing options for the key lifetimes such as:
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk lifetime P30D algorithm 8;
csk lifetime P6MT12H3M15S algorithm ecdsa256;
};
And while the ARM spells out what that last (weird) key argument does, there's no link to what the actual format of the lifetime statement is -- what the P and T stand for (also, nothing in our KB's.)
named-checkconf also does not emit warnings if you just say "lifetime 30d" so I cannot tell if this behavior is somehow different.
In fact, I cannot at all find a syntax for the "keys" sub-statement for dnssec-policy in the ARM.
Finally, in the rendered version of the ARM, there's a statement that says:
"Here is an example (for illustration purposes only) of some possible entries in a [keys] list:", and that links to the wrong "keys" statement. (It links to https://bind9.readthedocs.io/en/v9.18.18/reference.html#namedconf-statement-keys where it specifically says "these are NOT the dnssec-policy keys")
The only way we can track 404's on ReadTheDocs is with Google Search console (and the related BING tools, which validate using google, ie if you access to a thing in the google console, bing will also give you access to their tools with no extra work.
We cannot use the "upload an HTML file" to RTD, nor a TXT record, and the Google Analytics tag method isn't compatible. The META tag is pretty much the only option that works here.
Google Search Console wants us to add:
<meta name="google-site-verification" content="0-DMrB_qDynsvXBKJhpsS5m8l5oVea8Qe2ojkudjtCY" />
to our default page (presently bind 9.18.16)
My reading of Sphinx implies that we need to add:
.. meta::
:google-site-verification: 0-DMrB_qDynsvXBKJhpsS5m8l5oVea8Qe2ojkudjtCY
to doc/arm/index.rst
to cause this meta tag to be added. It's fine if this gets committed now and has to wait for the next release before it shows up in tree, i.e. for the release cut of 9.18.17
@ondrej Left that way in case I was asked to upload key or journal material, which was never asked for. Feel free to set public based on that.