dns_rdatatype_{to,from}text are not consistent for "reserved" types
Summary
As reported by a customer: https://support.isc.org/Ticket/Display.html?id=13627
I've just noticed this inconsistency: dns_rdatatype_totext() dumps "well-known" mnemonics for "reserved" types such as "EID" for 31; dns_rdatatyep_fromtext() refuses to recognize these mnemonics. Also, RRs of these types can be loaded into a zone unless the type mnemonic is used to represent it, e.g:
eid TYPE31 # 4 01020304
As a result of these, some awkward things can happen. For example, you can sign a zone containing these records, but the resulting zone file uses the mnemonic for them and RRSIG/NSEC[3]:
eid.example.com. 3600 IN EID # 4 ( 01020304 ) 3600 RRSIG EID 5 3 3600 ( 20181107145744 20181008145744 47451 exam... Cb8N+aFXgFu2s2ef5EfmvXZj05M= ) 3600 NSEC foo.example.com. EID RRSIG NSEC
So the signed zone can't be loaded:
8-Oct-2018 09:16:34.910 sigs/example.zone.signed:87: unknown RR type 'EID' 08-Oct-2018 09:16:34.910 zone example.com/IN: loading from master file sigs/example.zone.signed failed: not implemented 08-Oct-2018 09:16:34.910 zone example.com/IN: not loaded due to errors.
I suspect a similar issue can happen for a secondary zone if the zone file is saved in the "text" format.
These are certainly minor corner cases and probably no one cares in practice. But especially if so, I'd rather suggest making it more consistent (by, dumping TYPEnnn form and/or even refusing to load these types of RRs like the case of type 0) than making such a subtle failure mode happen.
Perhaps a bit more interesting case is DDNS update. Any client that is allowed to add, e.g., 'eid.example.com. 3600 IN TYPE31 # 4 01020304', can make the entire zone unloadable once the zone content is dumped to a file (I've confirmed this with 9.11.3-S2). This is probably considered a case of someone shooting their own foot, but given that the zone administrator and the owner of the update client can be different, you may probably rather want to prevent it from happening.