Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 525
    • Issues 525
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 101
    • Merge requests 101
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #2896

Closed
Open
Created Sep 08, 2021 by Gavin Brown@gb

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

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

Assignee
Assign to
Time tracking