On 5 Apr 2018, at 13:58, Kurt Andersen (b) wrote:
That seems like a regrettable limitation. Would we need further
definition
around the "well known" aspect from IETF to fix this or would it
require
ICANN-level changes to contractual terms?
Contractual changes. This is the relevant text from
https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.html
1.1. For the “Internet” (IN) Class:
1.1.1. Apex SOA record
1.1.2. Apex NS records and in-bailiwick glue for the TLD’s DNS
servers
1.1.3. NS records and in-bailiwick glue for DNS servers of
registered names in the TLD
1.1.4. DS records for registered names in the TLD
1.1.5. Records associated with signing the TLD zone (e.g., RRSIG,
DNSKEY, NSEC, NSEC3PARAM and NSEC3)
1.1.6. Apex TXT record for zone versioning purposes
1.1.7. Apex TYPE65534 record for automatic dnssec signing
signaling
1.2. For the “Chaos” (CH) Class:
1.2.1. TXT records for server version/identification (e.g., TXT
records for “version.bind.”, “id.server.”, “authors.bind”
and/or “hostname.bind.”)
Luis Muñoz
Director, Registry Operations
____________________________
http://www.uniregistry.link/
2161 San Joaquin Hills Road
Newport Beach, CA 92660
Office +1 949 706 2300 x 4242
l...@uniregistry.link
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
