•

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.

-p

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.

-u

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

-h

This option prints out the help menu.

•

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.

•

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

•

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.