TXT record parsing interop issue in named-compilezone
Summary
I have an interoperability issue where named-compilezone
and ldns-read-zone
handle the following TXT record differently:
example.com. 3600 IN TXT "foo""bar"
Note the lack of space between "foo"
and "bar"
. From reading RFC 1035 it's not clear whether the space between the two text segments is required or optional:
3.3.14. TXT RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / TXT-DATA / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: TXT-DATA One or more <character-string>s.
A <character-string>
is defined in Section 5 as follows:
<character-string> is expressed in one or two ways: as a contiguous set of characters without interior spaces, or as a string beginning with a " and ending with a ". Inside a " delimited string any character can occur, except for a " itself, which must be quoted using \ (back slash).
RFC 1035 says nothing about how consecutive <character-string>
s are delimited from each other.
named-compilezone
parses the above TXT record without issue, and in its output, re-emits the TXT record with a space between each segment:
example.com. 3600 IN TXT "foo" "bar"
My question is whether or named-compilezone
should reject the input above because it's malformed.
ldns-read-zone
parses the record incorrectly and produces a mangled record, which I've already reported here.
BIND version used
$ named-compilezone -v
9.16.7
Installed using Homebrew on macOS Big Sur, but this behaviour has also been reported on other versions/OSes.
Steps to reproduce
named-compilezone -i none -o /dev/stdout example.com example.com.txt
What is the current bug behavior?
$ named-compilezone -i none -o /dev/stdout example.com example.com.txt
zone example.com/IN: loaded serial 2021090201
example.com. 900 IN SOA ns.icann.org. noc.dns.icann.org. 2021090201 7200 3600 1209600 3600
example.com. 900 IN NS a.iana-servers.net.
example.com. 900 IN NS b.iana-servers.net.
example.com. 900 IN TXT "foo" "bar"
OK
What is the expected correct behavior?
The existing behaviour or named-compilezone
should reject the RR as malformed.
Relevant configuration files
N/A
Relevant logs and/or screenshots
N/A
Possible fixes
N/A