Knot DNS: High-performance authoritative-only DNS server. https://www.knot-dns.cz/support/
Hello, I recently started to play with the authoritative version of Knot resolver. My setup consists of master and slave running in Docker (on the lastest tag). The configuration is all taken from the docs with no changes and consists only from information for the zone, acls for updates between slaves and dnssec setup. I would like to ask two questions:
- I've set up a test domain but the domain still doesn't have DS record in the parent zone. Should I do something special in the resolver configuration or is this managed by the resolver alone?
- Can I somehow verify that the master-slave scenario is working? I wasn't able to find anything that would suggest so in the docs.
Thanks for help.
- Can I somehow verify that the master-slave scenario is working? I wasn't able to find anything that would suggest so in the docs.
Knot DNS = autoritative server
Knot Resolver = DNS resolver
These are separate software packages etc. so beware, docs etc. are separate as well.
Then to first question about DS: It depends on your parent zone. Parent zones which support CDS/CDNSKEY mechamism (https://tools.ietf.org/html/rfc8078) will take the DS automatically.
If your parent does not support that I suggest you writen a question to their support line, the more people ask for it the more likely it gets implemented.
If your parent does not do CDS you have to upload the key manually and in that case the process is different for each parent zone.
To your second question about master-slave testing:
Ultimate test is to change data on master and then check that all slaves received the new values.
Less demanding option is to use commands like
zone-status in knotc and check serial numbers and other data on slave and compare them with master server.
Is it different from normal ddns ?
That is really badly written. That should be "must be enabled" to be clear.
not disabled is very unclear.
I'd even say confusing.
Hi @bleve, thanks for early feedback :-) Your confusion is interesting!
it doesn't work with onlinesignwants to say that if online signing is enabled, which means the module is responsible for key rollovers,
DS push configuration is ignored by the module (not implemented). It has nothing to do with upstream!- To be honest, I don't feel strong difference between
must not be disabledandmust be enabled. It should meancds-cdnskey-publishis not set tonone! So if you keep the default, it's ok.
@salzmdan ok. that means I can'
I can't use ds-push feature because I do online signing.
I mean why doesn't it work?
Or do I completely misunderstand that feature?
I'd expect ds-push from 3.65.193.in-addr.foobar.fi to push DS record to foobar.fi
@salzmdan about documentation: "cds-cdnsk-publish must be enabled and configured" - would that be more like wanted wording?
if only I could write without typos :)
cds-cdnskey-publish is of course activated.
@salzmdan I must say this will be a very good feature when it works with signing.
without signing it's kind of dummy one.
@bleve please don't confuse
automatic zone signing (https://www.knot-dns.cz/docs/2.8/singlehtml/index.html#automatic-dnssec-signing) with online signing(https://www.knot-dns.cz/docs/2.8/singlehtml/index.html#onlinesign-online-dnssec-signing)! Most of our user use normal signing (I guess it's also your case), for whom the ds-push feature is intended.
so yes, looks really promising.
Tricky question: with Knot auth server, what would be a way to serve (automatically DNSSEC-maintained) records while overwriting one of the signatures - to force validaton error for that record? (I experimented a while back with rosedb, trying to return a dummy RRSIG for that record, but I somehow wasn't able to have it overwrite the original RRSIG)
Hi all. I have two questions regarding DNSSEC, although they are more related to the process of DNSSEC rather than the realisation.
When the server restarts new keys are generated. Can this behaviour change in configuration or dumping the lmdb and reloading it is the only way?
When the server restarts and the keys are generated is it necessary to upload them to parent zone to maintain the signature in parent zone (in the case parent zone doe not support CDS/CDNSKEY submission)?
When the server restarts new keys are generated. Can this behaviour change in configuration or dumping the lmdb and reloading it is the only way?
When the server restarts and the keys are generated is it necessary to upload them to parent zone to maintain the signature in parent zone (in the case parent zone doe not support CDS/CDNSKEY submission)?
@Narzhan Sorry, I don't get your question. When the server restarts, the KASP database is preserved, so the keys from previous run are used rather then generating new ones. Or is your use-case something with misused Docker? To answer your second question: yes, whenever you change your keys, you shall update the DS record in parent zone. However, it's not so easy like this. Because the resolvers use caches, it's necessary to do proper key roll-overs (both old and new key present in parallel for some time) to keep the zone valid all the time...
@libor-peltan-cznic thanks for help. The server indeed load the keys didn't know why that didn't work. For the second answer I have several followups. Is it neccessary to upload ZSK and KSK to parent zone or is KSK enough? If it is necessary what about the situation when the keys (either ZSK or KSK) reach it's expiry date. Do I have to generate new keys beforehand and add the keys to keyset (present at the tld) or is there any other procedure for it. One other question is regarding reverse zones. Do they have to be signed by DNSSEC in the case that the domain is not present in the zone (e.g. I own an IP range and need to make the PTR records available for domains found there but don't have the access to the domains)
Parent zone obviously needs to know only your KSK, that's the reasony why you have the KSK-ZSK pair. Maybe you better read some literature about DNSSEC first, our documentation (see e.g. https://www.knot-dns.cz/docs/2.8/singlehtml/index.html#dnssec-key-rollovers ) tells you how to do things with Knot, but doesn't tell to you what things to do ;) Anyway, DNSSEC keys do not necessarily have an expiration, it's just a good policy to exchange them sometimes. Regarding reverse zone - dunno. Probably everything is better signed than unsigned.