NAMED-RRCHECKER(1) BIND 9 NAMED-RRCHECKER(1)

named-rrchecker - syntax checker for individual DNS resource records

named-rrchecker [-h] [-o origin] [-p] [-u] [-C] [-T] [-P]

named-rrchecker reads a single DNS resource record (RR) from standard input and checks whether it is syntactically correct.

CLASS TYPE RDATA

  • Input must not start with an owner (domain) name
  • The CLASS field is mandatory (typically IN).
  • The TTL field must not be present.
  • RDATA format is specific to each RRTYPE.
  • Leading and trailing whitespace in each field is ignored.

Format details can be found in RFC 1035 Section 5.1 <https://datatracker.ietf.org/doc/html/rfc1035.html#section-5.1> under <rr> specification. RFC 3597 <https://datatracker.ietf.org/doc/html/rfc3597.html> format is also accepted in any of the input fields. See Examples.

This option specifies the origin to be used when interpreting names in the record: it defaults to root (.). The specified origin is always taken as an absolute name.

This option prints out the resulting record in canonical form. If there is no canonical form defined, the record is printed in RFC 3597 <https://datatracker.ietf.org/doc/html/rfc3597.html> unknown record format.

This option prints out the resulting record in RFC 3597 <https://datatracker.ietf.org/doc/html/rfc3597.html> unknown record format.

These options do not read input. They print out known classes, standard types, and private type mnemonics. Each item is printed on a separate line. The resulting list of private types may be empty

This option prints out the help menu.

Pay close attention to the echo command line options -e and -n, as they affect whitespace in the input to named-rrchecker.

  • Valid input is in RFC 1035 <https://datatracker.ietf.org/doc/html/rfc1035.html> format with no newline at the end of the input.
  • Return code 0.

  • Valid input with leading and trailing whitespace.
  • Output: IN A 192.0.2.1
  • Leading and trailing whitespace is not part of the output.


  • Valid input with a relative name as the CNAME target.
  • Output: IN CNAME target.
  • Relative name target from the input is converted to an absolute name using the default origin . (root).

  • Valid input with a relative name as the CNAME target.
  • Output: IN CNAME target.origin.test.
  • Relative name target from the input is converted to an absolute name using the specified origin origin.test

  • Valid input with an absolute name as the CNAME target.
  • Output: IN CNAME target.
  • The specified origin has no influence if target from the input is already absolute.


Special characters allowed in zone files by RFC 1035 Section 5.1 <https://datatracker.ietf.org/doc/html/rfc1035.html#section-5.1> are accepted.

  • Valid input with backslash escapes.
  • Output: IN CNAME target\..origin.test.
  • \097 denotes an ASCII value in decimal, which, in this example, is the character a.
  • \g is converted to a plain g because the g character does not have a special meaning and so the \ prefix does nothing in this case.
  • \. denotes a literal ASCII dot (here as a part of the CNAME target name). Special meaning of . as the DNS label separator was disabled by the preceding \ prefix.

  • Valid input with @ used as a reference to the specified origin.
  • Output: IN CNAME origin.test.

  • Valid input with a literal @ character (escaped).
  • Output: IN CNAME \@.origin.test.

  • Valid input with @ used as a reference to the specifed origin.
  • Output: IN CNAME prefix.\@.origin.test.
  • @ has special meaning only if it is free-standing.

  • Valid input with a trailing comment. Note the lack of whitespace before the start of the comment.
  • Output: IN A 192.0.2.1


For multi-line examples see the next section.

  • Valid TXT RR with two unquoted words and trailing whitespace.
  • Output: IN TXT "two" "words"
  • Two unquoted words in the input are treated as two <character-string>s per RFC 1035 Section 3.3.14 <https://datatracker.ietf.org/doc/html/rfc1035.html#section-3.3.14>.
  • Trailing whitespace is omitted from the last <character-string>.

  • Valid TXT RR with one character-string and trailing whitespace.
  • Output: IN TXT "two words"

•
Invalid input - the closing " is not detected before the end of the line.

  • Valid input with an escaped newline character inside character-string.
  • Output: IN TXT "with newline\010"

  • Valid multi-line input with line continuation allowed inside optional parentheses in the RDATA field.
  • Output: IN TXT "two" "words"

•
Invalid input - comments, starting with ";", are ignored by the parser, so the closing parenthesis should be before the semicolon.

  • Valid input - the comment is terminated with a newline.
  • Output: IN TXT "two" "words"

  • Valid HTTPS record
  • Output: IN HTTPS 1 . alpn="h2,h3"

  • Valid HTTPS record with individual sub-fields split across multiple lines using RFC 1035 Section 5.1 <https://datatracker.ietf.org/doc/html/rfc1035.html#section-5.1> parentheses syntax to group data that crosses a line boundary.
  • Note the missing whitespace between the closing parenthesis and adjacent tokens.
  • Output: IN HTTPS 1 . alpn="dot" port=853


  • Valid input in RFC 1035 <https://datatracker.ietf.org/doc/html/rfc1035.html> format.
  • Output in RFC 3957 <https://datatracker.ietf.org/doc/html/rfc3957.html> format: CLASS1 TYPE1 \# 4 C0000201

  • Valid input in RFC 3597 <https://datatracker.ietf.org/doc/html/rfc3597.html> format.
  • Output in RFC 1035 <https://datatracker.ietf.org/doc/html/rfc1035.html> format: IN A 192.0.2.1

  • Valid input with class and type in RFC 1035 <https://datatracker.ietf.org/doc/html/rfc1035.html> format and rdata in RFC 3597 <https://datatracker.ietf.org/doc/html/rfc3597.html> format.
  • Output in RFC 1035 <https://datatracker.ietf.org/doc/html/rfc1035.html> format: IN A 192.0.2.1

  • Valid input with RFC 9460 <https://datatracker.ietf.org/doc/html/rfc9460.html> syntax for an unknown key3 field. Syntax \001\000 produces two octets with values 1 and 0, respectively.
  • Output: IN HTTPS 1 . port=256
  • key3 matches the standardized key name port.
  • Octets 1 and 0 were decoded as integer values in big-endian encoding.

•
Invalid input - the length of the value for key3 (i.e. port) does not match the known standard format for that parameter in the SVCB RRTYPE.

•
Invalid input - the key port, when specified using its standard mnemonic name, must use standard key-specific syntax.


•
Invalid input - AXFR is a meta type, not a genuine RRTYPE.

•
Invalid input - ANY is meta class, not a true class.

•
Invalid input - the class field is missing, so the parser would try and fail to interpret the RRTYPE A as the class.


0
The whole input was parsed as one syntactically valid resource record.
1
The input is not a syntactically valid resource record, or the given type is not supported, or either/both class and type are meta-values, which should not appear in zone files.

RFC 1034 <https://datatracker.ietf.org/doc/html/rfc1034.html>, RFC 1035 <https://datatracker.ietf.org/doc/html/rfc1035.html>, RFC 3957 <https://datatracker.ietf.org/doc/html/rfc3957.html>, named(8) <#std-iscman-named>.

Internet Systems Consortium

2026, Internet Systems Consortium

@PACKAGE_VERSION@