Re: Nsupdate usage scenario
On Mon, May 2, 2016, at 12:15 PM, Jeremy C. Reed wrote: > What about using a specific zone file just for the purpose of the single > A record you want to maintain using dynamic updates? Well, this is a timely idea for another issue I've been working on ... Could you expand on this a bit? Maybe an example? I'm not clear how you go about maintaining a 'different' zone for a record that belong in the 'original', parent zone. Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Mon, May 2, 2016, at 07:17 AM, Matthew Pounsett wrote: > The general procedure is > 1) use 'rndc freeze ' to stop dynamic updates to the zone > 2) edit the file > 3) use 'rndc thaw ' to re-enable dynamic updates > > If the zone is not set up to use dynamic updates, then: > 1) edit the zone file > 2) 'rndc reload ' Nice & clear. Thanks! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
I'm pretty sure I got this sorted -- as you said, perms. With default ownership of root:named, both the zone & jnl files need to be group writeable inside the chroot. That's fixed now, and I'm getting jnl data written to zone files. (1) Thanks! (2) No idea why I see no logging of these perm errors. I couldn't pick the perm prob out of strace or logs. Your prodding and just staring at my dir/file perms did the trick. I'm now cleaning up my chroot script. General question -- When I want to change a zone file's data manually, say to add an A record, what's the right procedure: (1) change it in the chroot dir/file, then copy to the on-disk data? or (2) change it in the on-disk data, then restart the nameserver? To me, change in the live-data, i.e., in the chroot makes the most sense. If yes, what do folks do about getting that data saved back to disk? Wait until dns RESTART, sync'ing everything back up at chroot tear-down & set-up? Or do an update *immediately* on data change at the chroot? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Sun, May 1, 2016, at 11:34 AM, Phil Mayers wrote: > Days? That surely must be permissions? > > As per my other email - attach a strace to the bind process, and run > "rndc sync" / "rndc freeze" to force an immediate write-out - if there's > a permission problem the error should be apparent. > > I'd expect to see something in the logs with a permissions issue though... I tried the strace, and TBH don't understand, yet, the output. So I have some homework there. Afaict, there's no perms-related error in my logs. At least not that I recognize as being a perms-error. If there were a perms problem, I'd have expected that 'rndc freeze' would report it -- I get no complaint. I'm reading through as many posts as I can find -- Is there a specific/particular permission to check for? Also, in LOGGING, right now I've got debug = on for all categories. Really noisy, of course. What specific logging category would report perms problems ? I'd like to turn just that one on . Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Sun, May 1, 2016, at 11:05 AM, Phil Mayers wrote: > > IIUC, though, a nameserver restart is supposed to force the > > write-to-journal immediately, right? > > No, I don't think so. > > Perhaps the behaviour in flush-zones-on-shutdown (which defaults to > "no") is what you're thinking of? > > See also "rndc sync". Well, TBH, I've got different sites saying different things :-/ Sticking with the more reputable resources, e.g. Zytrax, they agree with your assessment: "All changes made to a zone using dynamic update are written to the zone's journal file. The server will periodically flush the complete contents of the updated zone to its zone file this happens approximately every 15 minutes. When a server is restarted after a shutdown or crash, it will replay the journal file to incorporate into the zone any updates that took place after the last zone file update." My journal's NEVER getting written to the zone files. Not after 15 minutes, or several days. Can't seem to figure out why not. The Zytrax site also advises: "If changes have to be made manually to a dynamic zone then use the following sequence: Disable dynamic updates to the zone using rndc freeze zone which causes the zone file to be updated. Edit the zone file Run rndc unfreeze zone to reload the changed zone and re-enable dynamic updates " But , here, rndc freeze+unfreeze doesn't do a thing with the journal, either. Don't yet know about 'flush-zones-on-shutdown', so looking into that now. Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
Oops, s/write-to-journal /write-journal-to-masterfile / ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
Hi On Fri, Apr 29, 2016, at 08:42 PM, Mark Andrews wrote: > Just give it time. The zone contents are the masterfile + journal. > The masterfile only gets written periodically as it can be a expensive > operation. Sure, under normal operation, as I understand it. IIUC, though, a nameserver restart is supposed to force the write-to-journal immediately, right? But it doesn't appear to be doing it on my setup. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Wed, Apr 27, 2016, at 06:30 AM, Matthew Pounsett wrote: > > Actually it is normal for privsep processes to chroot themselves, usually > > to /var/empty - e.g. > > Right, so "no chroot necessary" (which is what I was responding to) isn't > accurate. Oh. That's not what I got out of your comment. >From this end-user's perspective, there's a pretty big difference from a user >perspective of (1) "it" uses privsep, and takes care of the chroot for you -- i.e., you don't mess with it, and it's all in a documented, predictable package and (2) you have to monkey with all of it yourself. It's either easy & insecure, or secure but 'good luck with it'. Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Tue, Apr 26, 2016, at 11:18 AM, Matthew Pounsett wrote: > Both things together are better than either one alone. Thanks for the explanation. upstream bind-chroot with systemd should be easier and better documented ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Mon, Apr 25, 2016, at 11:33 AM, Matthew Pounsett wrote: > Unless you have a clear reason to do it (perhaps there's some security > consideration I haven't thought of) it seems to me it's unnecessary > complexity that would lead to problems just like this. Noted. Still, I'd honestly like to know that my chroot'd environment make sense, and works, and why -- rather than just being lucky that it doesn't break. I'm gonna stick with trying to figure this out -- and likely afterwards stop tearing down the existing chroot on exit. > > I'm not clear on it. > > Although BIND 9 has never had a remote code execution exploit that I'm > aware of, it's still advisable to run it in a chroot environment. Oh well. I completely gave up on chroot'd ntpd because of the endless weirdness. Finally just moved to openntpd as (1) it had safe privsep, (2) no chroot req'd, and (3) did the job I need. It'd be great to be able to dump it here too, but since, for the moment, bind9 does (3) for me nicely, and nothing else does quite yet, I guess I stick with chroot. But IMO it'd be really nice if it went away. And from what I'm reading in various threads online, I'm not the only one who wouldn't mind. Now back to figuring this^ out :-/ Thanks. Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Mon, Apr 25, 2016, at 10:58 AM, Matthew Pounsett wrote: > It's not clear to me why one would want to destroy/rebuild the chroot every > time you restart the process. Well, here (1) Because I inherited it this way, and (2) The notes' quoted examples did that too, and (3) I'd not yet gotten any/good advice NOT to (security?) TBH, I'm not even sure whether "these days", chroot is still recommended. Apparmor or Docker instead? Is privsep taken care of in current bind so we don't have to worry about it anymore (e.g., the openntpd vs ntpd case)? I'm not clear on it. > However, as long as you're doing that you > should make sure that all the important files are preserved. As you noted > earlier, it looks like your journal file is probably not preserved. I'd > start there, and if that doesn't fix it, then have a careful look at what's > in your chroot tree before you shut down the server, and compare that to > what's in the chroot after you start it up again. Good suggestion. Will give it a try. Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Mon, Apr 25, 2016, at 10:46 AM, Matthew Pounsett wrote: > > Unfortunately, that^ returns no TXT record either. Which to me suggests > > the problem's 'earlier'. > > > > Yeah. I think you need to solve the problem with the vanishing journal > file first. But, the above dig is what you *should* do to get back the > TXT record that you're adding. If it's not getting you the record, then > there's a problem with your server somewhere. Got it. I suspect that there's something wrong with what is/isn't copied , and maybe when, in that chroot build/destroy script. Although it does seem to be mostly consistent with some of the tutes I'm finding online, I can't see the problem yet ... I did try to look at opensuse project's rpm-build's spec file to maybe cherry pick the chroot stuff. It's a complete mess, and beyond me what's what in there. Let's just say I can now understand WHY my predecessor on this machine went the DIY route (some of the comments in his notes were -- colorful ;-) ) I've 'started over' a couple of times already on this box, but just get to the same point. I really DON'T want to run bind without the chroot, so haven't taken that path. Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Mon, Apr 25, 2016, at 10:19 AM, Matthew Pounsett wrote: > > TBH I don't understand WHAT to 'expect' from dig to test/verify this^. > > What do I dig to get an answer with "TEST STRING" in it? > > dig in txt test.example.com @ns01.example.com Thanks. Unfortunately, that^ returns no TXT record either. Which to me suggests the problem's 'earlier'. Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
> This zone would not pass named-checkzone, which interestingly, is the same > code which named itself uses when initially loading a zone. It appears to named-checkzone -t /var/chroot/named example.com /namedb/master/example.com.zone zone example.com/IN: loaded serial 1461540029 OK cat /tmp/nsupdate.txt server ns01.example.com debug yes zone example.com. update add test.example.com. 300 in TXT "TEST STRING" show send $NSUPDATE /tmp/nsupdate.txt @ server Apr 24 16:24:02 ns01 named[14954]: 24-Apr-2016 16:24:02.350 update-security: info: client 10.0.0.17#26427/key jason-key: view external: signer "jason-key" approved Apr 24 16:24:02 ns01 named[14954]: 24-Apr-2016 16:24:02.350 update: info: client 10.0.0.17#26427/key jason-key: view external: updating zone 'example.com/IN': adding an RR at 'test.example.com' TXT "TEST STRING" TBH I don't understand WHAT to 'expect' from dig to test/verify this^. What do I dig to get an answer with "TEST STRING" in it? Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
> What is deleting your journal? It's not named doing that.
Hm.
Maybe this
destroy_chroot() {
cp -af ${CHROOT}/namedb/master/*.signed
/opt/etc/named/namedb/master/
should be
destroy_chroot() {
cp -af ${CHROOT}/namedb/master/*.{jnl,signed}
/opt/etc/named/namedb/master/
?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
I'm in over my head a bit on these details, so appreciate the help.
> The smoking gun is in the hand of systemctl ...
Hadn't thought of that, but not surprised to hear it.
I inherited this, and didn't yet monkey with systemd. But I can as needed.
Here's the systemd unit file for named:
cat named.service
[Unit]
Description=Bind9 DNS Server
After=syslog.target network-online.target
Before=named.target
Wants=network-online.target
[Service]
ExecStartPre=/opt/sbin/bind-chroot.sh /var/chroot/named rebuild
ExecStart=/opt/bind9/sbin/named -f -t "/var/chroot/named" -u
named -c /etc/named.conf
ExecReload=/opt/sbin/bind-chroot.sh /var/chroot/named reload
ExecReload=/opt/bind9/sbin/rndc reload
ExecStop=/opt/bind9/sbin/rndc stop
ExecStopPost=/opt/sbin/bind-chroot.sh /var/chroot/named destroy
ReadOnlyDirectories=/etc
InaccessibleDirectories=/boot
InaccessibleDirectories=/home
[Install]
WantedBy=multi-user.target
And here's the chroot setup script. From the notes I did find, this was done
specifically for this opensuse system. I haven't setup a chroot on my own yet,
but I do see the cp back & forth. Wonder if something's missing ...
cat /opt/sbin/bind-chroot.sh
#!/bin/bash
CHROOT="$1"
build_chroot() {
mkdir -p ${CHROOT}/dev
mkdir -p ${CHROOT}/var/{run/named,log}
mkdir -p ${CHROOT}/lib64/engines
mkdir -p ${CHROOT}/etc
mkdir -p ${CHROOT}/namedb/{master,slave,working}
mkdir -p ${CHROOT}/keys/{managed-keys,DNSSEC}
mkdir -p ${CHROOT}/includes
mkdir -p ${CHROOT}/var/lib/GeoIP
populate_chroot
mknod -m 644 ${CHROOT}/dev/nullc 1 3
mknod -m 644 ${CHROOT}/dev/random c 1 8
mknod -m 644 ${CHROOT}/dev/urandom c 1 9
chown root:named ${CHROOT}
chmod 750 ${CHROOT}
chown -R named:named
${CHROOT}/namedb/{master,slave,working}
chown named:named ${CHROOT}/var/{run,log}
chown named:named ${CHROOT}/var/run/named
chmod 755 ${CHROOT}/var/run/named
chmod 666 ${CHROOT}/dev/{null,random,urandom}
chown -R named:named ${CHROOT}/dev
}
populate_chroot() {
cp -a /opt/etc/named/includes/*
${CHROOT}/includes/
cp -a /opt/etc/named/keys/* ${CHROOT}/keys/
cp -a /opt/etc/named/named.{conf,cache} ${CHROOT}/etc/
cp -a /opt/etc/named/namedb/*
${CHROOT}/namedb/
cp -a /opt/etc/named/rndc.key ${CHROOT}/
cp -a /var/lib/GeoIP/*
${CHROOT}/var/lib/GeoIP/
cp/lib64/engines/libgost.so
${CHROOT}/lib64/engines/
cp/etc/localtime${CHROOT}/etc/
}
destroy_chroot() {
cp -af ${CHROOT}/keys/DNSSEC/*
/opt/etc/named/keys/DNSSEC/
cp -af ${CHROOT}/namedb/master/*.signed
/opt/etc/named/namedb/master/
cp -af ${CHROOT}/namedb/slave/*
/opt/etc/named/namedb/slave/
umount --lazy ${CHROOT}/dev
rm -rf ${CHROOT}
}
case "$2" in
build)
build_chroot
;;
destroy)
destroy_chroot
;;
rebuild)
destroy_chroot
build_chroot
;;
reload)
populate_chroot
;;
*)
exit 1
;;
esac
exit 0
At the moment I'm looking suspiciously at that
ReadOnlyDirectories=/etc
Also need to re-read those^ comments about in-zone & out-of-zone
Fwiw, afaict the server's working fine otherwise. I'm not seeing, well let's
say not yet, any errors.
Jason
Re: 'succesful' nsupdate of remote server not persistent across nameserver restart?
On Sun, Apr 24, 2016, at 12:20 PM, Anand Buddhdev wrote: > On 24/04/16 21:04, jaso...@mail-central.com wrote: > > Hey Jason, > > > checking with dig, it's NOT in 'TXT' where I expected it > > > > dig TXT example.net +short > > (empty) > > You added a TXT record for the name test.example.net, but you're looking > for it at the name example.net. Of course you won't see the record! Try: Right, I added the TXT record for test.example.net ... to the zone file for the parent domain, example.net >zone example.net. >update add test.example.net. 500 in TXT "TEST STRING" And it obviously shows up in the AXFR dig for 'just' example.net > dig txt test.example.net +short That comes back empty too. Jason :-/ ? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
'succesful' nsupdate of remote server not persistent across nameserver restart?
I'm doing an nsupdate to a remote server from my desktop cat nsupdate.txt server ns01.example.com debug yes zone example.net. update add test.example.net. 500 in TXT "TEST STRING" show send nsupdate -k ./jason-key ./nsupdate.txt On the nameserver, logs show what appears to be 'success', Apr 24 11:47:07 ns01 named[23053]: 24-Apr-2016 11:47:07.949 update-security: info: client 10.0.0.17#4218/key jason-key: view internal: signer "jason-key" approved Apr 24 11:47:08 ns01 named[23053]: 24-Apr-2016 11:47:07.949 update: info: client 10.0.0.17#4218/key jason-key: view internal: updating zone 'example.net/IN': adding an RR at 'test.example.net' TXT "TEST STRING" checking with dig, it's NOT in 'TXT' where I expected it dig TXT example.net +short (empty) instead it's in 'AXFR' dig AXFR example.net ; <<>> DiG 9.10.3-P4 <<>> AXFR example.net ;; global options: +cmd example.net. 5 IN SOA ns01.example.com. ns-admin.example.com. 1461435298 7200 1800 604800 5 example.net. 5 IN NS ns01.example.com. example.net. 5 IN A 127.0.0.1 test.example.net. 500 IN TXT "TEST STRING" example.net. 5 IN SOA ns01.example.com. ns-admin.example.com. 1461435298 7200 1800 604800 5 ;; Query time: 1 msec ;; SERVER: 10.0.0.53#53(10.0.0.53) ;; WHEN: Sun Apr 24 11:48:58 PDT 2016 ;; XFR size: 5 records (messages 1, bytes 213) The journal HAS been modified cd grep -rlni acme . ./namedb/master/internal.example.net.zone.jnl After a bind restart, which iiuc is supposed to flush the journal to files, systemctl stop named.service systemctl start named.service checking with dig, the update's missing dig AXFR example.net ; <<>> DiG 9.10.3-P4 <<>> AXFR example.net ;; global options: +cmd example.net. 5 IN SOA ns01.example.com. ns-admin.example.com. 1461435297 7200 1800 604800 5 example.net. 5 IN NS ns01.example.com. example.net. 5 IN A 127.0.0.1 example.net. 5 IN SOA ns01.example.com. ns-admin.example.com. 1461435297 7200 1800 604800 5 ;; Query time: 2829 msec ;; SERVER: 10.0.0.53#53(10.0.0.53) ;; WHEN: Sun Apr 24 11:52:32 PDT 2016 ;; XFR size: 4 records (messages 1, bytes 178) cd grep -rlni acme . (empty) What am I failing to do to make this update persistent across flush/restart, as intended? Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: generating TSIG keys with 'dnssec-keygen', get "error reading key file ... bad key type"?
On Tue, Apr 19, 2016, at 05:19 PM, Evan Hunt wrote: > The "bad key type" message is a bug; it's been there for a while ... > KEY is in fact what *should* be there, but the collision- > checking function is expectingly DNSKEY, and so it complains. Ok, so the data's good; just the detection whines for now. Thanks. Which leads me right back to my original problem -- unable to get nsupdates 'to' my remote server ( I was kinda hoping that there was something wrong with the key file :-/ ) But that's another issue. Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: generating TSIG keys with 'dnssec-keygen', get "error reading key file ... bad key type"?
On Tue, Apr 19, 2016, at 04:25 PM, Evan Hunt wrote: > It's not "bad", dnssec-keygen can generate TSIG keys fine, it's just that > it's cumbersome to remember all the options, and the keys are generated in > a format that isn't directly useful. Sure that's what I was doing anyway. To be clean, I'm not saying it's bad. It's returning the "bad key type" . I'm just trying to understand what the problem is. Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: generating TSIG keys with 'dnssec-keygen', get "error reading key file ... bad key type"?
On Tue, Apr 19, 2016, at 02:24 PM, Evan Hunt wrote: > On Tue, Apr 19, 2016 at 07:40:38AM -0700, jaso...@mail-central.com wrote: > > I'm working on generating TSIG keys for use with my bind server. > > I think you'll be happier if you use "tsig-keygen" instead of "dnssec-keygen". Huh. Didn't come across that in any of the example I was using :-/ Looks like tsig-keygen is also from bind rpm -q --whatprovides /usr/sbin/dnssec-keygen /usr/sbin/tsig-keygen bind-utils-9.10.3P4-215.1.x86_64 bind-utils-9.10.3P4-215.1.x86_64 I'll sure read up and give tsig-keygen a try. But, why's using dnssec-keygen 'bad' for TSIG ? Apart from all the online tutes that refer to it, from its manpage DESCRIPTION dnssec-keygen generates keys for DNSSEC (Secure DNS), as defined in RFC 2535 and RFC 4034. It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930. I'd still like to at least understand what the problem is. Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
generating TSIG keys with 'dnssec-keygen', get "error reading key file ... bad key type"?
I'm working on generating TSIG keys for use with my bind server. When I generate a 2nd set of keys in a dir, I get a "bad key type" error, DIR="/home/me/test/nsupdate" HOST="myhost.example.com" dnssec-keygen -V dnssec-keygen 9.10.3-P4 cd $DIR rm -f * ls * (emtpy) dnssec-keygen -a hmac-sha256 -b 128 -K $DIR -n HOST $HOST Kmyhost.example.com.+163+35917 ls * Kmyhost.example.com.+163+35917.key Kmyhost.example.com.+163+35917.private dnssec-keygen -a hmac-sha256 -b 128 -K $DIR -n HOST $HOST dnssec-keygen: warning: dns_dnssec_findmatchingkeys: error reading key file Kmyhost.example.com.+163+39520.private: bad key type dnssec-keygen: warning: dns_dnssec_findmatchingkeys: error reading key file Kmyhost.example.com.+163+35917.private: bad key type Kmyhost.example.com.+163+16588 ls * Kmyhost.example.com.+163+16588.key Kmyhost.example.com.+163+16588.private Kmyhost.example.com.+163+35917.key Kmyhost.example.com.+163+35917.private >From the manpage Note 2: DH, HMAC-MD5, and HMAC-SHA1 through HMAC-SHA512 automatically set the -T KEY option. So it's auto-set here. What's "bad" about the automatically set key type? Jason ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
