If you can, add the support for CIDR style netmask (/8, /24 etc). Nothing wrong without it, but when you hop between them constantly mistakes happen.
In the example.yaml you state what option 3 is required - but it's not. It is absolutely a valid way to run some network without providing a default router.[0] If this is somehow is really a requirement anywhere than that requirement should be removed.
One of the things what I often use in MS DHCP is the server wide options, so some basic option values are configured on the server level and I add/override the needed ones on the scope level.
PS while the name is amusing, it is a possible IP conflict there, especially since you clearly state you know about Dora.
[0] And you can still provide the routign info through the option 121. Even for 0/0
The config format was created primarily to be easy to generate & consume programmatically, so the format is fully 'flattened' with no real abstraction. But this may be something we add later. It's also why the option format is the way it is. I'm sure we could make some improvements there to make hand writing easier.
I appreciate your other suggestions, thanks for taking the time to look through things. I will have a look at both the router option and the CIDR input.
We've been doing Rust before this. We've rewritten some of our core components over to Rust. Discussed a bit in this post: https://medium.techatscale.com/open-heart-surgery-from-java-...
In terms of writing a DHCP server there was research looking through Github, and the conclusion was that there is a gap in the DHCP space. DHCPd was approaching EOL (and now is EOL). Others in the DHCP industry were calling for options, and it looked like Dora could potentially fill some of those asks: https://ns1.com/blog/isc-dhcp-is-eol-what-will-replace-it
(I actually contemplated writing my own dhcp server in Rust while debugging dnsmasq but felt like it's one of those real PITA kinds of projects. Managed to workaround whatever the dnsmasq problem was after a few hours.)