desec-io
Support classless IPv4 reverse DNS domains
The naming scheme for classless IPv4 reverse DNS domains is defined in IETF RFC 2317, e.g.
$ORIGIN 128/26.2.0.192.in-addr.arpa.
@ IN SOA ns.B.domain. hostmaster.B.domain. (...)
@ NS ns.B.domain.
@ NS some.other.name.server.too.
;
129 PTR host1.B.domain.
130 PTR host2.B.domain.
131 PTR host3.B.domain.
The deSEC web-interface does not allow to enter slashes in domain names.
Please support classless IPv4 reverse DNS domains.
As synchronizing the forward and reverse zones manually is quite error-prone, I suggest to add/update/delete A/AAAA-RRs automatically in the forward zones if they are in the same user account like the reverse DNS zones.
I don't think we should include this functionality in the GUI, as it is very confusing to most users when slashes appear in domain names (i.e. they don't signify the boundary between hostname and URL path). However, we can consider accepting slashes for API calls, possibly depending on whether the name is a reverse DNS domain name. Would you like to create a pull request?
Regarding automatic provisioning: I'd say that needs more thinking. The first thing that comes to mind are complications related to shared IP addresses: Let's say you register example.dev for your development environment and create an A record. If you also have the rDNS zone at deSEC, the PTR record would then be created automatically. Now, you're done with development and you move your stuff to example.com. Should the PTR record be adjusted? How? (Should be put two records for the same IP? Would that unintentionally expose your other hostname that you didn't even know was public?) What happens when domains are deleted?
I'm sure there are more complications, and I suspect that the best way forward is explicit (not automatic) provisioning. This is as far as the API is concerned; I can easily imagine that a client library may have logic and configuration for such things. However, I'm happy to discuss!
In my experience API-handling is too complicated for users who just want to set up a few personal server instances on their home-NAS. The web-interface could offer an assistant which converts an IPv4/IPv6 CIDR notation into a rDNS zone name (converting an IPv6 CIDR notation into an rDNS zone name manually is quite a lot of typing and thinking backwards ;-) ).
Usually IP-addresses have only one PTR-RR (don't poke the SPAM-filters with multiple PTR-RRs) but can have multiple A/AAAA-RRs. So I suggest not to add an PTR-RR when an A/AAAA-RR is added to the forward zone but instead add an A/AAAA-RR automatically to the forward zone if a PTR-RR is added. In case there is an existing A/AAAA-RR I suggest to ask whether to replace the existing A/AAAA-RR or add a new A/AAAA-RR. When a PTR-RR or a rDNS zone is deleted, I suggest to ask wether the RR(s) in the forward zones have to be deleted, too.
As a first step to automatic synchronisation of forward and reverse zones, we could consider creating an automated check that pings users (or us) if we consider them out of sync. Only after gaining experience with this, I'd look into automatic updates, and also then probably only after opt-in by the user. (We doing automatic updates when creating domains under dedyn.io, and we found it to be error-prone and highly security relevant.)
Regarding the slashes in labels, I don't see a problem in allowing this in API and GUI. @peterthomassen What scenario do you have in mind in which users are confused?