For rndc.conf, it's less obvious that include
works. But mentioning include
in both places would be a good idea.
As for the mechanics:
rndc-confgen
currently mixes output for rndc.conf
and (as comments) named.conf
. I don't see why it's harder to generate include
instead of the key
clause, the options, and then as comments the key file. Then instead of duplicating the key
clause in the named.conf
comments, duplicate the include
.
Splitting into 3 files is pretty simple with 2 sed
commands; you have the "# End of " markers, so select the range and output. (Or awk
, perl
, bash
, or your favorite) That's compatible with current style.
I'd suggest something simpler for the user: -o foo
writes foo.conf
, foo.key
, foo.named.conf
e.g.
foo.conf := "include foo.key; options...
foo.key := "'key rndc-key { ...};`"
foo.named.conf := "`include foo.key; controls { ... }'"
with that approach, the command becomes rndc-confgen -o foo
; everything else, as now, is optional.
And it's less work for users/distributions - no need to strip comments, just include
the fragments.
With no -o
, can produce the modified all-in-1 file with live rndc.conf
and comment sections for the other two.
At least the documentation should recommend keeping the key in its own files..
I was wrong about md5 - running current bind, but there was an old rndc-confgen
in PATH on the system where I ran it. Sorry. I don't run rndc-confgen
very often...I have a script that periodically creates new .key
files, and reconfig's named
... which is easy since I include
them :-)
The wildcard
match documentation reads
The name field is subject to DNS wildcard expansion, and this rule matches when the name being updated is a valid expansion of the wildcard.
It would be useful to have a more flexible wildcard match for the update-policy's grant/deny wildcard names.
An example that would help many of us (who use Let's Encrypt) is
_acme-challenge.*.example.net
, as in
grant "CERTIFICATE_ISSUE_BOT" name _acme-challenge.*.example.net. TXT ;
Since DNS wildcards only work for the leftmost label, this can't be expressed with the current syntax.
As a result, when a server is added, not only must the A/AAAA records be added (which can be done with UPDATE), but a grant
clause must be added to the configuration (which can not).
Or allow the BOT to handle all TXT records in the domain. I'm pretty sure I don't want a bot to be able to mess up SPF, google console, and other TXT records...
There are other cases where a generic glob match would be helpful, but most of them can be worked-around by suitable naming and/or introducing a subdomain. Unfortunately, that's not the case for ACME, which requires this structure for the records it uses for dns-01
validation.
This is NOT asking for changes to how queries are resolved. That ship sailed (to where there be dragons) long ago. Just how update-policy
clauses are matched. update-policy
is internal to bind, and the suggested change would be upward-compatible.
The documentation for update-policy is unclear, and takes the reader down false paths. The section could use a top-to-bottom rewrite for clarity.
Some examples:
It describes "identity" as "The identity field must be set to a fully qualified domain name. "
This is incorrect.
The documentation goes on to says "In most cases, this represents the name of the TSIG or SIG(0) key that must be used to sign the update request. "
But the name of a TSIG key is simply a string, as documented here.
key <string> {
algorithm <string>;
secret <string>;
};
In fact, the name of a key is more likely to NOT be a valid FQDN., e.g. "INTERNAL_VIEW_UPDATE_KEY".
Further down, "The name
field also specifies a FQDN. That's closer - certainly true for a name
match.
But a subdomain
, zonezub
, or wildcard
isn't a FQDN, since each of these, at least in most cases, is a partial name.
Nor is 'ignored' a FQDN, as in self
matches. Nor '.', as recommended in tcp-self
, krb-self
, ms-subdomain
The code is (mostly) willing, but the documentation is weak :-(
I finally noticed that the rndc documentation 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:
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.
Thank you for the follow-up. I reported what I saw - and as it turns out, neither of us was entirely correct.
There were no environment variables or configuration files behind this incident.
At some point in its evolution, the behavior of ccache
changed. The old, but still servicable, version on this particular machine does pass pre-processed files to the compiler. I verified this with strace
. For that version, -C
is required when the compiler is looking for structured comments. I haven't encountered this before, but a web search with the right terms will turn up other reports.
I updated ccache
to the latest release, which resolves the issue for me.
Thus there is some minimum version of ccache
which behaves as you expect, and below which the behavior that I experienced occurs. I don't think it's worth finding the pivot point or dealing with it in configure
.
It might be worth listing the minimum version of build tools that you test with in the README (or a revived INSTALL).
Thanks again for taking the time to follow-up. It provided a useful clue - the price of things that "just work" is that one tends to forget about them.
I apologize for failing to do a careful and complete analysis of this issue before opening it.
It turns out to be a case where configure
could do better.
Analysis
I allow configure
to determine the compiler flags - no overrides are specified. (LDFLAGS
is specified for the linker.)
This build used ccache
(https://ccache.dev/) - as have past builds, but the compiler upgrade is new. (ccache
is an accelerator for re-compiling C and C++ code.)
ccache
preprocessing causes gcc
to strip comments - removing the FALLTHROUGH markers. Thus, the compile doesn't see them, resulting in the errors.
This can be overcome with CFLAGS=-C
.
To automate this, configure
could do the autoconf
equivalent of something like:
# Check for (optional) ccache
gpath="`which cc`"
cpath="`which ccache 2>/dev/null`"
if [ -n "$cpath" -a "`readlink -f $gpath`" = "`readlink -f $cpath`" ]; then CFLAGS += "-C" ;fi
I'm not an autoconf
person - a complete scriptlet should check if the active compiler is a gcc
family compiler (gcc
, clang
, icc
, ...)
Since you haven't encountered this, you might want to include ccache
in at least some of your builds. It does make them faster.
I'm re-opening the issue to allow consideration of improving configure, which may save others some pain.
Compiling 9.11.29 with gcc 8.1.0 (or later) results in a number of warnings of the form:
warning: this statement may fall through [-Wimplicit-fallthrough=]
-Wimplicit-fallthrough=3
is enabled by -W
(-Wextra
), which configure includes.
These can be annoying - but they can also indicate bugs. Most experienced C coders are careful, but anyone can slip up. They're worth cleaning up.
See https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html for a complete description of the option.
Use comments like /* FALLS THROUGH */
for legitimate cases. (There's a regexp in the doc listing alternative tags.) */
BIND 9.11.29 (Extended Support Version) <id:a35739f>
built by make with '--cache-file=../bind-config.cache' '--with-libtool' '--with-openssl=/usr/local/ssl' '--prefix=/usr' '--enable-largefile' '--with-zlib' '--enable-full-report' '--with-readline=-lreadline -lncurses' '--with-libxml2=/usr' '--with-python=/usr/local/bin/python3' '--with-libjson=/usr/local' '--with-lmdb' '--disable-linux-caps' 'LDFLAGS=-L/usr/local/lib'
compiled by GCC 8.1.0
Here is a list of the errors that I encountered:
entropy.c:157:35: warning: this statement may fall through [-Wimplicit-fallthrough=]
entropy.c:195:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
../entropy.c:331:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
../entropy.c:335:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
../entropy.c:356:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
../entropy.c:359:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
socket.c:2711:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
socket.c:5054:15: warning: this statement may fall through [-Wimplicit-fallthrough=]
socket.c:5227:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
socket.c:5431:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
log.c:1671:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
ratelimiter.c:341:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
siphash.c:123:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
siphash.c:126:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
siphash.c:129:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
siphash.c:132:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
siphash.c:135:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
siphash.c:138:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
tm.c:307:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
tm.c:316:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
dnssec.c:444:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
masterdump.c:621:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
name.c:1169:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
name.c:1186:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
name.c:1227:10: warning: this statement may fall through [-Wimplicit-fallthrough=]
name.c:1246:10: warning: this statement may fall through [-Wimplicit-fallthrough=]
name.c:1493:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
resolver.c:8130:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
rootns.c:127:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
rpz.c:2318:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
update.c:1593:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
update.c:1625:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
update.c:1713:59: warning: this statement may fall through [-Wimplicit-fallthrough=]
update.c:1829:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
update.c:1861:30: warning: this statement may fall through [-Wimplicit-fallthrough=]
update.c:1902:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
update.c:2003:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
xfrin.c:1431:42: warning: this statement may fall through [-Wimplicit-fallthrough=]
xfrin.c:621:42: warning: this statement may fall through [-Wimplicit-fallthrough=]
zone.c:15959:168: warning: this statement may fall through [-Wimplicit-fallthrough=]
zone.c:13591:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
zone.c:13638:39: warning: this statement may fall through [-Wimplicit-fallthrough=]
zone.c:10226:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
zone.c:10248:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
gssapictx.c:743:10: warning: this statement may fall through [-Wimplicit-fallthrough=]
getaddresses.c:157:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
query.c:7569:15: warning: this statement may fall through [-Wimplicit-fallthrough=]
query.c:7693:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
query.c:8175:14: warning: this statement may fall through [-Wimplicit-fallthrough=]
query.c:8342:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
./rndc.c:867:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
dnssec-keygen.c:492:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
dnssec-keygen.c:927:17: warning: this statement may fall through [-Wimplicit-fallthrough=]
./dnssec-signzone.c:3438:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
dnssec-keyfromlabel.c:340:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
dnssec-dsfromkey.c:406:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
dnssec-dsfromkey.c:441:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
dnssec-revoke.c:145:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
dnssec-settime.c:247:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
./dnssec-verify.c:261:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
./dnssec-verify.c:122:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
dnssec-importkey.c:379:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
genrandom.c:86:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
./named-checkconf.c:614:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
./named-checkzone.c:425:7: warning: this statement may fall through [-Wimplicit-fallthrough=]
Compiling 9.11.29 with gcc 8.1.0 (or later) results in a number of warnings of the form:
warning: this statement may fall through [-Wimplicit-fallthrough=]
-Wimplicit-fallthrough=3
is enabled by -W
(-Wextra
), which configure includes.
These can be annoying - but they can also indicate bugs. Most experienced C coders are careful, but anyone can slip up. They're worth cleaning up.
See https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html for a complete description of the option.
Use comments like /* FALLS THROUGH */
for legitimate cases. (There's a regexp in the doc listing alternative tags.) */
BIND 9.11.29 (Extended Support Version) <id:a35739f>
built by make with '--cache-file=../bind-config.cache' '--with-libtool' '--with-openssl=/usr/local/ssl' '--prefix=/usr' '--enable-largefile' '--with-zlib' '--enable-full-report' '--with-readline=-lreadline -lncurses' '--with-libxml2=/usr' '--with-python=/usr/local/bin/python3' '--with-libjson=/usr/local' '--with-lmdb' '--disable-linux-caps' 'LDFLAGS=-L/usr/local/lib'
compiled by GCC 8.1.0