KEY Record Type Parsing Failure Causes Silent Fallback to Fabricated Empty Zone

[rsingha108]

Description

Technitium's zone file parser fails to parse the KEY resource record type (RR type 25, defined in RFC 2535). When zone import fails, instead of reporting an error, Technitium silently falls back to an auto-generated empty zone with a fabricated SOA record. This causes queries to return authoritative NXDOMAIN responses with incorrect SOA data, misleading clients into believing the zone was loaded successfully.

This is two bugs in one:

1. KEY record parsing failure (same as other servers lacking KEY support).
2. Silent fallback to a fabricated zone on import failure, producing misleading authoritative responses.

Steps to Reproduce

Zone File (campus.edu):

campus.edu.      300  IN  SOA  ns1.campus.edu. hostmaster.campus.edu. 2026013101 3600 600 2419200 60
campus.edu.      300  IN  NS   ns1.campus.edu.
ns1.campus.edu.  300  IN  A    192.0.2.1
sub.campus.edu.  300  IN  KEY  0 3 1 AQIDBA==

Query:

Name: sub.campus.edu.
Type: KEY

Expected Behavior

rcode: NOERROR
flags: QR AA
;ANSWER
sub.campus.edu. 300 IN KEY \# 8 0000030101020304
;AUTHORITY
campus.edu. 300 IN NS ns1.campus.edu.
;ADDITIONAL
ns1.campus.edu. 300 IN A 192.0.2.1

(This is what BIND and NSD return.)

Buggy Behavior

rcode: NXDOMAIN
flags: QR AA RA
;ANSWER (empty)
;AUTHORITY
campus.edu. 900 IN SOA <container-hostname>. hostadmin.campus.edu. 1 900 300 604800 900
;ADDITIONAL (empty)

Note the SOA in the authority section is completely different from the real zone:

• Primary NS: container hostname (e.g., "0fd599f17aa0.") instead of "ns1.campus.edu."
• Serial: 1 instead of 2026013101
• TTL: 900 instead of 300
• This is an auto-generated default zone, not the user's zone data.

Additional Details

Zone import API error response:

{
  "status": "error",
  "errorMessage": "The zone file parser failed to parse 'rdata' field on line # 4.",
  "innerErrorMessage": "Unable to parse Unknown record data: unsupported format."
}

Stack trace: ZoneFile.cs:line 596 → ReadZoneFileFromAsync()

Why this is particularly dangerous:

• The AA (Authoritative Answer) flag is set, so clients trust the NXDOMAIN as genuine.
• There is no indication to the querier that the zone failed to load.
• Unlike a SERVFAIL (which signals a server problem), an authoritative NXDOMAIN with AA looks like a valid "this name does not exist" answer.
• A resolver caching this NXDOMAIN would deny access to all records under this name for the SOA negative TTL duration.

References:

• KEY record: RFC 2535 (type 25), updated by RFC 3445 and RFC 4034.
• RFC 3597 requires DNS implementations to handle unknown RR types as opaque data.

[ShreyasZare]

Thanks for the post. However, there is no issue here to fix.

KEY record parsing failure (same as other servers lacking KEY support).

The DNS server does not support KEY record and thus there is no parse for it to parse from the zone file.

Silent fallback to a fabricated zone on import failure, producing misleading authoritative responses.

The API call gives an error which you have mentioned. In case of this error, no records are imported. So this is not "silent fallback" and the records that you see in the zone are not "fabricated" but the default SOA and NS records that exists when you create a new zone.

RFC 3597 requires DNS implementations to handle unknown RR types as opaque data.

This is already supported. For zone files, there is support for unknown records and you have to follow the unknown record syntax for it that the RFC explains in section 5 instead of using the KEY record syntax.