--- 1/draft-ietf-dnsop-dns-zone-digest-01.txt 2019-10-28 15:13:08.945984805 -0700 +++ 2/draft-ietf-dnsop-dns-zone-digest-02.txt 2019-10-28 15:13:09.005986323 -0700 @@ -1,23 +1,23 @@ Internet Engineering Task Force D. Wessels Internet-Draft P. Barber Intended status: Experimental M. Weinberg -Expires: March 8, 2020 Verisign +Expires: April 30, 2020 Verisign W. Kumari Google W. Hardaker USC/ISI - September 5, 2019 + October 28, 2019 Message Digest for DNS Zones - draft-ietf-dnsop-dns-zone-digest-01 + draft-ietf-dnsop-dns-zone-digest-02 Abstract This document describes an experimental protocol and new DNS Resource Record that can be used to provide a message digest over DNS zone data. The ZONEMD Resource Record conveys the message digest data in the zone itself. When a zone publisher includes an ZONEMD record, recipients can verify the zone contents for accuracy and completeness. This provides assurance that received zone data matches published data, regardless of how the zone data has been @@ -41,21 +41,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 8, 2020. + This Internet-Draft will expire on April 30, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -74,55 +74,55 @@ 1.3.1. Root Zone . . . . . . . . . . . . . . . . . . . . . . 6 1.3.2. Providers, Secondaries, and Anycast . . . . . . . . . 6 1.3.3. Response Policy Zones . . . . . . . . . . . . . . . . 7 1.3.4. Centralized Zone Data Service . . . . . . . . . . . . 7 1.3.5. General Purpose Comparison Check . . . . . . . . . . 7 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 7 2. The ZONEMD Resource Record . . . . . . . . . . . . . . . . . 7 2.1. ZONEMD RDATA Wire Format . . . . . . . . . . . . . . . . 8 2.1.1. The Serial Field . . . . . . . . . . . . . . . . . . 8 2.1.2. The Digest Type Field . . . . . . . . . . . . . . . . 8 - 2.1.3. The Reserved Field . . . . . . . . . . . . . . . . . 8 + 2.1.3. The Parameter Field . . . . . . . . . . . . . . . . . 8 2.1.4. The Digest Field . . . . . . . . . . . . . . . . . . 9 2.2. ZONEMD Presentation Format . . . . . . . . . . . . . . . 9 2.3. ZONEMD Example . . . . . . . . . . . . . . . . . . . . . 9 3. Calculating the Digest . . . . . . . . . . . . . . . . . . . 9 3.1. Canonical Format and Ordering . . . . . . . . . . . . . . 9 3.1.1. Order of RRSets Having the Same Owner Name . . . . . 10 3.1.2. Duplicate RRs . . . . . . . . . . . . . . . . . . . . 10 3.2. Add ZONEMD Placeholder . . . . . . . . . . . . . . . . . 10 3.3. Optionally Sign the Zone . . . . . . . . . . . . . . . . 10 3.4. Calculate the Digest . . . . . . . . . . . . . . . . . . 11 - 3.4.1. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11 - - 3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 11 + 3.4.1. SHA384-STABLE Calculation . . . . . . . . . . . . . . 11 + 3.4.2. Inclusion/Exclusion Rules . . . . . . . . . . . . . . 11 + 3.5. Update ZONEMD RR . . . . . . . . . . . . . . . . . . . . 12 4. Verifying Zone Message Digest . . . . . . . . . . . . . . . . 12 4.1. Verifying Multiple Digests . . . . . . . . . . . . . . . 13 5. Scope of Experimentation . . . . . . . . . . . . . . . . . . 13 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 13 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 6.1. ZONEMD RRtype . . . . . . . . . . . . . . . . . . . . . . 14 6.2. ZONEMD Digest Type . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.1. Attacks Against the Zone Digest . . . . . . . . . . . . . 14 - 7.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 14 + 7.2. Attacks Utilizing the Zone Digest . . . . . . . . . . . . 15 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 10.1. Authors' Implementation . . . . . . . . . . . . . . . . 15 - 10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 15 + 10.2. Shane Kerr's Implementation . . . . . . . . . . . . . . 16 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 12.2. Informative References . . . . . . . . . . . . . . . . . 19 - Appendix A. Example Zones With Digests . . . . . . . . . . . . . 21 + 12.2. Informative References . . . . . . . . . . . . . . . . . 20 + Appendix A. Example Zones With Digests . . . . . . . . . . . . . 22 A.1. Simple EXAMPLE Zone . . . . . . . . . . . . . . . . . . . 22 - A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 22 + A.2. Complex EXAMPLE Zone . . . . . . . . . . . . . . . . . . 23 A.3. EXAMPLE Zone with multiple digests . . . . . . . . . . . 23 A.4. The URI.ARPA Zone . . . . . . . . . . . . . . . . . . . . 24 A.5. The ROOT-SERVERS.NET Zone . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction In the DNS, a zone is the collection of authoritative resource records (RRs) sharing a common origin ([RFC7719]). Zones are often stored as files on disk in the so-called master file format @@ -318,42 +318,42 @@ "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. The ZONEMD Resource Record This section describes the ZONEMD Resource Record, including its fields, wire format, and presentation format. The Type value for the ZONEMD RR is 63. The ZONEMD RR is class independent. The RDATA of the resource record consists of four fields: Serial, Digest Type, - Reserved, and Digest. + Parameter, and Digest. This specification utilizes ZONEMD RRs located at the zone apex. Non-apex ZONEMD RRs are not forbidden, but have no meaning in this specification. A zone MAY contain multiple ZONEMD RRs to support algorithm agility [RFC7696] and rollovers. Each ZONEMD RR MUST specify a unique Digest - Type. It is RECOMMENDED that a zone include only one ZONEMD RR, - unless the zone publisher is in the process of transitioning to a new - Digest Type. + Type and Parameter tuple. It is RECOMMENDED that a zone include only + one ZONEMD RR, unless the zone publisher is in the process of + transitioning to a new Digest Type. 2.1. ZONEMD RDATA Wire Format The ZONEMD RDATA wire format is encoded as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Serial | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Digest Type | Reserved | | + | Digest Type | Parameter | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Digest | / / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.1.1. The Serial Field The Serial field is a 32-bit unsigned integer in network order. It is equal to the serial number from the zone's SOA record ([RFC1035] @@ -362,73 +362,72 @@ The zone's serial number is included here in order to make DNS response messages of type ZONEMD meaningful. Without the serial number, a stand-alone ZONEMD digest has no association to any particular instance of a zone. 2.1.2. The Digest Type Field The Digest Type field is an 8-bit unsigned integer that identifies the algorithm used to construct the digest. - At the time of this writing, SHA384, with value 1, is the only + At the time of this writing, SHA384-STABLE, with value 1, is the only standardized Digest Type defined for ZONEMD records. The Digest Type registry is further described in Section 6. Digest Type values 240-254 are allocated for Private Use as described in [RFC8126]. -2.1.3. The Reserved Field +2.1.3. The Parameter Field - The Reserved field is an 8-bit unsigned integer, which is always set - to zero. This field is reserved for future work to support efficient - incremental updates. + The Parameter field is an 8-bit unsigned integer whose meaning + depends on the Digest Type in use. For SHA384-STABLE, the Parameter + field plays no role in digest calculation or verification. 2.1.4. The Digest Field The Digest field is a variable-length sequence of octets containing the message digest. The Digest field MUST NOT be empty. Section 3 describes how to calculate the digest for a zone. Section 4 describes how to use the digest to verify the contents of a zone. 2.2. ZONEMD Presentation Format The presentation format of the RDATA portion is as follows: The Serial field MUST be represented as an unsigned decimal integer. The Digest Type field MUST be represented as an unsigned decimal integer. - The Reserved field MUST be represented as an unsigned decimal integer - set to zero. + The Parameter field MUST be represented as an unsigned decimal + integer. The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits. Whitespace is allowed within the hexadecimal text. 2.3. ZONEMD Example The following example shows a ZONEMD RR. example.com. 86400 IN ZONEMD 2018031500 1 0 ( FEBE3D4CE2EC2FFA4BA99D46CD69D6D29711E55217057BEE 7EB1A7B641A47BA7FED2DD5B97AE499FAFA4F22C6BD647DE ) 3. Calculating the Digest 3.1. Canonical Format and Ordering - Calculation of the zone digest REQUIRES the RRs in a zone to be - processed in a consistent format and ordering. Correct ordering of - the zone depends on (1) ordering of owner names in the zone, (2) - ordering of RRSets with the same owner name, and (3) ordering of RRs - within an RRSet. + Calculation of the zone digest REQUIRES RRs to be processed in a + consistent format and ordering. Correct ordering depends on (1) + ordering of owner names, (2) ordering of RRSets with the same owner + name, and (3) ordering of RRs within an RRSet. This specification adopts DNSSEC's canonical ordering for names (Section 6.1 of [RFC4034]), and canonical ordering for RRs within an RRSet (Section 6.3 of [RFC4034]). It also adopts DNSSEC's canonical RR form (Section 6.2 of [RFC4034]). However, since DNSSEC does not define a canonical ordering for RRSets having the same owner name, that ordering is defined here. 3.1.1. Order of RRSets Having the Same Owner Name @@ -444,82 +443,96 @@ MUST NOT be included in the calculation of a zone digest. 3.2. Add ZONEMD Placeholder In preparation for calculating the zone digest, any existing ZONEMD records at the zone apex MUST first be deleted. Prior to calculation of the digest, and prior to signing with DNSSEC, a placeholder ZONEMD record MUST be added to the zone apex. This serves two purposes: (1) it allows the digest to cover the Serial, - Digest Type, and Reserved field values, and (2) ensures that + Digest Type, and Parameter field values, and (2) ensures that appropriate denial-of-existence (NSEC, NSEC3) records are created if the zone is signed with DNSSEC. It is RECOMMENDED that the TTL of the ZONEMD record match the TTL of the SOA. In the placeholder record, the Serial field MUST be set to the current SOA Serial. The Digest Type field MUST be set to the value - for the chosen digest algorithm. The Reserved field MUST be set to - zero. The Digest field MUST be set to all zeroes and of length - appropriate for the chosen digest algorithm. + for the chosen digest algorithm. The Parameter field is set to a + value whose meaning depends on the Digest Type. The Digest field + MUST be set to all zeroes and of length appropriate for the chosen + digest algorithm. If multiple digests are to be published in the zone, e.g., during an algorithm rollover, there MUST be one placeholder record for each Digest Type. 3.3. Optionally Sign the Zone Following addition of placeholder records, the zone MAY be signed with DNSSEC. Note that when the digest calculation is complete, and the ZONEMD record is updated, the signature(s) for the ZONEMD RRSet MUST be recalculated and updated as well. Therefore, the signer is not required to calculate a signature over the placeholder record at this step in the process, but it is harmless to do so. 3.4. Calculate the Digest + The digest calculation details vary depending upon the Digest Type. + This document describes digest calculation for SHA384-STABLE only. + Digest calculation for additional types may be defined in future + updates to this document. + +3.4.1. SHA384-STABLE Calculation + + The Parameter field is not used in the calculation of SHA384-STABLE + message digets. The Parameter field SHOULD be set to zero in + SHA384-STABLE placeholder records. + The zone digest is calculated by concatenating the canonical on-the- wire form (without name compression) of all RRs in the zone, in the order described above, subject to the inclusion/exclusion rules - described below, and then applying the digest algorithm: + described below, and then applying the SHA384 digest algorithm + [RFC6605]: - digest = digest_algorithm( RR(1) | RR(2) | RR(3) | ... ) + digest = SHA384( RR(1) | RR(2) | RR(3) | ... ) where "|" denotes concatenation, and RR(i) = owner | type | class | TTL | RDATA length | RDATA -3.4.1. Inclusion/Exclusion Rules +3.4.2. Inclusion/Exclusion Rules When calculating the digest, the following inclusion/exclusion rules apply: o All records in the zone, including glue records, MUST be included. o Occluded data ([RFC5936] Section 3.5) MUST be included. o Duplicate RRs with equal owner, class, type, and RDATA MUST NOT be included. o The placeholder ZONEMD RR(s) MUST be included. o If the zone is signed, DNSSEC RRs MUST be included, except: o The RRSIG covering ZONEMD MUST NOT be included because the RRSIG will be updated after all digests have been calculated. 3.5. Update ZONEMD RR - Once the zone digest has been calculated, its value is then copied to - the Digest field of the ZONEMD record. + Once a zone digest has been calculated, its value is then copied to + the Digest field of the placeholder ZONEMD record. Repeat for each + digest if multiple digests are to be published. If the zone is signed with DNSSEC, the appropriate RRSIG records covering the ZONEMD RRSet MUST then be added or updated. Because the ZONEMD placeholder was added prior to signing, the zone will already have the appropriate denial-of-existence (NSEC, NSEC3) records. Some implementations of incremental DNSSEC signing might update the zone's serial number for each resigning. However, to preserve the calculated digest, generation of the ZONEMD signature at this time MUST NOT also result in a change of the SOA serial number. @@ -539,68 +552,66 @@ ZONEMD record MUST be verified. If the ZONEMD record provably does not exist, digest verification cannot be done. If the ZONEMD record does provably exist, but is not found in the zone, digest verification MUST NOT be considered successful. 3. For zones that are provably secure, the SOA and ZONEMD RRSets MUST have valid signatures, chaining up to a trust anchor. If DNSSEC validation of the SOA or ZONEMD records fails, digest verification MUST NOT be considered successful. - 4. If the zone contains more than one apex ZONEMD RR, digest - verification MUST NOT be considered successful. + 4. If the ZONEMD RRSet contains more than one RR with the same + Digest Type and Paremter, digest verification MUST NOT be + considered successful. 5. The SOA Serial field MUST exactly match the ZONEMD Serial field. If the fields to not match, digest verification MUST NOT be considered successful. 6. The ZONEMD Digest Type field MUST be checked. If the verifier does not support the given digest type, it SHOULD report that the zone digest could not be verified due to an unsupported algorithm. - 7. The Reserved field MUST be checked. If the Reserved field value - is not zero, verification MUST NOT be considered successful. - - 8. The received Digest Type and Digest values are copied to a + 7. The received Digest Type and Digest values are copied to a temporary location. - 9. The ZONEMD RR's RDATA is reset to the placeholder values + 8. The ZONEMD RR's RDATA is reset to the placeholder values described in Section 3.2. - 10. The zone digest is computed over the zone data as described in + 9. The zone digest is computed over the zone data as described in Section 3.4. - 11. The calculated digest is compared to the received digest stored + 10. The calculated digest is compared to the received digest stored in the temporary location. If the two digest values match, verification is considered successful. Otherwise, verification MUST NOT be considered successful. - 12. The ZONEMD RR's RDATA is reset to the received Digest Type and + 11. The ZONEMD RR's RDATA is reset to the received Digest Type and Digest stored in the temporary location. Thus, any downstream clients can similarly verify the zone. 4.1. Verifying Multiple Digests If multiple digests are present in the zone, e.g., during an algorithm rollover, a match using any one of the recipient's supported Digest Type algorithms is sufficient to verify the zone. 5. Scope of Experimentation This memo is published as an Experimental RFC. The purpose of the experimental period is to provide the community time to analyze and evaluate the methods defined in this document, particularly with regard to the wide variety of DNS zones in use on the Internet. Additionally, the ZONEMD record defined in this document includes a - Reserved field in the form of an 8-bit integer. The authors have a + Parameter field in the form of an 8-bit integer. The authors have a particular future use in mind for this field, namely to support efficient digests in large, dynamic zones. We intend to conduct future experiments using Merkle trees of varying depth. The choice of tree depth can be encoded in this reserved field. We expect values for tree depth to range from 0 to 10, requiring at most four bits of this field. This leaves another four bits available for other future uses, if absolutely necessary. The duration of the experiment is expected to be no less than two years from the publication of this document. If the experiment is @@ -613,33 +624,35 @@ This document defines a new DNS RR type, ZONEMD, whose value 63 has been allocated by IANA from the "Resource Record (RR) TYPEs" subregistry of the "Domain Name System (DNS) Parameters" registry: Type: ZONEMD Value: 63 Meaning: Message Digest Over Zone Data + Reference: This document 6.2. ZONEMD Digest Type This document asks IANA to create a new "ZONEMD Digest Types" registry with initial contents as follows: - +---------+-------------+-----------+-----------+ - | Value | Description | Status | Reference | - +---------+-------------+-----------+-----------+ - | 1 | SHA384 | Mandatory | [RFC6605] | - | 240-254 | Private Use | | [RFC8126] | - +---------+-------------+-----------+-----------+ + +---------+-----------------+---------------+-----------+-----------+ + | Value | Description | Mnemonic | Status | Reference | + +---------+-----------------+---------------+-----------+-----------+ + | 1 | SHA384 for | SHA384-STABLE | Mandatory | This | + | | stable zones | | | document | + | 240-254 | Private Use | - | - | [RFC8126] | + +---------+-----------------+---------------+-----------+-----------+ Table 1: ZONEMD Digest Types 7. Security Considerations 7.1. Attacks Against the Zone Digest The zone digest allows the receiver to verify that the zone contents haven't been modified since the zone was generated/published. Verification is strongest when the zone is also signed with DNSSEC. @@ -671,26 +684,27 @@ types result in larger amplification effects (i.e., DNSKEY). 8. Privacy Considerations This specification has no impacts on user privacy. 9. Acknowledgments The authors wish to thank David Blacka, Scott Hollenbeck, and Rick Wilhelm for providing feedback on early drafts of this document. - Additionally, they thank Joe Abley, Mark Andrews, Olafur Gudmundsson, - Paul Hoffman, Evan Hunt, Shumon Huque, Tatuya Jinmei, Burt Kaliski, - Shane Kerr, Matt Larson, John Levine, Ed Lewis, Matt Pounsett, Mukund - Sivaraman, Petr Spacek, Ondrej Sury, Florian Weimer, Tim Wicinksi, - Paul Wouters, and other members of the dnsop working group for their - input. + Additionally, they thank Joe Abley, Mark Andrews, Ralph Dolmans, + Richard Gibson, Olafur Gudmundsson, Paul Hoffman, Evan Hunt, Shumon + Huque, Tatuya Jinmei, Burt Kaliski, Shane Kerr, Matt Larson, John + Levine, Ed Lewis, Matt Pounsett, Mukund Sivaraman, Petr Spacek, + Ondrej Sury, Willem Toorop, Florian Weimer, Tim Wicinksi, Wouter + Wijngarrds, Paul Wouters, and other members of the dnsop working + group for their input. 10. Implementation Status 10.1. Authors' Implementation The authors have an open source implementation in C, using the ldns library [ldns-zone-digest]. This implementation is able to perform the following functions: o Read an input zone and output a zone with the ZONEMD placeholder. @@ -853,20 +867,33 @@ From -00 to -01: o Simplified requirements around verifying multiple digests. Any one match is sufficient. o Updated implementation notes. o Both implementations produce expected results on examples given in this document. + From -01 to -02: + + o Changed the name of the Reserved field to Parameter. + + o Changed the name of Digest Type 1 from SHA384 to SHA384-STABLE. + + o The meaning of the Parameter field now depends on Digest Type. + + o No longer require Parameter field to be zero in verification. + + o Updated a rule from earlier versions that said multiple ZONEMD RRs + were not allowed. + 12. References 12.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, @@ -897,22 +924,22 @@ 12.2. Informative References [CZDS] Internet Corporation for Assigned Names and Numbers, "Centralized Zone Data Service", October 2018, . [dns-over-https] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", draft-ietf-doh-dns-over-https-12 (work in - progress), June 2018, . + progress), June 2018, . [InterNIC] ICANN, "InterNIC FTP site", May 2018, . [ldns-zone-digest] Verisign, "Implementation of Message Digests for DNS Zones using the ldns library", July 2018, . @@ -979,22 +1006,22 @@ Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RootServers] Root Server Operators, "Root Server Technical Operations", July 2018, . [RPZ] Vixie, P. and V. Schryver, "DNS Response Policy Zones (RPZ)", draft-vixie-dnsop-dns-rpz-00 (work in progress), - June 2018, . + June 2018, . [ZoneDigestHackathon] Kerr, S., "Prototype implementation of ZONEMD for the IETF 102 hackathon in Python", July 2018, . Appendix A. Example Zones With Digests This appendix contains example zones with accurate ZONEMD records. These can be used to verify an implementation of the zone digest @@ -1046,24 +1073,24 @@ 616c6c6f77656420 6275742069676e6f 7265642e20616c6c 6f77656420627574 2069676e6f726564 2e20616c6c6f7765 ) A.3. EXAMPLE Zone with multiple digests Here, the EXAMPLE zone contains multiple ZONEMD records. Since only - one Digest Type is defined at this time (SHA384), this example + one Digest Type is defined at this time (SHA384-STABLE), this example utilizes additional ZONEMD records with Digest Type values in the private range (240-254). These additional private-range digests are - not verifiable, but note that their other fields (Serial, Reserved, + not verifiable, but note that their other fields (Serial, Parameter, Digest Type) are included in the calculation of all ZONEMD digests. example. 86400 IN SOA ns1 admin 2018031900 ( 1800 900 604800 86400 ) example. 86400 IN NS ns1.example. example. 86400 IN NS ns2.example. example. 86400 IN ZONEMD 2018031900 1 0 ( c0218e8eeb4f0275 d54c0e5ce7791f4d 23742b4756708d50