Nameserver registration daemon (and client)
Naming of devices on a network is often a tedious procedure, especially for IPv6 addresses, where there is often no DHCP server that knows about the devices on the network. Multicast DNS (mdns) discovery can help on the local network, but there is no authoritative way for a device to claim a name.
This daemon and associated client is an attempt to provide a solution to this naming problem.
How it works
nsregd daemon will allow a client to claim a name on a Trust On
First Use (TOFU) basis using the RFC2136 dynamic DNS update protocol. A
client claims a name by sending a DNS update request with a SIG(0)
(RFC2931) signature and including the public key corresponding to the
signature. If the name in a claim is not already taken by another
client, the client's claim will be successful and the daemon will cache
the public key and use it to verify subsequent update requests.
Once a name has been claimed by a client, that client can add and remove A and AAAA records by means of regular DNS update requests signed with the key used to claim the name. The daemon will forward these updates to one or more configured upstream authoritative nameservers.
Since the main use case for this mechanism is dynamic networks where clients can come and go without warning, a client is expected to periodically refresh any name records it creates. The daemon will expire records and remove them from its upstream servers one TTL (as specified by the client) after it was last registered. The client is expected to pick a suitable TTL for the records it creates, such as the lease time of the IP address in the record. The daemon may enforce a maximum TTL as well as filter out records; the actual records created and the TTLs before they are expired are echoed back to the client as part of the reply to a successful update request.
The daemon will only accept registrations from configured allowed subnets (and will only listen on TCP to prevent spoofing). Optionally, subsequent updates can be allowed to point to any IP addresses (to allow, say, a laptop to register itself on its home network while away from home). Clients are only allowed to register names that are one level below the configured zone name, and names can be reserved by configuration. Currently, any upstream servers supporting TSIG-authenticated updates are supported.
nsregc client included here is an implementation of a client that
will speak to the daemon as per the description above and register any
addresses found on the local machine with a configured name (which
defaults to the system hostname). The client is given one or more zones
to register with, and will attempt to find a compatible
by querying for a SRV record at the name
_nsreg._tcp.<zone>. It can
auto-discover the zone(s) to register in using the mechanism specified
in section 11 of RFC6763.
If a suitable server is found, the client will register A and AAAA records corresponding to each of the local addresses of the machine, and maintain these registrations until killed. In addition, the client will attempt to listen for address addition and removal events via the Linux Netlink interface, and update the records accordingly. The TTL for the created records is taken from the address validity as reported by the kernel, clamped to a configurable maximum value.
nsregc are written in Go. To build, you will need a
working Go build environment.
- Make sure the
$GOPATHenvironment variable is set to a suitable value.
make depto get the Go dependencies.
maketo build both binaries.
To run the
- Pick a zone under which clients will be able to register names, such
- Generate a TSIG secret and configure the authoritative DNS server for
the parent zone (
example.orgin the example above) to allow updates to the registration zone with this secret and HMAC-SHA256 authentication.
/etc/nsregdand edit it to contain the chosen zone name and to point at the right upstream server and set the TSIG secret.
- Add a SRV record at
_nsreg._tcp.dynamic.example.orgpointing to the hostname and port that
nsregdis listening on.
- (Optional) Add an auto-discovery PTR record for
r._dns-sd._udp.local.. This needs to be resolvable by the clients and point to the configured base domain (i.e.,
nsregd daemon will re-read its configuration upon receiving a
To run the
If you configured the auto-discovery PTR record above correctly,
nsregc can run with no configuration, in which case it will generate a
key, use the system hostname as the name to register, and create records
for all IP addresses found on the system. If this is not the behaviour
you want, follow these steps to modify the configuration:
~/.nsregc/nsregc.yamland edit it to suit your preferences.
nsregc. Supply the zone(s) you wish to register with as command line parameters or in the config file.
For testing, it is possible to point
nsregc directly at
the initial query (using the --dns-server option and setting --dns-tcp),
nsregd will reply with its own address to any SRV queries.
This is still alpha quality software. In particular, the code has had NO
external security review, so use at your own risk. In particular, it is
recommended to configure your authoritative DNS server to only allow
nsregd to update its own zone.
Other limitations, in no particular order:
If communication between
nsregdand the upstream server(s) fail, no retries are currently performed. If the failure occurs while the client is first registering, the failure will be reported to the client, but if the failure occurs while entries are being automatically expired, it can result in records being left behind in the upstream DNS.
If subscribing to netlink fails, the client will be oblivious to any new addresses that appear on the configured interface(s).
nsregdtries not to send too many updates to the authoritative server, it could be smarter about this. For instance, using the prerequisites feature of RFC2136 could be a way to bring down the number of updates.
In some cases, the cache logic will end up doing a linear search through all cached records.
To repeat: There has been NO external security review. I've done my best to get it right, but for all I know it may eat your lunch (and your DNS zone).
The above is not meant to be an exhaustive list: There are probably other bugs! If you find any, please do report them (or even better, send a patch!).