[Feature] make it possible to read extra_records from file

[kradalby]

Use case

When use_username_in_magic_dns is removed, there will be a gap where DNS entries might not be available for some configuration.

A possible workaround is to generate these entries and put them in extra_records and generate them based on your headscale. See #1369 (comment) for more information.

Description

To facilitate this use case (and others where you want to inject dns entries programmatically, we should add the ability to consume extra_records from a JSON file.

For example, this will allow administrators to use headscale commands as part of a script to generate a JSON file by looping over the entries in the host list and create entries containing the username.

Contribution

• I can write the design doc for this feature
• I can contribute this feature

How can it be implemented?

Let us create a new config option like extra_records_path or maybe paths, which sets up a file watcher reading the DNS entries on change.
It should hash the file and check against the old hash to make sure we dont sent any updates if the file or content has not changed.

If the content has changed, propagate it to the nodes in the tailnet with our update mechanism, see if we can have a fastpath that only sends DNS updates.

[nikp123]

Furthermore for people who rely on this (as stated) incorrect behavior:
Is it a problem to make headscale itself invoke a script for generating DNS records upon a new client being registered/deregistered to the server? This would potentially reduce administration overhead and possible mistakes as well. A cron would be also fine, but this seems nicer.

[kradalby]

It would be possible to make a feature like that, but it would rely on a lot more logic and change, kind of similar to webhooks (#1543), which is on the table, but it is not really practical to block this feature on that. We have not really started to think about how that would be implemented and I think its a significantly bigger undertaking.

[nikp123]

It would be possible to make a feature like that, but it would rely on a lot more logic and change, kind of similar to webhooks (#1543), which is on the table, but it is not really practical to block this feature on that.

Webhooks seem like a fine solution as well. Thanks for the information.