High-performance authoritative DNS server. Please support the development https://donations.nic.cz/donate/?project=knot-dns
I will try to explain after some testing...
I see in the knotc man page that zone-retransfer has a '#' which means " indicates an optionally blocking operation". So, if a retransfers is triggered with or without blocking flag, will it also change how knotd processes the retransfer (ie directly vs putting the retransfer on some worker queue) or will it in nonblocking mode just respond with "OK" and then do an direct retransfer?
So
resp = ctl.receive_block() is needed for the synchronization.
You just have to increase the client control timeout
E.g.
ctl = libknot.control.KnotCtl()
ctl.connect(conf.knot_socket[system])
ctl.set_timeout(60)
try:
ctl.send_block(cmd="zone-retransfer", zone=domain_name, flags="B")
ctl.receive_block()
except libknot.control.KnotCtlError as e:
print(e)
finally:
ctl.send(libknot.control.KnotCtlType.END)
ctl.close()
9 replies
And this is a server timeout https://www.knot-dns.cz/docs/3.1/html/reference.html#timeout
Timeouts are protections against unexpected situations. You should set timeouts according to your usual needs.
Feature Request: python libknot wrapper always fires libknot.control.KnotCtlError exception in case of problems. I think there should be different exceptions for every error, or at least separate connection errors from application errors, ie: connection errors (timeout, "Os lacks ressources", refused ...) versus application errors (control socket communication works fine, but the requested operation failed, ie retransfer of a zone which is not provisioned, adding a zone which is already present ...). If you ever want to implement it I can open an issue on your gitlab.
4 replies
Hi Daniel! I just noticed a small thing with catalags:
add('2.zones.catz. PTR klaus.testet.') -> klaus.testet. added to catalog
add('3.zones.catz. PTR klaus.testet.') -> klaus.testet. added to catz zone, but ignored by catalog as already existent
delete('2.zones.catz.') -> klaus.testet. removed from catalog (although still present in catz zone)
restart knotd -> klaus.testet. readded to catalogI wonder if this should be addressed or ignored.
For example if add(3) and del(2) whould happen in the same DDNS UPDATE, then the catalog behaves correctly and purges the member and then readds the member.
Please create an issue. Libor will take a look at that when he is back from vacation.
2 replies
Having always the same uniqu-N for the same member would solve other issues. But I can not be sure that a hash function does not have a collision. So other problems. Honestly I do not know which way is better. Right now we built it that way, that we reuse the DB domain_id which is different every time a domain is removed and readded from/to PowerDNS.
4 replies
^ I think that the latest draft allows just one label for id
1 reply
FYI Knot uses siphash for generated PTR record owners
there must be unique per server salt to avoid collision.
we used hostname fqdn but it could be uuid or whatever.
That is if hash is calculated from domain name.
it's required by rfc that it is unique id.
so salt + zone is enough to generate unique enough but without salt it's guaranteed that there is collision if two knot-dns servers generate catalog zone.
Note: I haven't tried catalog zone generation because I wrote our implementation before there was automatic genreation so I haven't really checked how genration works.
we just used fqdn of primary server as salt because it was good enough for our purposes.
so foobar.fi. must have different id on two catalog zones.
actually. name of the catalog zone would be better for salt than fqdn of primary server :)
I didn't think of that when I wrote our catalog zone generator.
The bug mentined there has already been fixed afaik.
Might be good idea to remove from docs.