DNS: allow update from DHCP #29

New Issue

moepman · 2019-03-25T14:21:43+01:00

moepman commented

2019-03-25 14:21:43 +01:00

In order to enable a user to simply reach a headless device such as a Raspberry Pi via DNS we should:

switch dns-intern to sqlite backend
create the zone users.binary.kitchen (or similar)
allow updates to this zone from the DHCP servers
configure the DHCP servers to update entries via nsupdate

In order to enable a user to simply reach a headless device such as a Raspberry Pi via DNS we should: * switch `dns-intern` to sqlite backend * create the zone `users.binary.kitchen` (or similar) * allow updates to this zone from the DHCP servers * configure the DHCP servers to update entries via nsupdate

moepman modified the milestone from 2020 Q4 to 2020 Q4

2020-10-12 19:54:46 +02:00

moepman modified the milestone from 2020 Q4 to 2021 Q2

2021-05-06 21:57:24 +02:00

moepman commented

2021-05-06 21:58:07 +02:00

I am still not sure how to handle sync/resync/consistency issues considering that there are two DHCP and two DNS servers running

noby commented

2021-05-14 01:05:11 +02:00

Why do we need two DHCP or DNS servers? Couldn't we just allow ddns updates from the user ip range to the users.binary.kitchen zone?

moepman commented

2021-05-14 13:32:07 +02:00

We need two DHCP and DNS servers for redudndancy reasons, because without an IP and being able to resolve domain names the doorlock won't work.

I think I'll just do a proof of concept, maybe with users.binary.kitchen as its own zone so it can update independently of the server/service entries.

We need two DHCP and DNS servers for redudndancy reasons, because without an IP and being able to resolve domain names the doorlock won't work. I think I'll just do a proof of concept, maybe with `users.binary.kitchen` as its own zone so it can update independently of the server/service entries.

moepman commented

2021-05-14 18:35:25 +02:00

ISC dhcpd can only send ddns updates to a server running on port 53 - this means that we are required to use dnsdist as frontend for DNS running on port 53 which will then forward queries (and updates) to either the local auth. server, or the local recursor - depending on the domain.

moepman commented

2021-05-14 18:43:23 +02:00

Another problem to solve is the initial content of the users.binary.kitchen zone.

Vague idea: check if if the zone name is in the output of pdnsutil list-all-zones and if not call pdnsutil load-zone

Another problem to solve is the initial content of the `users.binary.kitchen` zone. Vague idea: check if if the zone name is in the output of `pdnsutil list-all-zones` and if not call `pdnsutil load-zone`

moepman self-assigned this 2021-05-15 16:56:06 +02:00

moepman commented

2021-05-15 17:06:03 +02:00

Another question is how to keep the DNS zones in sync.

First idea would be to make one of the authoritative servers primary for the users.binary.kitchen zone and the other secondary. Which would mean no updates at all while the primary is down. On the other hand both servers would be in sync and give consistent answers.

Another Option would be to always update both servers, but this approach might eventually go out of sync if one of them is offline.

Another question is how to keep the DNS zones in sync. First idea would be to make one of the authoritative servers primary for the `users.binary.kitchen` zone and the other secondary. Which would mean no updates at all while the primary is down. On the other hand both servers would be in sync and give consistent answers. Another Option would be to always update both servers, but this approach might eventually go out of sync if one of them is offline.

moepman commented

2021-05-16 12:21:32 +02:00

Proof of concept (Update from dhcpd against localhost, dnsdist on port 53, sqlite backed zone) seems to work okay so far.