Open mdavids opened 5 years ago
UPDATE: Appears to apply to experimental RRtype MR as well. And ISDN, L32, L64, LP, MG and probably others as well.
Adding all the exotic (and mostly redundant) types is quite some work, since they almost all seem to have new syntax in the data field. Quite some work and little or no gain...
That said, we're happy to review PRs. If they are high quality and low risk the'll hit the tree.
Short description
Trying to load a zone (both as master and as slave) with 'eccentric' rrtypes results in errors.
The zone is not served as a consequence.
This is the zone: https://workbench.sidnlabs.nl/zones/types.wb.sidnlabs.nl.txt
Environment
Steps to reproduce
A.1. Configure the zone as master A.2. Restart PowerDNS
B.1. Configure the zone as slave B.2. Restart PowerDNS
Expected behaviour
Be able to load the zone in case A.2 and RFC3597 behaviour in both cases A.2 and B.2. In other words; a working zone in both cases.
Actual behaviour
B.1: PowerDNS does not start and logs an error.
B.2: PowerDNS slaves the zone, stores it on disk, but refuses to serve it and logs an error.
These errors are logged:
'KX' doesn't look like a qtype, stopping loop 'GPOS' doesn't look like a qtype, stopping loop
In the case of B.1, the zone is indeed fetched with an AXFR and stored on disk. The GPOS type is shown as TYPE27 in the file, whereas KX is actually shown as KX on disk.
Other information
The zone used is part of SIDN Labs DNS workbench: https://workbench.sidnlabs.nl/
Usecase
The mentioned zone file is part of the DNS workbench, intended to test behaviour of various name server flavours. The idea is that all these name servers contain the same zone file. This particular test has a focus on RFC3597 compatibility, and thus the zonefile contains quite a number of unusual rrtypes. With the BIND backend configured we cannot load this zone, that contains rrtype KX and GPOS among others.
Description
In the ideal case RFC3597 compliancy would be desired.