Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 09:31
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • 08:23
    GitLab | Libor Peltan pushed 2 commits to Knot DNS
  • Apr 07 18:01
    GitLab | Libor Peltan pushed 13 commits to Knot DNS
  • Apr 07 17:33
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • Apr 07 12:36
    GitLab | David Vasek pushed 3 commits to Knot DNS
  • Apr 07 12:15
    GitLab | Daniel Salzman pushed 2 commits to Knot DNS
  • Apr 06 18:25
    GitLab | Daniel Salzman pushed 103 commits to Knot DNS
  • Apr 06 18:09
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • Apr 06 14:28
    GitLab | David Vasek pushed 5 commits to Knot DNS
  • Apr 03 16:46
    GitLab | Libor Peltan pushed 2 commits to Knot DNS
  • Apr 03 13:26
    GitLab | Jan Hák pushed 1 commits to Knot DNS
  • Apr 03 13:22
    GitLab | Jan Hák pushed 1 commits to Knot DNS
  • Apr 03 12:59
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • Apr 03 12:35
    GitLab | Jan Hák pushed 1 commits to Knot DNS
  • Apr 03 11:08
    GitLab | Libor Peltan pushed 1 commits to Knot DNS
  • Apr 03 10:56
    GitLab | Libor Peltan pushed 2 commits to Knot DNS
  • Apr 03 10:56
    GitLab | Daniel Salzman pushed to Knot DNS
  • Apr 03 10:56
    Libor Peltan merged merge request #1114 Allow sockaddr_cmp() to ignore port if needed in Knot DNS
  • Apr 03 10:48
    Daniel Salzman opened merge request #1114 Allow sockaddr_cmp() to ignore port if needed in Knot DNS
  • Apr 03 10:47
    GitLab | Daniel Salzman pushed 1 commits to Knot DNS
Micah
@micah_gitlab
its 825 lines, including comments, i'm not sure if that counts as big
i dont think it was an actual timeout, because it would happen immediately... and the machines are on the same switch
Daniel Salzman
@salzmdan
Definitely, it's a small zone :-)
The address 0.0.0.0@46356 is suspicious
Micah
@micah_gitlab
that is our log anonymization, it would be a normal ip there typically, but our rsyslog replaces those with zeros
Daniel Salzman
@salzmdan
ok
Narzhan
@Narzhan
Hi, is it possible to setup Knot to dynamically load the zone definitions from the zone files in a specified directory and not to define all the zones and the zone files in the zone section of the configuration? In case of several tenths of zones it is hard to manually maintain them and it increases the size of the configuration.
Daniel Salzman
@salzmdan
Narzhan
@Narzhan
@salzmdan Sorry for not checking it beforehand. I will monitor that.
Daniel Salzman
@salzmdan
No problem.
Petr Špaček
@pspacek
@Narzhan BTW Knot DNS has ability to store and modify configuration internally in database, which makes it easier to modify it one-by-one.
See command knotc and press <TAB> key to get help once kresc is running.
bleve
@bleve
I'd suggest changing default for tcp-io-timeout to something bigger than 200ms which seem to be all too little.
Something like 500ms might be better default value...
Daniel Salzman
@salzmdan
Is it because of transfers?
bleve
@bleve
yes, I was forced to set bigger value because anycast dns had tcp timeout issues when doing zonexfers.
so outbound zonexfers had problems with 200ms
Daniel Salzman
@salzmdan
Ok. The primary motivation for this option and its default was to reduce possible slow loris attacks. So low values are suitable for slave servers and higher values for master servers. There is no optimal configuration. To be honest, I would rather decrease this value :-)
bleve
@bleve
Well - our slaves ARE the servers for anycast dns.
are the master servers :)
Or there should be separate setting for zonexfers for known servers using tsig.
If I could set timeout per server there wouldn't be any issue.
Daniel Salzman
@salzmdan
No, it's on a higher level of the processing. It's not that easy.
bleve
@bleve
I can imagine.
Daniel Salzman
@salzmdan
Still you can adjust the configuration! :-)
bleve
@bleve
sure - and I did for now.
@salzmdan is 2.9.2 sitll far ahead?
Daniel Salzman
@salzmdan
This week. Based on the previous release dates, you could guess when ;-)
bleve
@bleve
I haven't tracked those, I'd just think there is quite important bug fix waiting for release :)
Daniel Salzman
@salzmdan
I think there are more users who use Knot DNS on slaves than on masters. So the default for tcp-io-timeout reflects this situation. Also users with huge zones must increase the limit.
bleve
@bleve
No huge zones here :)
Daniel Salzman
@salzmdan
Probably you are on the border :-)
bleve
@bleve
Issue with anycast is some anycast service hidden masters are on the other side of the world.
when ping to slave is 119ms 200ms tcp timeout is not so good...
Daniel Salzman
@salzmdan
But this timeout doesn't count the TCP segment round trip time! There are some data available to read! For short messages (1 TCP segment) it's ok.
bleve
@bleve
ok - so network latency is not issue here?
Daniel Salzman
@salzmdan
In most cases (no transfers) no, it's not an issue.
bleve
@bleve
this is transfers.
Daniel Salzman
@salzmdan
Yes, I know. So in this case you have to tune the config.
When there are more users complaining about this default, we can change it. So far I think it's ok.
bleve
@bleve
I didn't have any problems before anycast dns service.
My own servers don't have issues with timeouts.
But those are all less than 10ms away.
bleve
@bleve
Hmh. I smell fresh software :)
In production, seem to work
bleve
@bleve
@salzmdan Back to tcp timeout. Increasing to 500ms did the trick and slaves don't get errors any more.
Micah
@micah_gitlab
hi, my slaves are having trouble refreshing one of my zones from my master, they say no usable master and I cannot see why
Daniel Salzman
@salzmdan
Hi, any logs? Try enabling debug verbosity level
Micah
@micah_gitlab
I only see refresh, remote owl not usable
and refresh, remote owl, address 0.0.0.0@53, failed (connection reset)