RFC 7477
Child-to-Parent Synchronization in DNS
RFC 7477: Child-to-Parent Synchronization in DNS 🎀
bestie, this one is by W. Hardaker of Parsons, Inc., and it's a Standards Track doc from the IETF 🦋 It's dated March 2015 and carries ISSN 2070-1721. The title block has no Obsoletes or Updates lines, so it doesn't replace or change anything else. 💅
Abstract ✨
okay so the big idea is that a child zone in the DNS can publish a record that basically tells the parental agent "hey, you're allowed to copy and process certain records from me" 🫶 Once that record exists, the parental agent can keep an eye on it, notice when its value changes, and act on that depending on its own local policy 👀
Status of This Memo 📜
this is an Internet Standards Track doc 🌈
it's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 5741 💖
the current status, any errata, and how to send feedback on it live at http://www.rfc-editor.org/info/rfc7477 🔥
Copyright Notice ⭐
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. 💜
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this doc 🙈 Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 🍓
Table of Contents 🧚
1. Introduction ....................................................2
1.1. Terminology Used in This Document ..........................3
2. Definition of the CSYNC RRType ..................................3
2.1. The CSYNC Resource Record Format ...........................4
2.1.1. The CSYNC Resource Record Wire Format ...............4
2.1.2. The CSYNC Presentation Format .......................6
2.1.3. CSYNC RR Example ....................................6
3. CSYNC Data Processing ...........................................6
3.1. Processing Procedure .......................................7
3.2. CSYNC Record Types .........................................8
3.2.1. The NS type .........................................8
3.2.2. The A and AAAA Types ................................9
4. Operational Considerations ......................................9
4.1. Error Reporting ...........................................10
4.2. Child Nameserver Selection ................................10
4.3. Out-of-Bailiwick NS Records ...............................10
4.4. Documented Parental Agent Type Support ....................11
4.5. Removal of the CSYNC Records ..............................11
4.6. Parent/Child/Grandchild Glue Synchronization ..............12
5. Security Considerations ........................................12
6. IANA Considerations ............................................12
7. References .....................................................13
7.1. Normative References ......................................13
7.2. Informative References ....................................14
Acknowledgments ...................................................15
Author's Address ..................................................151. Introduction 🌸
so this doc says how a child zone in the DNS ([RFC1034] [RFC1035]) can publish a record to tell a parental agent (see Section 1.1 for a definition of "parental agent") that it can copy and process certain records from the child zone 💅 The record's existence and any change to its value can be monitored by a parental agent and acted on depending on local policy ✨
right now, some resource records (RRs) in a parent zone are typically expected to be in sync with the source data in the child's zone. The most common ones that should match are the nameserver (NS) records and any necessary associated address records (A and AAAA), also known as "glue records." These are called "delegation records" 🎀
it's been really hard for operators of child DNS zones to update their delegation records within the parent's set in a timely way 😭 Some of that is operator laziness, and some of it is just the complexity of maintaining a huge pile of DNS zones. Having an automated mechanism for signaling updates would make the child zone operator's maintenance burden way easier and improve the robustness of the DNS as a whole 👑
this doc introduces a new Resource Record Type (RRType) called "CSYNC" that indicates which delegation records published by a child DNS operator should be processed by a parental agent and used to update the parent zone's DNS data 🦋
this spec was not designed to synchronize DNSSEC security records, like DS RRsets 🙈 For a solution to that, see the complementary solution [RFC7344], which is designed to maintain security delegation information. Also, this spec does not address how to perform bootstrapping operations, including getting the required initial DNSSEC-secured operating environment in place 🧚
1.1. Terminology Used in This Document 💜
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🔥
these are the roles that interact in this doc, defined in the list below:
- Child: The entity on record that has the delegation of the domain from the parent
- Parent: The domain in which the child is registered
- Child DNS operator: The entity that maintains and publishes the zone information for the child DNS
- Parental agent: The entity that the child has relationship with, to change its delegation information
2. Definition of the CSYNC RRType 🍓
the CSYNC RRType has three parts in its RDATA: an SOA serial number, a set of flags, and a simple bit-list showing the DNS RRTypes in the child that should be processed by the parental agent so it can modify the DNS delegation records within the parent's zone for the child DNS operator 💖 Child DNS operators who want a parental agent to do the synchronization steps outlined in this doc MUST publish a CSYNC record at the apex of the child zone 🫶 Parental agent implementations MAY choose to query child zones for this record and process DNS record data as indicated by the Type Bit Map field in the RDATA of the CSYNC record ✨ How the data gets processed is described in Section 3 🌈
the big rules: parental agents MUST process the whole set of child data the Type Bit Map points to, or else they MUST NOT change any parental records at all. Errors from unsupported Type Bit Map bits (or other nonpunishable data) SHALL result in no change to the parent zone's delegation info for the child. And if multiple CSYNC resource records show up, parental agents MUST ignore that child's CSYNC RDATA set, because only a single CSYNC record should ever be present 🙅♀️
Parental agents MUST process the entire set of child data indicated by the Type Bit Map field (i.e., all record types indicated along with all of the necessary records to support processing of that type) or else parental agents MUST NOT make any changes to parental records at all. Errors due to unsupported Type Bit Map bits, or otherwise nonpunishable data, SHALL result in no change to the parent zone's delegation information for the child. Parental agents MUST ignore a child's CSYNC RDATA set if multiple CSYNC resource records are found; only a single CSYNC record should ever be present.
the parental agent MUST perform DNSSEC validation ([RFC4033] [RFC4034] [RFC4035]) of the CSYNC RRType data, and MUST perform DNSSEC validation of any data to be copied from the child to the parent 🔒 Parents MUST NOT process any data from any of these records if any of the validation results indicate anything other than "Secure" [RFC4034] or if any the required data cannot be successfully retrieved 💀
2.1. The CSYNC Resource Record Format 🦋
2.1.1. The CSYNC Resource Record Wire Format 🎀
the CSYNC RDATA consists of the following fields:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOA Serial |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Type Bit Map /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Type Bit Map (continued) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2.1.1.1. The SOA Serial Field 🧁
the SOA Serial field holds a copy of the 32-bit SOA serial number from the child zone 💖 If the soaminimum flag is set, parental agents querying children's authoritative servers MUST NOT act on data from zones advertising an SOA serial number less than this value 🙅♀️ See [RFC1982] for properly implementing "less than" logic. If the soaminimum flag is not set, parental agents MUST ignore the value in the SOA Serial field. Clients can set the field to any value if the soaminimum flag is unset, such as the number zero 🫶
note that a child zone's current SOA serial number may be greater than the number indicated by the CSYNC record 👀 A child SHOULD update the SOA Serial field in the CSYNC record every time the data referenced by the CSYNC record changes (e.g., an NS record or associated address record is changed) ✨ A child MAY choose to update the SOA Serial field to always match the current SOA Serial field 🌈
Parental agents MAY cache SOA serial numbers from data they use, and refuse to process data from zones older than the last instance they pulled data from 🧚
Although Section 3.2 of [RFC1982] describes how to properly implement a less-than comparison operation with SOA serial numbers that may wrap beyond the 32-bit value in both the SOA record and the CSYNC record, it is important that a child using the soaminimum flag must not increment its SOA serial number value more than 2^16 within the period of time that a parent might wait between polling the child for the CSYNC record 🍓 this one's a real warning, so don't skip it 💀
2.1.1.2. The Flags Field 🌷
the Flags field holds 16 bits of boolean flags that define operations affecting how the CSYNC record gets processed 💜 The flags defined in this document are:
0x00 0x01: "immediate"
0x00 0x02: "soaminimum"the definitions for how the flags are used live in Section 3 🦋
The remaining flags are reserved for use by future specifications. Undefined flags MUST be set to 0 by CSYNC publishers. Parental agents MUST NOT process a CSYNC record if it contains a 1 value for a flag that is unknown to or unsupported by the parental agent 🔥
2.1.1.2.1. The Type Bit Map Field 🎀
okay so the Type Bit Map field is basically the list of record types the parental agent is supposed to process, following the procedures in Section 3 🫶. It's encoded the exact same way as the Type Bit Map field of the NSEC record, see [RFC4034], Section 4.1.2 ✨. If a bit is set that a parental agent doesn't understand, the parental agent MUST NOT act upon the record 🙅♀️. Like, it must not simply copy the data, and it has to actually understand what a bit set to 1 means 💅
2.1.2. The CSYNC Presentation Format 🦋
Here's how the CSYNC presentation format goes:
- The SOA Serial field is represented as an integer.
- The Flags field is represented as an integer.
- The Type Bit Map field is represented as a sequence of RRType mnemonics. When the mnemonic is not known, the TYPE representation described in [RFC3597], Section 5, MUST be used. Implementations that support parsing of presentation format records SHOULD be able to read and understand these TYPE representations as well. 🧚
2.1.3. CSYNC RR Example 🌸
This CSYNC RR is an example entry for "example.com" that sets the NS, A, and AAAA bits, so they should be processed by the parental agent for example.com. The parental agent should pull data only from a zone using a minimum SOA serial number of 66 (0x42 in hexadecimal). Main character energy, honestly 👑
example.com. 3600 IN CSYNC 66 3 A NS AAAAThe RDATA component of the example CSYNC RR would be encoded on the wire as follows:
0x00 0x00 0x00 0x42 (SOA Serial)
0x00 0x03 (Flags = immediate | soaminimum)
0x00 0x04 0x60 0x00 0x00 0x08 (Type Bit Map)3. CSYNC Data Processing 💅
The CSYNC record and associated data must be processed as an "all or nothing" operation set. If a parental agent fails to successfully query for any of the required records, the whole operation MUST be aborted. (Note that a query resulting in "no records exist" as proven by NSEC or NSEC3 is to be considered successful.) ✨
Parental agents MAY:
- Process the CSYNC record immediately if the "immediate" flag is set. If the "immediate" flag is not set, the parental agent MUST NOT act until the zone administrator approves the operation through an out-of-band mechanism (such as through pushing a button via a web interface). 🔥
- Choose not to process the CSYNC record immediately, even if the "immediate" flag is set. That is, a parental agent might require the child zone administrator approve the operation through an out-of-band mechanism (such as through pushing a button via a web interface). 🙈
Note: how the approval is done out of band is outside the scope of this document and is implementation specific to parental agents. 💜
3.1. Processing Procedure 🌈
The following shows a sequence of steps that SHOULD be used when collecting and processing CSYNC records from a child zone. Because DNS queries are not allowed to contain more than one "question" at a time, a sequence of requests is needed. When processing a CSYNC transaction request, all DNS queries should be sent to a single authoritative name server for the child zone. To ensure a single host is being addressed, DNS over TCP SHOULD be used to avoid conversing with multiple nodes at an anycast address. 🦋
- Query for the child zone's SOA record
- Query for the child zone's CSYNC record
- Query for the child zone's data records, as required by the CSYNC record's Type Bit Map field
- Note: if any of the resulting records being queried are not authoritative within the child zone but rather in a grandchild or deeper, SOA record queries must be made for the grandchildren. This will require the parental agent to determine where the child/grandchild zone cuts occur. Because of the additional operational complexity, parental agents MAY choose not to support this protocol with children making use of records that are authoritative in the grandchildren. 🍓
- Query for the collected SOA records again, starting with the deepest and ending with the SOA of the child's.
If the SOA records from the first, middle, and last steps for a given zone have different serial numbers (for example, because the zone was edited and republished during the interval between steps 1 and 4), then the CSYNC record obtained in the second set SHOULD NOT be processed (rapidly changing child zones may need special consideration or processing). The operation MAY be restarted or retried in the future. 🫶
If the soaminimum flag is set and the SOA serial numbers are equal but less than the CSYNC record's SOA Serial field [RFC1982], the record MUST NOT be processed. If state is being kept by the parental agent and the SOA serial number is less than the last time a CSYNC record was processed, this CSYNC record SHOULD NOT be processed. Similarly, if state is being kept by the parental agent and the SOA Serial field of the CSYNC record is less than the SOA Serial field of the CSYNC record from last time, then this CSYNC record SHOULD NOT be processed. 😭
If a failure of any kind occurs while trying to obtain any of the required data, or if DNSSEC fails to validate all of the data returned for these queries as "secure", then this CSYNC record MUST NOT be processed. 💀
See the "Operational Consideration" section (Section 4) for additional guidance about processing. ✨
3.2. CSYNC Record Types 🎀
This document defines how the following record types may be processed if the CSYNC Type Bit Map field indicates they are to be processed.
3.2.1. The NS type 🌸
The NS type flag indicates that the NS records from the child zone should be copied into the parent's delegation information records for the child.
NS records found within the child's zone should be copied verbatim (with the exception of the Time to Live (TTL) field, for which the parent MAY want to select a different value) and the result published within the parent zone should be a set of NS records that match exactly. If the child has published a new NS record within their set, this record should be added to the parent zone. Similarly, if NS records in the parent's delegation records for the child contain records that have been removed in the child's NS set, then they should be removed in the parent's set as well. 🧚
Parental agents MAY refuse to perform NS updates if the replacement records fail to meet NS record policies required by the parent zone (e.g., "every child zone must have at least two NS records"). Parental agents MUST NOT perform NS updates if there are no NS records returned in a query, as verified by DNSSEC denial-of-existence protection. This situation should never happen unless the child nameservers are misconfigured. 🙈
Note that it is permissible for a child's nameserver to return a CSYNC record that removes the queried nameserver itself from the future NS or address set. 👑
3.2.2. The A and AAAA Types 🦋
The A and AAAA type flags indicates that the A and AAAA address glue records for in-bailiwick NS records within the child zone should be copied verbatim (with the exception of the TTL field, for which the parent MAY want to select a different value) into the parent's delegation information. 💖
Queries should be sent by the parental agent to determine the A and AAAA record addresses for each NS record within a NS set for the child that are in bailiwick. 🔍
Note: only the matching types should be queried. For example, if the AAAA bit has not been set, then the AAAA records (if any) in the parent's delegation should remain as is. If a given address type is set and the child's zone contains no data for that type (as proven by appropriate NSEC or NSEC3 records), then the result in the parent's delegation records for the child should be an empty set. However, if the end result of processing would leave no glue records present in the parent zone for any of the of the in-bailiwick NS records, then the parent MUST NOT update the glue address records. That is, if the result of the processing would leave no in-bailiwick A or AAAA records when there are in-bailiwick NS records, then processing of the address records cannot happen as it would leave the parent/child relationship without any address linkage. 🚨
The procedure for querying for A and AAAA records MUST occur after the procedure, if required, for querying for NS records as defined in Section 3.2.1. This ensures that the right set of NS records is used as provided by the current NS set of the child. That is, for CSYNC records that have the NS bit set, the NS set used should be the one pulled from the child while processing the CSYNC record. For CSYNC records without the NS bit set, the existing NS records within the parent should be used to determine which A and/or AAAA records to update. 🌈
4. Operational Considerations ✨
There are a number of important operational aspects to consider when deploying a CSYNC RRType. 🎀
4.1. Error Reporting 😬
There is no inline mechanism for a parental agent to report errors to operators of child zones. Thus, the only error reporting mechanisms must be out of band, such as through a web console or over email. Parental agents should, at a minimum, at least log errors encountered when processing CSYNC records. Child operators utilizing the "immediate" flag that fail to see an update within the parental agent's specified operational window should access the parental agent's error logging interface to determine why an update failed to be processed. 🧐
4.2. Child Nameserver Selection 🔎
Parental agents will need to poll child nameservers in search of CSYNC records and related data records. 🫶
Parental agents MAY perform best-possible verification by querying all NS records for available data to determine which has the most recent SOA and CSYNC version (in an ideal world, they would all be equal, but this is not possible in practice due to synchronization delays and transfer failures). 🦋
Parental agents may offer a configuration interface to allow child operators to specify which nameserver should be considered the master to send data queries, too. Note that this master could be a different nameserver than the publicly listed nameservers in the NS set (i.e., it may be a "hidden master"). 💜
Parental agents with a large number of clients may choose to offer a programmatic interface to let their children indicate that new CSYNC records and data are available for polling rather than polling every child on a frequent basis. 🌸
Children that wish to phase out a nameserver will need to publish the CSYNC record to remove the nameserver and then wait for the parental agent to process the published record before turning off the service. This is required because the child cannot control which nameserver in the existing NS set the parental agent may choose to query when performing CSYNC processing. 🙏
4.3. Out-of-Bailiwick NS Records 🌸
okay so this one is a whole vibe 😭 when a zone has NS records pointing at a domain name that is not inside the zone itself, the parent has no safe way to update the matching glue records 💀 so the child DNS operator MAY say "hey, these NS records should be synced" 🫶 and MAY set the glue record flags (A, AAAA) too. the parent will only update the glue records that sit below the child's delegation point, though. that's the boundary, bestie ✨
the grandchild situation is extra spicy 🌶️ if a child has NS records pointing at its own children (the "grandchildren"), the child SHOULD make sure the grandchildren's glue records are set up properly before publishing the CSYNC record. honestly it's imperative that the child and the grandchild are talking to each other and staying in sync 🤝 no vibes-based DNS here, periodt 💅
4.4. Documented Parental Agent Type Support 💜
parental agents that handle CSYNC records SHOULD publicly document their minimum processing characteristics. the list is giving checklist energy ✅, so here's what they should be spilling:
- The fact that they support CSYNC processing
- The Type Bit Map bits they support
- The frequency with which they poll clients (which may also be configurable by the client)
- If they support the "immediate" flag
- If they poll a child's single nameserver, a configured list of nameservers, or all of the advertised nameservers when querying records
- If they support SOA serial number caching to avoid issues with regression and/or replay
- Where errors for CSYNC processing are published
- If they support sending queries to a "hidden master"
transparency is iconic, and everyone deserves to know how the parent actually behaves 🦋
4.5. Removal of the CSYNC Records 🧚
children MAY delete the CSYNC record once they notice the parent zone has published the records it needed 🎀 this is a glow-up for everyone. with the CSYNC record gone, the parental agent only has to check for the CSYNC record, and it can stop processing as soon as it finds it missing. no more constantly re-querying the CSYNC record and all the matching records. less work for the child AND the parental agent, which is so efficient it's kind of unhinged 😌✨
4.6. Parent/Child/Grandchild Glue Synchronization 🍓
when a child publishes a CSYNC record that syncs NS and A/AAAA glue records, and that NS record points at a child of the child (a grandchild of the parent), the glue records in the child have to point at the correct real addresses the grandchild actually publishes. this is critical, no cap 🔥 it's assumed that a child using a grandchild's nameserver is in very careful synchronization with that grandchild, and this specification requires exactly that.
5. Security Considerations 🔐
okay this section is serious, so buckle up 😭💀 this specification requires DNSSEC so the parent can confirm the data being updated wasn't tampered with by third parties. parental agents implementing CSYNC processing MUST ensure all DNS transactions are validated by DNSSEC as "secure". and clients deploying CSYNC MUST ensure their zones are signed, current, and properly linked to the parent zone with a DS record that points to an appropriate DNSKEY of the child's zone. no shortcuts, bestie 🔒
this spec does NOT cover bootstrapping, meaning how to get the initial DNSSEC-secured setup in place. the protocol also was never designed to sync DNSSEC security records like DS pointers or the CSYNC record itself. so implementations MUST NOT use it to synchronize DS records, DNSKEY materials, CDS records, CDNSKEY records, or CSYNC records. future documents extending this protocol MUST NOT offer the ability to synchronize DS, DNSKEY materials, CDS records, CDNSKEY records, or CSYNC records either. for that job, check out the complementary solution in [RFC7344] for maintaining security delegation information 🦋
the replay protection is the scariest part 🙈 to make sure an older CSYNC record using the soaminimum flag can't be replayed to roll values back, the SOA serial number MUST NOT be incremented by more than 2^16 during the lifetime of the signature window of the associated RRSIGs signing the SOA and CSYNC records. and this applies regardless of whether the increment causes the 2^32 bit serial number field to wrap. stay on top of your serials, queen 👑
6. IANA Considerations 🌈
this document defines a brand new DNS Resource Record Type called "CSYNC" ✨ IANA has assigned a code point for it from the "Resource Record (RR) TYPEs" sub-registry of the "Domain Name System (DNS) Parameters" registry (http://www.iana.org/assignments/dns-parameters), and it looks like this:
TYPE Value Meaning Reference
----- ------ -------------------------- -----------
CSYNC 62 Child-to-Parent Synchronization [RFC7477]IANA also created and maintains a sub-registry called the "Child Synchronization (CSYNC) Flags" registry, which lives under the "Domain Name System (DNS) Parameters" registry. the initial values are below 💅
a "Standards Action" [RFC5226] is required to assign a new flag value. this registry holds a set of single-bit "Flags" for the CSYNC record inside the 16-bit Flags field, so a maximum of 16 flags may be defined. the initial assignments are:
Bit Flag Description Reference
---- ------ ------------- -----------
Bit 0 immediate Immediately process this [RFC7477],
CSYNC record. Section 3
Bit 1 soaminimum Require a SOA serial [RFC7477],
number greater than the Section 2.1.1.1
one specified.7. References 📚
7.1. Normative References 🔗
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996, <http://www.rfc-editor.org/info/rfc1982>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003,
<http://www.rfc-editor.org/info/rfc3597>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.7.2. Informative References 📖
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987,
<http://www.rfc-editor.org/info/rfc1035>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC7344] Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
DNSSEC Delegation Trust Maintenance", RFC 7344, September
2014, <http://www.rfc-editor.org/info/rfc7344>.Acknowledgments 💖
a huge thank you to Warren Kumari and Olafur Gudmundsson 🫶 their work on the CDS record type helped inspire this document, and they gave us the definition of "parental agent" plus a ton of real contributions to the text. thank you also to Ed Lewis, who had many conversations with the author about the issues around parent/child relationships and synchronization. honestly, much of this work is built on the careful analysis of these three legends ✨
thank you to everyone who contributed text or detailed reviews (in no particular order): Matthijs Mekking, Petr Spacek, JINMEI Tatuya, Pete Resnick, Joel Jaeggli, Brian Haberman, Warren Kumari, Adrian Farrel, Alia Atlas, Barry Leiba, Richard Barnes, Stephen Farrell, and Ted Lemon 🌟 and lastly, DNSOP WG chairs Tim Wicinski and Suzanne Woolf have been a tremendous help in getting this document moving toward publication 🎀
a special shout-out to Roy Arends, who took on the "bite out of that hamburger" challenge while discussing this document 🍔😂
there was also a similar project, designed and developed independently by ep.net, called "Child Activated DNS Refresh" 🧚
Author's Address 🦋
Wes Hardaker
Parsons, Inc.
P.O. Box 382
Davis, CA 95617
US
Phone: +1 530 792 1913
EMail: ietf@hardakers.net📦 where this page comes from
- ietf: rfc7477 2015-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms