BIND allows an empty 'cm' value for optional LOC RDATA fields
From Support ticket https://support.isc.org/Ticket/Display.html?id=16882
(Checked the behavior with some recent version on the public git repo, but I believe it's the same for all versions that support LOC). I've just noticed somewhat awkward behavior of BIND about parsing textual LOC RDATA: it accepts an empty 'cm' part after a 'dot' of the SIZE or HORIZ/VERT PRE field. For example, it accepts the following textual RDATA as part of a zone file: 22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m 1. 22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m 1.m in this case, the VERT PRE field is specified that way (and is interpreted as "1m"). Is this intentional? The syntax format described in RFC1876 is not very formal, so it could be left to the implementor's discretion. But it looks quite awkward to me at least, and I wonder whether this was not really intentional. In that case, you may want to tighten the validation. I'm reporting this just because I've noticed it. I'm fine if you decided to keep it as is.
Then follows up with:
(Essentially the same issue but) maybe this looks even more awkward. BIND accepts these fields just containing a dot (with or without the 'm' suffix): 22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m . 22 21 54.000 N 71 6 18.000 W -24.00m 30m 100m .m and interprets it as "0.00m" (<1cm).
and one more...it even accepts just with an 'm' (interpreting it as 0.00m): 22 21 54.000 N 71 6 18.000 W -24.00m 30m 0100m m