Inconsistency regarding final dot

[gadall]

Zone names are required to be fully qualified with a final dot. However server names, when added to zones as NS records, are appended with a dot. Thus if they were entered with a final dot, we now have two dots, like so: ns1.example.com.. which causes an error when loading the zone.
In other DNS management interfaces, zone names are assumed to be FQDN and a final dot is not required. Sometimes if provided it is removed, for consistency.
With server names, I suppose we can avoid adding a dot when creating an NS record, if the server name already ends with a dot.

[pacoorozco]

Zone names are validated and the validation ensures that the zone name is a FQDN.
For NS records this validation is not in place because using non-FQDN names is something allowed and interesting.

Let's imagine that we want to delegate a subdomain gadall.domain.com, you can do it by creating this NS record

$ORIGIN domain.com
gadall IN NS 10.10.10.1

or equivalently

$ORIGIN domain.com
gadall.domain.com. IN NS 10.10.10.1

probind allows both... If you enter gadall you are referring to the first one, if you use a FQDN to the second one. In both cases I see that the data in the zone file is correct.

Have you seen it differently?

[gadall]

Zone file generation seems to be completely broken in the current main branch so my comments will refer to the previous version, against which this issue was originally opened.

1. This is a GUI for DNS. From my point of view, the target audience are the kind of people who update DNS records with a GUI, and presumably require a GUI and aren't necessarily proficient with CLI. Personally I find the user experience of nsupdate quite satisfactory. The target audience here have their expectations set by the common interfaces of the major service providers.
2. If zone names must be FQDN then we can and should assume they are FQDN, as is normal. We don't need to force the user to go out of their way to hit the period key. We can do better. If internally we want zone names to always end with a dot we can append one to the input, if missing, right before validation.
3. Adding a zone-relative NS record like you show is only possible if adding an actual NS record. I was talking about NS records generated from Probind's notion of "Servers". zone-relative doesn't make much sense here, unless you happen to have only one zone, but it is also just impossible because probind adds a dot anyway, forcing FQDN in all cases, and it adds a dot even if the hostname string already ends with a dot, which causes breakage and this is what is fixed in my PR.

So, in summary, I suggest probind adds dots more judiciously when justified, necessary and, if possible, not hamrful.