Background

Universal Acceptance (UA) is the state where all valid domain names and email addresses are accepted, validated, stored, processed and displayed correctly and consistently by all Internet- enabled applications, devices and systems.

Due to the rapidly changing domain name landscape, many systems do not recognize or appropriately process new domain names, primarily because they may be more than three characters in length or in a non-ASCII format. The same is true for email addresses that incorporate these new extensions.

The Universal Acceptance Steering Group (UASG), supported by Internet Corporation for Assigned Names and Numbers (ICANN), is a community-led, Internet industry-wide initiative working on creating awareness and identifying and resolving problems associated with the universal acceptance of domain names. The purpose of these efforts is to help ensure a consistent and positive experience for Internet users globally.

For more information on the UASG and recent development, visit www.uasg.tech.

Tender and Contractual Documents

One way of working toward Universal Acceptance of all domain names is to ensure that such a requirement is included in Tender and Contract documents.

‘Broccoli Issues’

The term ‘Broccoli Issues’ is used here to identify issues that are good and useful but not particularly exciting to the rest of the world. With respect to Internet issues, this will include provision of IPv6 and DNSSEC compliant services.

This document includes Good Practice clauses for Universal Acceptance as well as IPv6 and DNSSEC. Additional clauses may be added for other ‘Broccoli Issues’.

Universal Acceptance Sample Clause

UNIVERSAL ACCEPTANCE OF TLDs COMPLIANCE (Universal Acceptance (UA) is the state where all valid domain names and email addresses are accepted, validated, stored, processed and displayed correctly and consistently by all Internet-enabled applications, devices and systems.): To the extent the Services and/or Deliverables include development or provision of software and/or devices that support network or Internet connectivity of any kind, Contractor warrants and represents that all such Services and Deliverables will be fully compliant with the following provision: In whatever manner a Service/Deliverable handles a domain name, the Service/Deliverable shall do so consistently for all standards compliant names in all top-level domains listed in IANA’s Root Zone Database (accessible via https://www.iana.org/domains/root/db) at the time of delivery and guarantees consistency for three years.

IPv6 Sample Clause

IPV6 SPECIFICATION COMPLIANCE: To the extent the Services and/or Deliverables include development or provision of software and/or devices that support network or Internet connectivity of any kind, Contractor warrants and represents that all such Services and Deliverables will be fully compliant with the Internet Engineering Task Force (IETF) Internet Protocol, Version 6 Specification, sometimes referred to as the IPv6 Specification; and, in addition, will be fully backward-compatible with the Internet Engineering Task Force (IETF) Internet Protocol, Version 4 Specification, sometimes referred to as the IPv4 Specification, including without limitation having the capabilities: (a) to create or receive, process, and send or forward (as appropriate) IPv6 packets in mixed IPv4/IPv6 environments, and (b) to interoperate with other iPv6 compliant software, devices and websites on networks supporting only IPv4, only IPv6, and both IPv4 and IPv6. The expectation is that any networked application or service developed for “US” would operate irrespective of whether such services were accessed using IPv4 or IPv6.

DNSSEC Sample Clause

DNSSEC COMPLIANCE: To the extent the Services and/or Deliverables include development, provision, and/or use of the domain names, Contractor warrants and represents that all such Services and Deliverables will be fully compliant with the following provisions:

a) The Service/Deliverable is consistent with the definitions contained in the following list of RFCs and applicable errata, as the RFCs apply to the Service/Deliverable. The titles given here are representative, not the full name to improve readability of the list.

b) For Services/Deliverables making use of data obtained via DNS responses, DNSSEC validation must be active, use the IANA DNS Root Key Signing Key set (available at https://www.iana.org/dnssec/files) as a trust anchor, and support the updating of the Key Signing Key via RFC 5011 (and any revisions)

c) Services/Deliverables publishing zone data must DNSSEC-sign the zone data and describe the signing procedure in a document as described in RFC 6841, A Framework for DNSSEC Policies and DNSSEC Practice Statements.