Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 23 10:55
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • Oct 22 17:35
    GitLab | David Vasek pushed 1 commits to Knot DNS
  • Oct 22 16:44
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • Oct 22 14:20
    GitLab | Daniel Salzman pushed 2 commits to Knot DNS
  • Oct 22 14:20
    GitLab | Jakub Ružička pushed to Knot DNS
  • Oct 22 14:20
    Daniel Salzman merged merge request #1206 doc: fix typos found by lintian in Knot DNS
  • Oct 22 14:14
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • Oct 22 14:11
    GitLab | Jakub Ružička pushed 1 commits to Knot DNS
  • Oct 22 13:44
    Jakub Ružička opened merge request #1206 doc: fix typos found by lintian in Knot DNS
  • Oct 22 13:43
    GitLab | Jakub Ružička pushed 1 commits to Knot DNS
  • Oct 22 08:21
    GitLab | Daniel Salzman pushed 1 commits to Knot DNS
  • Oct 21 16:21
    GitLab | Libor Peltan pushed 2 commits to Knot DNS
  • Oct 21 12:37
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • Oct 21 10:13
    Libor Peltan opened merge request #1205 kdig: limit re-tries on BADCOOKIE in Knot DNS
  • Oct 21 10:13
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • Oct 21 09:57
    Daniel Salzman closed issue #692 knot with xdp in Knot DNS
  • Oct 21 09:57
    Daniel Salzman commented on issue #692 knot with xdp in Knot DNS
  • Oct 21 06:38
    mscbg commented on issue #692 knot with xdp in Knot DNS
  • Oct 20 13:16
    Libor Peltan opened merge request #1204 kxdpgun: allow override of local IP in Knot DNS
  • Oct 20 13:16
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
Daniel Lublin
@quite
Regarding the default template, other templates does not seem to inherit it.
Daniel Salzman
@salzmdan
You are correct. Templates are exclusive. But you can override template settings in the zone section.
Daniel Salzman
@salzmdan
As for the remote from acl, I understand the idea but there are some slight differences between the items. Anyway, I will reconsider possible simplification.
Daniel Lublin
@quite
should i add an issue?
Daniel Salzman
@salzmdan
It's not necessary (I have my private TODO list :-) ). But if you wish
Daniel Lublin
@quite
ah just tid anyway :) heh there yes
Daniel Salzman
@salzmdan
:-)
Micah
@micah_gitlab
I'm at 2.9.1-1 and when I push out a zone file change, and I do /usr/sbin/knotc zone-reload, I'm told in the logs error: [myzone.] zone event 'load' failed (semantic check) but if I run knotc zone-check on the zone, I dont get any complaints
can I turn up debugging somehow to find out what the sematic check failure is?
I'm able to restart knotd (systemctl restart knotd) and it seems to load it fine. Interestingly, it does a DNSSEC signing before it tries to load it
Daniel Salzman
@salzmdan
This error doesn't necessary mean that the zone itself has errors. In this case it's rather about a problematic zone change during the reload. It depends also on the configuration and journal contents. Do you know how the zone file was modified?
However, I agree the log message lacks some information.
Micah
@micah_gitlab
@salzmdan what I can tell is that it doesn't transfer the new zone to the secondaries, and isn't loaded on the primary
@salzmdan i do know how the zone was modified, I did it myself. I've had issues with the journal in the past, and have had to remove it in order for things to work ok again.
Daniel Salzman
@salzmdan
Hm. I don't remember whether 2.9.2 fixes something that you already reported. Do you have more logs or other details? :-(
Micah
@micah_gitlab
@salzmdan i dont have any more logs than that... but I can replicate this by making a change/bumping the serial, so if there is something I can do to get more info I can easily repeat the problem
I also can install 2.9.2 and see if that fixes anything
Micah
@micah_gitlab
@salzmdan ok, I upgraded to 2.9.2, and when it starts it now says, "zone event 'load' failed (not enough memory)'
there is 2gig of memory on this machine and only 600meg used
the zone is... 832 lines, including comments
Daniel Salzman
@salzmdan
@micah_gitlab you are a very good tester. What the heck are you doing?! :-D
Could you start with an empty journal? Maybe there is still something bad in it. Also you could switch back from journal-content: all to journal-content: changes. It was a workaround for your case IRC.
Micah
@micah_gitlab
@salzmdan i dont know what I'm doing !! :)
Starting with an empty journal would be: stop knotd, remove the journal, start knotd (after changing journal-content:)
Daniel Salzman
@salzmdan
Yes
Micah
@micah_gitlab
ok, did those two things. The last entry in the log now is DNSSEC, signing started, surprised it hasn't said DNSSEC, successfully signed yet as that was 5minutes ago, but maybe I'm expecting the wrong thing
Daniel Salzman
@salzmdan
Could you share all the logs since the server start? Use the private chat.
libor-peltan-cznic
@libor-peltan-cznic
Regarding the "semantic check" error: wasn't the error message preceded by a warning like "zone file changed without SOA serial update" or such?
Daniel Salzman
@salzmdan
Strangely, there were no other warnings. But zonefile-load: difference-no-serial solved that.
Kristian Klausen
@klausenbusk
Does it makes sense to "sandbox" knot? (https://www.ctrl.blog/entry/systemd-opensmtpd-hardening.html)
Kristian Klausen
@klausenbusk
It seems to work (I will open a PR tomorrow):
diff --git a/distro/common/knot.service b/distro/common/knot.service
index 750fadb55..5270f6b5a 100644
--- a/distro/common/knot.service
+++ b/distro/common/knot.service
@@ -10,6 +10,32 @@ User=knot
 Group=knot
 CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SETPCAP
 AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_SETPCAP
+TemporaryFileSystem=/run:ro /var:ro
+BindPaths=/run/systemd
+BindPaths=/run/knot
+BindPaths=/var/lib/knot
+LockPersonality=yes
+MemoryDenyWriteExecute=yes
+NoNewPrivileges=yes
+PrivateDevices=yes
+PrivateTmp=yes
+PrivateUsers=yes
+ProtectControlGroups=yes
+ProtectHome=yes
+ProtectHostname=yes
+ProtectKernelLogs=yes
+ProtectKernelModules=yes
+ProtectKernelTunables=yes
+ProtectSystem=strict
+RemoveIPC=yes
+RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
+RestrictNamespaces=yes
+RestrictRealtime=yes
+RestrictSUIDSGID=yes
+SystemCallArchitectures=native
+SystemCallErrorNumber=EPERM
+SystemCallFilter=@system-service
+SystemCallFilter=~@resources
 ExecStartPre=/usr/sbin/knotc conf-check
 ExecStart=/usr/sbin/knotd
 ExecReload=/usr/sbin/knotc reload
Kristian Klausen
@klausenbusk
Edit: PrivateUsers=yes should be PrivateUsers=no
Vladimír Čunát
@vcunat

I've seen a subset of these restrictions used by some people with knotd, without any complaint on those for about a year now.

From a quick look I'm not sure if it's good to force /var/lib/knotnon-persistent (tmpfs).

Daniel Salzman
@salzmdan
@klausenbusk I don't think that all the options are necessary. It would also require testing on all supported distributions. I like simplicity and don't like overusing systemd features :-)
Vladimír Čunát
@vcunat
BTW, it's nice that individual users can add such restrictions through overrides, i.e. without editing the unit files installed from package.
Daniel Salzman
@salzmdan
:+1:
Kristian Klausen
@klausenbusk
@salzmdan None of them are "necessary, but principle of least privilege :)
You can't abuse power you don't have.
Vladimír Čunát
@vcunat
Sure, but it tends to be hard to really think through all possible situations in advance. For example in a distro we thought to use DynamicUser=yes, but in time it turned out too problematic (e.g. wrt. key handling).
Kristian Klausen
@klausenbusk
DynamicUser is a different beast (IMHO). Should I open a MR?
Daniel Salzman
@salzmdan
You can :-) Btw, what is your distro on which you tested this configuration?
Kristian Klausen
@klausenbusk
Arch Linux, so newest version of more or less all packages.
Daniel Salzman
@salzmdan
Keep in mind that we build packages for Debian Stretch, Ubuntu Xenial and so on...
Kristian Klausen
@klausenbusk
Why can't i fork the repository? https://gitlab.labs.nic.cz/knot/knot-dns
Vladimír Čunát
@vcunat
IIRC at least TemporaryFileSystem is too new feature for some of those distros.
"External" users can't fork by default on our GitLab instance, unfortunately.
Kristian Klausen
@klausenbusk
So what shall I do? Open a Github PR?
Daniel Salzman
@salzmdan
Just wait, please.
what is your username?
Kristian Klausen
@klausenbusk
klausenbusk
@vcunat Would it be possible to ship different systemd service files per distro?