Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 20 18:36
    GitLab | Daniel Salzman pushed 1 commits to Knot DNS
  • Sep 20 17:57
    Daniel Salzman commented on issue #532 Consistent names for related options in Knot DNS
  • Sep 20 17:57
    Daniel Salzman closed issue #532 Consistent names for related options in Knot DNS
  • Sep 20 17:55
    GitLab | Daniel Salzman pushed 1 commits to Knot DNS
  • Sep 20 15:44
    GitLab | David Vasek pushed 1 commits to Knot DNS
  • Sep 20 13:36
    GitLab | Daniel Salzman pushed 2 commits to Knot DNS
  • Sep 20 13:36
    GitLab | Libor Peltan pushed to Knot DNS
  • Sep 20 13:36
    Daniel Salzman merged merge request #1071 zone load journal: don't use apply_ctx in Knot DNS
  • Sep 20 13:30
    GitLab | Daniel Salzman pushed 1 commits to Knot DNS
  • Sep 20 13:27
    GitLab | Daniel Salzman pushed 3 commits to Knot DNS
  • Sep 20 13:26
    GitLab | Libor Peltan pushed to Knot DNS
  • Sep 20 13:26
    Daniel Salzman merged merge request #1070 ixfr: don't failover to axfr if connection error in Knot DNS
  • Sep 20 13:26
    Daniel Salzman closed issue #642 Warning message "fallback to AXFR" somewhat misleading in Knot DNS
  • Sep 20 12:28
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • Sep 20 12:25
    GitLab | David Vasek pushed 1 commits to Knot DNS
  • Sep 20 12:07
    GitLab | David Vasek pushed 1 commits to Knot DNS
  • Sep 20 11:07
    GitLab | Daniel Salzman pushed 2 commits to Knot DNS
  • Sep 20 10:47
    GitLab | David Vasek pushed 1 commits to Knot DNS
  • Sep 20 09:40
    Libor Peltan opened merge request #1071 zone load journal: don't use apply_ctx in Knot DNS
  • Sep 20 09:04
    GitLab | David Vasek pushed 19 commits to Knot DNS
Narzhan
@Narzhan
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.
Petr Špaček
@pspacek
Hi and welcome. Please let me clarify terminology so we are all on the same page:
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.
Jonathan Foote
@footePGH_twitter
Hello all. For those CC'd on google/oss-fuzz notifications, the fuzzer build failure from this morning appears to be an issue with the clusterfuzz infrastructure. No action is required at this time to fix the issue.
Daniel Salzman
@salzmdan
Hi Jonathan, I noticed that already. Thanks
bleve
@bleve
Hmh. question about new ds-push - what does it mean that it doesn't work with onlinesign ?
Is it different from normal ddns ?
bleve
@bleve
I'd understand from NOTE in git that you can't do ds-push if you have automatic signing enabled on upstream zone.
bleve
@bleve
Another note: For proper operation ref:`cds-cdnskey-publish<policy_cds-cdnskey-publish> must not be disabled.
That is really badly written. That should be "must be enabled" to be clear.
not disabled is very unclear.
I'd even say confusing.
Daniel Salzman
@salzmdan
Hi @bleve, thanks for early feedback :-) Your confusion is interesting!
  • it doesn't work with onlinesign wants 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 disabled and must be enabled. It should mean cds-cdnskey-publish is not set to none! So if you keep the default, it's ok.
bleve
@bleve
@salzmdan double no is always hard for any human to understand
@salzmdan ok. that means I can'
I can't use ds-push feature because I do online signing.
bleve
@bleve
No problem, I only have one zone for that use anyway :)
Daniel Salzman
@salzmdan
Ok, I will try to improve the notes.
Maybe some time in the future we will extend online signing with DS push.
bleve
@bleve
What's different form normal ddns with ds-push?
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 :)
Daniel Salzman
@salzmdan
ds-push from 3.65.193.in-addr.foobar.fi to push DS record to foobar.fi is an intended use case. If both zones are on the same server for example, ds-push can help. However, the child zone must generate CDS record. It means cds-cdnsk-publish is not set to none on the child.
bleve
@bleve
Yes - but question is would this work because I sign both zones automatically.
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.
Daniel Salzman
@salzmdan
@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.
bleve
@bleve
Right - I really didn't even know there was such a feature :)
so yes, looks really promising.
SQFP
@Shot2
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)
Daniel Salzman
@salzmdan
@Shot2 I don't see any easy way how to do that except creating a query module for such an unusual operation. What is the use case?
Narzhan
@Narzhan
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)?
libor-peltan-cznic
@libor-peltan-cznic
@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...
SQFP
@Shot2
@salzmdan Basically, for testing purposes - e.g. ensuring all resolvers are properly configured to validate records, 'servfailing' on invalid or expired signatures and the such. Will look into a custom query module, thanks.
Vladimír Čunát
@vcunat
I don't really know these things, but wouldn't it be easier to e.g. create a sub-zone (on the same server-set) that isn't auto-signed and put the wrong records in there manually?
Daniel Salzman
@salzmdan
@vcunat :+1:
Narzhan
@Narzhan
@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)
libor-peltan-cznic
@libor-peltan-cznic
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.