Policy Networks | Internet Governance Forum
Skip to main content
Welcome to the United Nations
|
Department of Economic and Social Affairs
العربية
简体中文
English
Français
Русский
Español
العربية
简体中文
English
Français
Русский
Español
Menu
Quick links
I am new to the IGF
Subscribe to our mailing list
Register for an IGF activity
Donate to the IGF
Find/Become a Resource Person
Search
Feed me
Log in
Header Menu
About
About
About IGF
FAQs – About IGF & IGF 2025
Get Started
Team
IGF Donors
Work With Us
IGF Mailing Lists
Contact Us
IGF Leadership Panel
Multi-stakeholder Advisory Group
Multi-stakeholder Advisory Group
MAG Terms of Reference
MAG Chair Terms of Reference
MAG Chair's Blog
MAG Members
MAG Members
Previous MAG Members
MAG Working Groups
MAG Meeting Records
MAG Activities
MAG Member Dashboard
IGF 2026 MAG Renewal
UN Global Advocate
IGF Expert Group Meeting (2026)
IGF Expert Group Meeting 2026
EGM Report
The IGF and UN Processes
Code of Conduct
Newsletter
Press
Support the IGF
Donate
IGF Trust Fund
Donors' Contributions to Main Trust Fund
Global South Contributions
Host the IGF
Share Your Experience - "Voices of the IGF"
IGF 2026
IGF 2026 Entry Page
IGF 2026 Call for Session Proposals
IGF 2026 Call for Village Booths
IGF 2026 Call for Remote Hubs
IGF 2026 First Open Consultations & MAG Meeting
IGF 2026 Timeline
IGF 2026 Intersessional Work Proposals
IGF 2026 Proposed Thematic Inputs
IGF 2025 Stocktaking & 2026 Improvements
IGF 2026 Call for MAG Nominations
IGF 2026 Call for NRI Grants
IGF 2026 Judiciary Engagement
IGF 2026 Parliamentary Track
IGF 2026 Youth Track
IGF 2026 Business Engagement
Intersessional Work
Thematic Intersessional Work
Dynamic Coalitions
Dynamic Coalitions
DC Coordination Activities
Terms of Reference
Best Practice Forums
Policy Networks
Policy Network on Artificial Intelligence
Policy Network on Cybersecurity
Policy Network on Open Digital Infrastructure
Policy Network on Digital Inclusion
Previous Work
Capacity Development
Intersessional News
National and Regional IGFs
Overview
NRIs FAQs
NRIs Toolkit: How to Start Your IGF Initiative?
Youth Initiatives
Regional IGF Initiatives
National IGF Initiatives
All National Initiatives
Africa
Asia Pacific
Eastern Europe
GRULAC
WEOG
NRI Dashboard
NRIs Library
NRIs Collaborative Work
IGF 2026 NRIs Preparatory Process
Brochures about NRIs
IGF NRIs Call for Grants
NRIs Meetings - overview
Publications and Reports
IGF Brochures and Select Publications
Publications and Reports
IGF Annual Meeting Proceedings
IGF Intersessional Work
CSTD Reports
UN GA Resolutions on ICT for SD
Calendar
Intersessional
In between the two annual
IGF
meetings, the community works on several substantive activities and presents and discusses them at the annual
IGF
meeting.
Breadcrumb
Home
Intersessional Work
Policy Networks
IGF
Policy Networks are open, multistakeholder groups that work throughout the year on key Internet governance issues of global priority. Their focus areas are determined through a bottom-up, inclusive and consultative process. Policy Networks bring together stakeholders from governments, civil society, the private sector, the technical community and intergovernmental organizations from all parts of the world to exchange expertise, identify policy challenges and develop substantive outputs.
Working Modalities and Way to Participate
Policy Networks are facilitated by multistakeholder working groups of experts, formed through broad bottom-up community consultations. Members of the
IGF
Multistakeholder Advisory Group (
MAG
) serve as facilitators, while the
IGF
Secretariat provides overall neutral coordination and supports the development of the final outputs. The organizational structure of each group may further evolve based on the consensus of participating stakeholders and may include roles such as chairs or co-chairs, as well as leads for specific substantive workstreams.
All Policy Networks operate through an open, inclusive and bottom-up consultative process. Interested stakeholders are invited to subscribe to the dedicated mailing lists or contact the
IGF
Secretariat for further information.
IGF
Policy Networks in 2026
For the 2026 cycle, the community was invited to submit proposals. The proposals
received
were reviewed by the 2026 Multistakeholder Advisory Group (
MAG
), which considered their quality, relevance and potential contribution to addressing globally significant digital policy issues. Based on this assessment, the
IGF
2026 cycle focuses on the following four Policy Networks:
Policy Network on Artificial Intelligence (PNAI)
Policy Network on Cybersecurity (PNC)
Policy Network on Digital Inclusion (PNDI)
Policy Network on Open Digital Infrastructure (PNODI)
Past Work and Learn More
Below are the
IGF
Policy Networks implemented since 2015.
IGF Policy Options for Connecting and Enabling the Next Billion(s)
IGF Policy Network on Environment (PNE)
Policy Network on Meaningful Access (PNMA)
Policy Network on Internet Fragmentation (PNIF)
Policy Network on Artificial Intelligence (PNAI)
More about the concept of policy networks is available
here
.
Join a Policy Network
Participation is open to all stakeholders. Whether you are an expert, policymaker, researcher, practitioner, community organizer or eager to learn and network, you can contribute to the discussions.
Subscribe to
open mailing lists
and
IGF newsletter
Join regular
monthly meetings
Share research, experience and case studies
Engage at the activities organized at
IGF
annual meeting and others
Subscribe to mailing lists
|
Subscribe to IGF Newsletter
|
Contact the IGF Secretariat
UNITED NATIONS
Contact information
United Nations
Secretariat of the Internet Governance Forum (IGF)
Villa Le Bocage
Palais des Nations,
CH-1211 Geneva 10
Switzerland
igf [at] un [dot] org
+41 (0) 229 173 411
Additional Information
Donate to the IGF
Participant Funding
Vacancies
Multilingualism
Accessibility Statement
Resources
Publications
Press
Glossary
CONNECT WITH US
Donate
Footer menu
Copyright
Privacy Notice
Terms of Use
Accessibility menu
Contrast settings
Font size
Letter spacing
Line height
Images
Font
Reset the settings


About Contracted Parties

About Contracted Parties
العربية
中文
English
Français
Pусский
Español
Logo
en
Search
Search
Search
Filtered Search
Log In
Sign Up
Are you sure you want to sign out from
https://www.icann.org
?
Yes
Cancel
If you want to sign out from both
https://www.icann.org
and ICANN Account,
click here
.
ICANN
Get Started
News and Media
Policy
Public Comment
Resources
Community
Quicklinks
Get Started
News and Media
Policy
Public Comment
Resources
Community
Quicklinks
Contracted Parties
ICANN’s contracted parties consist of generic top-level domain (gTLD) registry operators and accredited registrars.
Subscribe
Contracted Parties Home
Accredited Registrars
Registry Operators
Consensus Policies and Advisories
About Contracted Parties
Accredited Registrars
An accredited registrar is an entity that offers domain name registration services to registrants in generic top-level domains (gTLDs). The relationship between ICANN and every ICANN-accredited registrar is governed by the Registrar Accreditation Agreements (RAAs), which sets out the obligations of both parties.
READ MORE
Registry Operators
The role of the registry operator within the Internet ecosystem is to keep the master database of all domain names registered in each top-level domain (TLD) and generate the "zone file" that allows computers to route Internet traffic to and from TLDs anywhere in the world.
READ MORE
Accredited Registrars
An accredited registrar is an entity that offers domain name registration services to registrants in generic top-level domains (gTLDs). The relationship between ICANN and every ICANN-accredited registrar is governed by the Registrar Accreditation Agreements (RAAs), which sets out the obligations of both parties.
READ MORE
Registry Operators
The role of the registry operator within the Internet ecosystem is to keep the master database of all domain names registered in each top-level domain (TLD) and generate the "zone file" that allows computers to route Internet traffic to and from TLDs anywhere in the world.
READ MORE
Helpful Links
Contracted Parties Communications
Consensus Policies
Contracted Parties Summit
Contractual Compliance
GDS Metrics
Global Support
ICANN Public Meetings
Internationalized Domain Names
Naming Services Portal
New gTLD Program: Next Round
Relationship Between Domain Name Industry Parties
Universal Acceptance
Contracted Parties Communications
Consensus Policies
Contracted Parties Summit
Contractual Compliance
GDS Metrics
Global Support
ICANN Public Meetings
Internationalized Domain Names
Naming Services Portal
New gTLD Program: Next Round
Relationship Between Domain Name Industry Parties
Universal Acceptance
Connect with us
X
Instagram
Facebook
Youtube
LinkedIn
Flickr
Soundcloud
Explore Our Social Media Hub and Follow Us on ICANN's Official Accounts
Who We Are
ICANN For Beginners
ICANN Learn
Participate
Groups
Board Members
CEO Corner
Staff
Careers
Public Responsibility
Contact Us
Locations
Report Security Issues
Certificate Authority
Registry Liaison
Ombuds
Complaints Office
Media Resources
Accountability and Transparency
Accountability Mechanisms
Document Disclosure
Independent Review Process
Requests for Reconsideration
Empowered Community
Employee Anonymous Hotline Policy and Procedures
Governance
Governance Documents
Agreements
Organizational Reviews
Specific Reviews
Annual Report
Financials
Planning
RFPs
Litigation
Correspondence
Help
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Name Collision
ICANN Lookup
Registration Data Request Service (RDRS)
Data Protection
Data Privacy Practices
Privacy Policy
Terms of Service
Cookies Policy
© Internet Corporation for Assigned Names and Numbers
Privacy Policy
Terms of Service
Cookies Policy
Privacy Policy
Terms of Service
Cookies Policy


RFC 1358: Charter of the Internet Architecture Board (IAB) | RFC Editor
Skip to content
Info
RFC
1358
:
Charter of the Internet Architecture Board (IAB)
L. Chapin
Informational
This RFC is now obsolete
, see
RFC
1601
.
Network Working Group                                   L. Chapin, Chair
Request for Comments: 1358                   Internet Architecture Board
                                                             August 1992
Charter of the Internet Architecture Board (IAB)
Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.
Section 1
.

   The Internet Architecture Board (IAB) shall be constituted and shall
   operate as a technical advisory group of the Internet Society.  Its
   responsibilities shall include:

      (1)  Expert and experienced oversight of the architecture of the
           worldwide multiprotocol Internet.

      (2)  The editorial management and publication of the Request for
           Comments (RFC) document series, which constitutes the
           archival publication series for Internet Standards and
           related contributions by the Internet research and
           engineering community.

      (3)  The development, review, and approval of Internet
           Standards, according to a well-defined and documented set
           of "Procedures for Internet Standardization".  Internet
           Standards shall be published in the form of specifications
           as part of the RFC series.

      (4)  The provision of advice and guidance to the Board of Trustees
           and Officers of the Internet Society concerning technical,
           architectural, procedural, and (where appropriate) policy
           matters pertaining to the Internet and its enabling
           technologies.

      (5)  Representation of the interests of the Internet Society in
           liaison relationships with other organizations.

   The IAB may be charged with additional responsibilities within the
   Internet Society, or undertake additional specific activities from
   time to time, as the needs and requirements of the Internet Society
   demand.
IAB                                                             [Page 1]
RFC 1358
Charter of the IAB                August 1992
Section 2
.

   The IAB shall consist of a number of members not to exceed 15.
   Members of the IAB shall serve in that capacity as individuals, and
   not as representatives of any company, agency, or other organization.
   Individuals shall be nominated for membership by:

      (a) the IAB;

      (b) the President of the Internet Society;

      (c) the Board of Trustees of the Internet Society;  or

      (d) a duly executed petition of at least 1% of the current
          membership of the Internet Society, or, if the current
          membership of the Society exceeds 15,000, of at least 150
          members, delivered to and validated by the Secretary of
          the Society.

   The Internet Society Board of Trustees shall approve or disapprove
   such a nomination within 60 days.  Approval shall be by the
   affirmative vote of at least three-fifths of the members of the Board
   of Trustees then in office.

   Any member of the IAB may be replaced by the Board of Trustees, by
   the affirmative vote of at least four-fifths of the members of the
   Board of Trustees then in office, whenever in their judgement the
   best interests of the Society will be served thereby.  A member of
   the IAB shall also be replaced, upon the confirming vote of a
   majority of the members of the Board of Trustees then in office, if
   and when a duly executed petition of at least 5% of the voting
   membership of the Internet Society is delivered to and validated by
   the Secretary of the Society.  The vote of the Board of Trustees, and
   any action pursuant to that vote, shall be taken no later than at the
   next regularly scheduled meeting of the Board following the date on
   which the Secretary declares the receipt of a valid petition.

   The Board of Trustees shall review each IAB member's contribution to
   the IAB at three-year intervals, and shall at that time explicitly
   reaffirm or revoke the membership.  There is no limit to the number
   of times the Board of Trustees may reaffirm the membership of any
   individual IAB member.  However, it is expected that the decision to
   reaffirm or revoke will be reached with respect to the current
   composition of the IAB as a whole, and the extent to which the goals
   and requirements of the Internet Society are served by the IAB as
   then currently constituted.
IAB                                                             [Page 2]
RFC 1358
Charter of the IAB                August 1992
Whenever the Board of Trustees determines that a vacancy exists on
   the IAB, it shall circulate among the membership of the Internet
   Society, by electronic mail, a call for nominations, specifying a
   closing date for nominations to be received by the Secretary of the
   Society that is no less than 30 days after the date on which the call
   is circulated.  At its discretion, the Board may also circulate the
   call for nominations among the membership of the Society my means
   other than electronic mail, and may also advertise or circulate the
   call by such other means and among the members of such other groups
   as it sees fit and appropriate.
Section 3
.

   The IAB may create and empower task forces, committees, and working
   groups, as it sees fit, to carry out activities that fall within the
   scope of the IAB's responsibilities.  The initial task forces of the
   IAB are the Internet Engineering Task Force (IETF) and the Internet
   Research Task Force (IRTF).
Section 4
.

   The Internet Society shall provide support for secretariat functions
   that are required by the IAB or its task forces, committees, and
   working groups, subject to approval by the Board of Trustees.  In
   particular, the secretariat shall include support for the Internet
   standards-making activity of the IAB.  During the Internet Society's
   Initial Period of operations, support for secretariat functions shall
   depend on the availability of funding provided specifically for this
   purpose.
Section 5
.

   Members of the IAB and its task forces, committees, and working
   groups shall serve on a volunteer basis without compensation, except
   as provided in (a) and (b) below:

   (a)  The President of the Internet Society may approve the
        reimbursement by the Society of expenses incurred by a
        member of the IAB or one of its corollary organizations,
        if he or she determines that reimbursement of specific
        expenses is appropriate.

   (b)  Acting on the recommendation of the President of the Internet
        Society, the Board of Trustees may approve the payment of
        compensation to an individual whose service as a member of the
        IAB or of one of its corollary organizations is
IAB                                                             [Page 3]
RFC 1358
Charter of the IAB                August 1992
(1) considered by the Board to be essential to the welfare of
            the Society, and

        (2) is, in the Board's estimation, unobtainable in the absence
            of reasonable compensation.

        In determining the need for and amount of compensation, the
        Board shall apply the criteria and voting rules that it normally
        applies to matters concerning the allocation of Internet Society
        funds.
Section 6
.

   The members of the IAB shall appoint one of their number to serve as
   the chair of the IAB, with all of the duties and responsibilities
   normally associated with such a position.  The chair of the IAB may
   be removed at any time by the affirmative vote of two-thirds of the
   members of the IAB, or as a result of his or her departure from the
   IAB.
Section 7
.

   The chair of the IAB shall have the authority to organize the IAB as
   he or she sees fit.
Section 8
.

   The chair of the IAB, with the approval of at least two-thirds of the
   IAB membership, shall have the authority to appoint an Editor for the
   Request for Comments (RFC) publication series (the "RFC Editor"), who
   shall be responsible for the editorial management and publication of
   the RFC series.  If the RFC Editor is not a member of the IAB, he or
   she shall serve ex officio as a member of the IAB unless and until
   made a regular member of the IAB.  The RFC Editor may be removed at
   any time by the affirmative vote of two-thirds of the members of the
   IAB.
Section 9
.

   The chair of the IAB, with the approval of at least two-thirds of the
   IAB membership, shall have the authority to appoint the chair of the
   Internet Engineering Task Force (IETF), who shall be responsible for
   the management and organization of the IETF.  If the IETF chair is
   not a member of the IAB, he or she shall serve ex officio as a member
   of the IAB unless and until made a regular member of the IAB.  The
   IETF chair may be removed at any time by the affirmative vote of
   two-thirds of the members of the IAB.
IAB                                                             [Page 4]
RFC 1358
Charter of the IAB                August 1992
Section 10
.

   The chair of the IAB, with the approval of at least two-thirds of the
   IAB membership, shall have the authority to appoint the chair of the
   Internet Research Task Force (IRTF), who shall be responsible for the
   management and organization of the IRTF.  If the IRTF chair is not a
   member of the IAB, he or she shall serve ex officio as a member of
   the IAB unless and until made a regular member of the IAB.  The IRTF
   chair may be removed at any time by the affirmative vote of two-
   thirds of the members of the IAB.
Section 11
.

   The Internet Society News shall serve as the formal Publication of
   Record for the announcement of actions taken and decisions made by
   the IAB on matters related to the Internet Standards.  Other official
   actions and decisions of the IAB may be announced and recorded in the
   News.  All IAB announcements published in the News shall also be
   distributed by electronic mail to the Internet Society membership.

   The Internet Society shall, through its various publications and by
   any other means that may be suitable in each circumstance, provide
   timely information to its members concerning the actions and
   decisions of the IAB;  and shall actively solicit and promote the
   participation of its members in IAB-administered activities such as
   the development and review of Internet Standards.
Section 12
.

   The Internet Society shall regularly publish as an RFC a definitive
   record of the status of the Internet Standards process.  As it is
   used in this section, the term "regularly" shall mean "no less
   frequently than once every six months".

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   A. Lyman Chapin
   Bolt, Beranek & Newman
   Mail Stop 20/5b
   150 Cambridge Park Drive
   Cambridge, MA 02140

   Phone: (617) 873-3133
   EMail: lyman@BBN.COM

IAB                                                             [Page 5]
RFC
1358
: Charter of the Internet Architecture Board (IAB)
Informational
Obsoleted by
RFC
1601
Charter of the Internet Architecture Board (IAB)


The Digital Services Act | Shaping Europe’s digital future
Skip to main content
en
Select your language
Close
bg
български
es
español
cs
čeština
da
dansk
de
Deutsch
et
eesti
el
ελληνικά
en
English
fr
français
ga
Gaeilge
hr
hrvatski
it
italiano
lv
latviešu
lt
lietuvių
hu
magyar
mt
Malti
nl
Nederlands
pl
polski
pt
português
ro
română
sk
slovenčina
sl
slovenščina
fi
suomi
sv
svenska
Search
Search
Shaping Europe’s digital future
Menu
Close
Menu
Back
Previous items
Next items
Home
Policies
Activities
News
Library
Funding
Calendar
Consultations
AI Office
Home
...
Policies
Online platforms and e-commerce
The Digital Services Act
The Digital Services Act
Page Contents
Page Contents
What is the Digital Services Act?
What does the DSA do for citizens?
What does the DSA do for businesses?
Which providers are covered?
Which authorities ensure companies follow the Digital Services Act?
The Digital Services Act helps to make the online environment safe and trustworthy.
What is the Digital Services Act?
The Digital Services Act (DSA) introduces rules for online services used by European citizens in their everyday life. These services include marketplaces, social media networks, app stores, and online travel and accommodation platforms.
Find out more about your rights under DSA
The main goal of the DSA is to create a digital space that respects citizens and consumers’ fundamental rights. By establishing a clear set of rules across the EU, the DSA also enables smaller platforms, small and medium enterprises (SMEs) and start-ups to scale up in Europe, fostering innovation, growth and competitiveness.
The DSA is complemented by the Digital Markets Act (DMA), which includes rules for gatekeeper online platforms. Gatekeepers function as bottlenecks between businesses and consumers for digital services, affecting competition and the functioning of the EU internal market. Some of these services are also covered in the DSA, but for different reasons and with different types of provisions.
Find out more about how the
DMA benefits
you.
What does the DSA do for citizens?
The
DSA empowers citizens
by strengthening the protection of their fundamental rights online and giving them greater control and more choices when they navigate online platforms and search engines.
The DSA also requires platforms to minimise the risks of exposing citizens, including children and young people, to illegal and harmful content. With the DSA, your digital rights include:
Transparency in content removals
- If your content is removed or suspended, platforms must explain why this has been done.
Options to appeal to content moderation decisions
- If you disagree with a content moderation decision taken by a platform, you can appeal it through the platform itself or an
out-of-court dispute settlement body
, which is faster and cheaper than going to court.
Easy flagging of illegal content
- You can report illegal content, goods or services via an easy-to-use mechanism directly on the platform you are using. Platforms must respond to your reports and offer options to appeal their decisions
.
Enhanced protection for minors
- Platforms must take measures to safeguard minors on their services, such as reducing the risks of exposure to age-inappropriate content like gambling or pornography. The DSA also introduces a complete ban on showing targeted advertisements to children.
Feed options
- On
large platforms
with over 45 million monthly users in the EU, you can now opt for
non-personalised feeds. This way, you decide whether to see content based on the algorithm’s suggestions, sometimes pushing specific content which may be more appealing or even addictive, or other criteria, such as the chronological order.
Ad transparency
- Ads must be clearly labelled as such and include information like who is placing them and why you are seeing them, while very large online platforms are required to store ad information in a publicly accessible repository. Platforms can no longer show you ads based on your sensitive data, such as sexual orientation, religion, or race.
Ban on dark patterns
- Deceptive design tactics, such as aggressive pop-ups or confusing and misleading consent buttons, are now prohibited.
Verified sellers
- Marketplaces must verify and display the contact details of sellers, so you have clear information about whom you’re buying goods or services from.
What does the DSA do for businesses?
The DSA provides several benefits for your company:
One single set of rules across the EU
- All online services operating in the European Union are required to comply with the DSA. The DSA replaces 27 different regulations with one unified framework, giving you legal certainty and the ability to scale up across the EU.
A proportionate approach
- The DSA’s obligations are tailored to each online services’ role, size and impact in the online ecosystem. Micro and small companies have lighter requirements based on their size, to keep them accountable while helping them scale up, while bigger platforms have more responsibilities and therefore, obligations.
Simplified reporting of illegal content
- You can use a user-friendly mechanism to flag illegal content and goods that infringe your rights, including intellectual property rights. Your company may also become ‘trusted flaggers’, whose notices of illegal content or goods gain priority in platforms’ assessment.
Better protection against unfair content moderation decisions
- New appealing mechanisms through the platform or through
out-of-court dispute settlement bodies
allow you to protect your online presence in case you disagree with a content moderation decision by a platform.
More transparency on marketplaces
- New obligations for marketplaces, such as the requirement to list a seller’s contact information, enhance transparency and trustworthiness in ecommerce. For the same reason, the DSA requires marketplaces to make reasonable efforts to perform random checks on products sold on their service or adopt new technologies for product traceability.
Which providers are covered?
The DSA applies to all companies proportionally to their size. The DSA recognises that the
biggest online platforms
– those with over 45 million monthly users in the EU – play a significant role in our societies and democracies. They must therefore follow specific rules to ensure they do not pose unintentional risks to us, such as amplifying illegal content and shaping opinion at scale, and to minimise the possibility of malicious actors using them to inflict harm on Europe.
In particular, these large platforms must identify and analyse wide-spread risks. These risks include:
The spreading of illegal content, as defined in national or EU laws
Threats to fundamental rights, such as freedom of expression
Threats to media freedom and pluralism, public security and electoral processes
Gender-based violence, public health, protection of minors and physical and mental wellbeing
Once these risks are identified, these larger platforms must put measures in place to reduce them. Similarly, these platforms must meet other requirements to
enhance transparency and accountability
. A
full list of these platforms
is published on the Commission’s website.
Which authorities ensure companies follow the Digital Services Act?
The Commission enforces the DSA together with
Digital Services Coordinators
– national authorities who supervise the compliance of the platforms established in their territory. The Commission is primarily responsible for the monitoring and enforcement of the additional obligations applying to the biggest platforms and search engines, such as the measures to mitigate systemic risks. Digital Services Coordinators
supervise and enforce compliance with the DSA in their Member States
.
If you want to file a complaint about a violation of the DSA, you can contact the
Digital Services Coordinator of your Member State
.
Subscribe to the latest news on this topic and more
Explore more
What are your rights under the DSA?
DSA Questions & Answers
DSA's enforcement framework
DSA's cooperation framework
User rights under the DSA
DSA's impact on digital platforms
Text of the DSA
List of designated very large online platforms and search engines
Follow us
Digital EU on LinkedIn
Digital EU on Facebook
Digital EU on Youtube
Digital EU on Instagram
DigitalEU on X
Latest News
Press release
24 July 2026
Commission preliminary finds TikTok in breach of Digital Services Act for failing to ensure safe accounts for minors
Today, the European Commission sent TikTok preliminary findings indicating that TikTok accounts of minors do not meet the safety standards required under the Digital Services Act (DSA).
Press release
20 July 2026
Commission fines AliExpress €550 million for breaching the Digital Services Act
The European Commission fined AliExpress €550 million for breaching its obligations under the Digital Services Act (DSA) to diligently assess and mitigate risks relating to the sale of illegal, unsafe or counterfeit products on its e-commerce platform.
Press release
16 July 2026
Commission accepts X’s action plan to comply with Digital Services Act
The European Commission has accepted X’s action plan to comply with transparency obligations and researchers’ access to data, under the Digital Services Act.
Digibyte
15 July 2026
Commission accepts X's corrective measures to terminate breaches of the DSA
The European Commission has accepted X’s action plan to comply with transparency obligations and researchers’ access to data, under the Digital Services Act.
Browse DSA - Digital Services Act
Related Content
Big Picture
Online platforms and e-commerce
The EU wants to ensure businesses and citizens can use online platforms and e-commerce services no matter where they are in the EU.
Dig deeper
The impact of the Digital Services Act on digital platforms
With the Digital Services Act (DSA) platforms have already changed their systems and interfaces to...
DSA: Making the online world safer
Find out how the DSA can make the online world safer and protect your fundamental rights.
The enforcement framework under the Digital Services Act
The enforcement of the Digital Services Act (DSA) includes a full set of investigative and...
The cooperation framework under the Digital Services Act
The Digital Services Act (DSA) provides a framework for cooperation between the Commission, EU and...
How the Digital Services Act enhances transparency online
The Digital Services Act (DSA) details a range of actions to promote transparency and accountability...
DSA whistleblower tool
The DSA (Digital Services Act) whistleblower tool allows employees and other insiders to report...
Last update
18 May 2026
Print as PDF
Shaping Europe’s digital future
This site is managed by:
Directorate-General for Communications Networks, Content and Technology
Digital EU on Mastadon
Digital EU on LinkedIn
Digital EU on Facebook
Digital EU on Youtube
Digital EU on Instagram
Digital EU on X
About us
Privacy statement
Copyright notice
About Directorate-General CONNECT
Language Policy
Accessibility statement
Follow the European Commission
Mastodon
LinkedIn
Bluesky
Facebook
Youtube
Other
Contact us
Report an IT vulnerability
Languages on our websites
Cookies
Privacy policy
Legal notice
Accessibility


RIPE Policy Development — RIPE Network Coordination Centre
Skip to main content
IPs & ASNs
IPs & ASNs
We distribute Internet number resources to our members and provide tools to help them manage their allocations and assignments.
Visit page
IPv4
Request /24 Allocation
IPv4 Run-out
How Does The IPv4 Waiting List Work?
IPv4 Transfer Request
IPv4 Waiting List
IPv6
Request IPv6
IPv6 Info Centre
AS Numbers
Reassigning Referenced AS Numbers
RIPE Database
Whois Search
Webupdates
Database Support
LIR Portal
DNS
Reverse DNS
DNSSEC
Resource Transfers and Mergers
Inter-RIR Transfers
Mergers and Acquisitions
Legacy Internet Resources
Documentation
Documentation for Resource Management
Resource Public Key Infrastructure (RPKI)
Policy Implementation
Assisted Registry Check
Close
Analyse
Analyse
We collect a wide range of Internet data and provide statistics and tools you can use for your own operations and analyses.
Visit page
Statistics
Internet Measurements
RIPE Atlas
RIPEstat
RIS
RIPE IPMap
Internet Traffic Maps
Analyses and Use Cases
IXP Country Jedi (Alpha)
DNS
K-root
AuthDNS
Reverse DNS Zonecheck
DNS Monitoring Service (DNSMON)
Raw Datasets
RIPE Atlas Raw Data Format
RIPE Atlas Raw Data
RIS Raw Data
Terms and Conditions
Archived Projects
RIS Tools and Web Interfaces
TTM
RRCC
DISI
IRRToolset
Re-implementation Project
DBConstat
Sponsorship
Close
Community
Community
More information about RIPE
Visit page
Working Groups
Working Group Chairs
Active Working Groups
Task Forces
Policy Development
Policy Implementation Status
Current Policy Proposals
Internet Governance
Internet Technical Community
Multi-stakeholder Engagement
Internet Governance News
RIPE Labs
NRO NC
About the NRO NC
NRO NC Nominations - October 2025
ICP-2 Review
Initiatives
Academic Cooperation (RACI)
RIPE Fellowship
Diversity
Community Projects Fund
Rob Blokzijl Foundation
Community Sponsorship
RIPE Governance
The RIPE Chair Team
RIPE Code of Conduct
RIPE Community Plenary
The History of RIPE
RIPE Document Store
Participate
How to Participate
RIPE Mailing Lists
Close
Membership
Membership
Get information about your membership, the benefits you get and how you can participate and shape RIPE NCC's activities.
Visit page
RIPE NCC Membership
Become a Member
LIR Basics for Members
RIPE NCC Access
RIPE NCC Surveys
General Meetings
General Meeting October 2026
Meetings
Billing, Payment and Fees
Charging Schemes
Billing Procedure 2026
Billing Procedure 2025
Tax Information
Financial Information
RIPE NCC Organisational Documents
Activity Plan and Budget
Annual Reports
Financial Reports
Charging Schemes
Quarterly Sanctions Transparency Reports
RIPE NCC Strategy
Join a Discussion
Membership Mailing Lists
RIPE Mailing Lists
Consultations
RIPE NCC Forum
Close
Events
Events
The RIPE community carries out much of its work through mailing lists, but face-to-face meetings are equally important.
Visit page
RIPE Meetings
Presenting at a RIPE Meeting
Programme Committee
Upcoming RIPE Meetings
Previous RIPE Meetings
Regional Meetings
CAPIF
MENOG
SEE
RIPE NCC Days
Next Regional Meetings
Roundtable Meetings
Previous Meetings
General Meetings
Open House
Previous Events
Internet Measurement Days
Sofia
Bucharest
Hackathons
Events Calendar
Event Sponsorship
Close
Training
Training
Follow our courses, build skills, and earn certifications. Browse topics and skill levels for the learning path that best matches your goals and learning style.
Visit page
In-Person Training Courses
Upcoming Training Courses
Host a Training Course
Training Material
Webinars
Webinar Recordings
RIPE NCC Academy
Certified Professionals
Schedule an Exam
BGP Security Associate
IPv6 Fundamentals - Analyst
IPv6 Security Expert
Local Internet Registry (LIR) Fundamentals
RIPE Database Associate
Practical Information
Exam Vouchers
Videos
Summer School 2026
Close
Docs
Docs
Find the documents that you need from the RIPE Document Store, the RIPE NCC's technical documentation and IPv6 resources.
Visit page
RIPE Document Store
RIPE Documents by Number
RIPE Documents by Category
RIPE Policies
Documentation
Developer Documentation
Quarterly Plans
RIPE Atlas Documentation
RIPE Database Documentation
RIS Documentation
RIPE IPmap Documentation
RIPEstat Documentation
Disclosures and Reports
IPv6 Information Centre
About IPv6
Deploy IPv6 Now
Statistics and Tools
Training and Materials
Documents
Community
Close
About
About
We're a not-for-profit membership association, a Regional Internet Registry and the secretariat for the RIPE community supporting the Internet.
Visit page
What We Do
Regional Internet Registry
RIPE NCC Service Region
Coordination Function
Statistics
Transition to IPv6
List of RIPE NCC Services
User Research
Staff
RIPE NCC Staff
Careers at the RIPE NCC
Executive Board
Functions and Expectations
Minutes from Executive Board Meetings
Financial Information
Current Charging Scheme
Current Billing Procedure
Press Centre
RIPE NCC in the News
Publications and Presentations
Press Releases
Press Quality Photos
Legal
Arbitration
Corporate Governance
Internet Number Resources
Other RIPE NCC Services
Information for LEA
News
RSS News Feeds
RIPE NCC Member Updates
Support
Contact Us
Spam, Hacking and Phishing
Service and Security Announcements
RIPE NCC Trust Portal
RIPE NCC Middle East
Close
Languages
Find information about the RIPE NCC translated into eight languages. Use the menu to read text in Arabic, Spanish, Farsi, French, Italian, Turkish, Ukrainian and Russian.
Visit page
English
How to Become a Member
Billing, Fees and Payments
How to Get IP Addresses
How to Transfer IP Addresses and ASNs
How to get involved at the RIPE NCC
How the RIPE NCC is Run
How to Find Abuse Contact Information
Training and Certification
Türkçe
RIPE NCC’ye Nasıl Üye Olabilirsiniz?
Faturalandırma, Ücretler ve Ödemeler
IP Adresleri Nasıl Alınır
IP Adreslerinin ve ASN'lerin Aktarılması
RIPE NCC’nin faaliyetlerinde nasıl yer alınır
RIPE NCC Nasıl Çalışır
Kötüye Kullanımdan Sorumlu İrtibat Kişisinin Bilgileri Nasıl Bulunur?
Eğitim ve Sertifikalar
Español
Cómo hacerse miembro
Facturación, Tarifas y Pagos
Cómo obtener direcciones IP
Cómo transferir direcciones IP y ASN
Cómo involucrarse en RIPE NCC
Cómo funciona el RIPE NCC
Cómo encontrar información de contacto de abuso
Formación y certificación
Italiano
Come associarsi
Costi, fatturazione e pagamenti
Come ottenere indirizzi IP
Come trasferire indirizzi IP e ASN
Come partecipare al RIPE NCC
Come viene gestito il RIPE NCC
Come trovare informazioni di contatto sugli abusi
Formazione e certificazione
Pусский
Как стать членом RIPE NCC
Оформление счетов, взносы и платежи
Как получить IP-адреса
Как передавать IP-адреса и ASN
Как принять участие в работе RIPE NCC
Кто руководит RIPE NCC
Как найти контактную информацию для обращений касательно злоупотреблений
Обучение и сертификация
عربي
كيف تصبح عضوًا
رسوم العضوية
كيفية الحصول على عناوين IP
كيفية نقل عناوين IP وأرقام ASN
كيف تشارك في RIPE NCC
كيف تُدار RIPE NCC
كيف تصل إلى معلومات الاتصال الخاصة بإساءة الاستخدام
التدريب والشهادات
فارسی
نحوۀ عضویت
صدور صورتحساب، هزینه‌ها و پرداخت‌ها
چگونه میتوان آدرس های IPرا گرفت
نحوۀ انتقال آدرس های IP و شماره های سیستم خودمختار
نحوۀ همکاری با مرکز هماهنگی شبکه RIPE NCC
RIPE NCC نحوۀ ادارۀ
نحوۀ یافتن اطلاعات تماس سوءاستفاده‌گر
آموزش و اعطای گواهی
Українська
Як стати членом RIPE NCC
Виставлення рахунків, збори та платежі
Як отримати IP-адреси
Як передавати IP-адреси та ASN
Навчання та сертифікація
Як функціонує RIPE NCC
Як знайти контактну інформацію для повідомлення про зловживання
Français
Comment devenir membre ?
Facturation, frais et paiements
Comment obtenir des adresses IP
Comment transférer des adresses IP et des numéros de système autonome (ASN)
Comment s'impliquer au sein du RIPE NCC
Comment fonctionne le RIPE NCC
Comment trouver les Informations de Contact d'Abus
Formation et certification
Close
Search
Search
Your IP Address is:
193.171.242.40
Tip: try using "quotes around your search phrase"
Apps
RIPE.NET
LIR Portal
RIPE Database
RIPE Labs
RIPEstat
RIPE Atlas
RIPE NCC Academy
RPKI
DNSMON
Log in
Menu
Close
Apps
RIPE.NET
LIR Portal
RIPE Database
RIPE Labs
RIPEstat
RIPE Atlas
RIPE NCC Academy
RPKI
DNSMON
Log in
Working Groups
Task Forces
Policy Development
Internet Governance
RIPE Labs
NRO NC
Initiatives
RIPE Governance
RIPE Document Store
Participate
PDP Glossary
Policy Proposal Template
Policy Implementation Status
RIPE Document: Policy Development Process
RIR Comparative Policy Overview (nro.net)
RIPE Policies
Current Policy Proposals
Archived Policy Proposals
Home
/
Community
/
Policy Development
RIPE Policy Development
The RIPE community develops and sets policies through a long established, open, bottom-up process of discussion and consensus-based decision making.
Where does it happen?
Policy development happens at
RIPE Meetings
(where RIPE Working Groups meet) and the
RIPE Working Group mailing lists
.
Who can contribute?
All RIPE Meetings and RIPE Working Group mailing lists are open to everyone.
The policy-making process involves all relevant parties. This means that discussions cannot be rushed, and anyone that could be affected by a decision should have a chance to become aware of discussions, review proposals and provide their input.
To promote and support the inclusive and open process:
Everyone is welcome and encouraged to take part in the workings of RIPE by attending RIPE Meetings and participating on RIPE Working Group mailing lists;
Mailing lists are publicly archived;
The minutes of working group sessions at RIPE Meetings are publicly archived;
All policies are formally documented and publicly available.
How can I contribute?
Study the
list of current proposals
and if you wish to take part in discussions, post messages to the appropriate RIPE Working Group mailing list noted in each proposal.
I've got a better idea
If you want to propose a policy for the RIPE community, you are free to do so. You
don't
have to be a member of the RIPE NCC
or
a regular at any of our meetings.
Read the RIPE Document
that outlines how the Policy Development Process (PDP) works. If you still have questions,
get in touch
.
Global Policy
RIPE Policies for Internet resources may differ from those used in other regions.
The
RIR Comparative Policy Overview
maintained by the Number Resource Organisation (NRO) gives you an overview of the policies for each Regional Internet Registry (RIR).
Official regional policy documents can be found at the respective websites of the RIRs:
AFRINIC
APNIC
ARIN
LACNIC
RIPE NCC
On this page
Where does it happen?
Who can contribute?
How can I contribute?
I've got a better idea
Working Groups
Task Forces
RIPE Governance
Initiatives
RIPE 93
How to Participate
IPs & ASNs
IPv4
IPv6
AS Numbers
RIPE Database
LIR Portal
DNS
Resource Transfers and Mergers
Legacy Internet Resources
Documentation for Resource Management
Analyse
Statistics
Internet Measurements
DNS
Raw Datasets
Archived Projects
Sponsorship
Community
Working Groups
Task Forces
Policy Development
Internet Governance
RIPE Labs
NRO NC
Initiatives
RIPE Governance
RIPE Document Store
Participate
Membership
RIPE NCC Membership
General Meetings
Billing, Payment and Fees
RIPE NCC Organisational Documents
Join a Discussion
RIPE NCC Forum
Events
RIPE Meetings
Regional Meetings
Roundtable Meetings
General Meetings
Open House
Internet Measurement Days
Hackathons
Events Calendar
Event Sponsorship
Training
In-Person Training Courses
Webinars
RIPE NCC Academy
Certified Professionals
Videos
Summer School 2026
Docs
RIPE Document Store
Documentation
IPv6 Information Centre
About
What We Do
Staff
Executive Board
Financial Information
Press Centre
Legal
News
Support
RIPE NCC Trust Portal
RIPE NCC Middle East
Languages
English
Türkçe
Español
Italiano
Pусский
عربي
فارسی
Українська
Français
© 1992–2026 RIPE NCC
Your IP Address is:
193.171.242.40
Home
Sitemap
Contact Us
Careers
Service Announcements
Privacy Statement
Legal
Cookies
Copyright Statement
Terms of Service
RSS Feeds


Policy Development – APNIC

Policy Development – APNIC
Skip to content
MyAPNIC
Academy
Blog
Orbit
REx
DASH
Home
Whois and website search
Search
Advanced Whois
Make
a
payment
Close Search
Search APNIC.net OR enter Whois database
query
Get IP
Get IP
Make a payment
Membership
FAQs
Manage IP
MyAPNIC
Using Whois
IPv4 exhaustion
Go IPv6
Routing Registry
Make a payment
Training
About
Events
APNIC Academy
Community Trainers
Courses
Events
Conferences
Calendar
Sponsorship
Code of Conduct
Insights
APNIC Labs
DASH to secure your networks
REx
Raw Data
Community
Orbit
Community demographics
Policy Development
Fellowship
Addressing policies
Internet community
Code of Conduct
Technical Assistance
Root servers
Security at APNIC
ISIF Asia
APNIC Foundation
NRO Number Council (NC)
Blog
Help Centre
About
APNIC Region
APNIC Membership
Executive Council
Service updates
Team
Annual Reports
Transparency
APNIC Survey
Corporate Documents
Publications Archive
Careers
Glossary
Contact
Advanced Whois
Make a payment
Get IP
Get IP
Make a payment
Membership
FAQs
Manage IP
MyAPNIC
Using Whois
IPv4 exhaustion
Go IPv6
Routing Registry
Make a payment
Training
About
Events
APNIC Academy
Community Trainers
Courses
Events
Conferences
Calendar
Sponsorship
Code of Conduct
Insights
APNIC Labs
DASH to secure your networks
REx
Raw Data
Community
Orbit
Community demographics
Policy Development
Fellowship
Addressing policies
Internet community
Code of Conduct
Technical Assistance
Root servers
Security at APNIC
ISIF Asia
APNIC Foundation
NRO Number Council (NC)
Blog
Help Centre
About
APNIC Region
APNIC Membership
Executive Council
Service updates
Team
Annual Reports
Transparency
APNIC Survey
Corporate Documents
Publications Archive
Careers
Glossary
Contact
Policy Development
APNIC Policies are the rules that control the way IP addresses and Autonomous System Numbers are distributed and registered in the Asia Pacific. The procedures for discussing and deciding proposed changes to APNIC policies are called the Policy Development Process (usually referred to as the PDP).
Policies are decided by the APNIC membership and the broader Internet community.
APNIC staff support the PDP by providing administrative services to the Policy SIG, drafting policy wording, and managing the implementation of policy changes.
Most of the policy development activity takes place on the Policy SIG mailing list. Proposed changes to policy are discussed over email. Two times each year the SIG holds a face-to-face Open Policy Meeting to decide the outcomes by trying to reach consensus on the policy changes proposed.
The policy development process is explained
here
. You can also refer to the official APNIC
Policy Development Process
policy.
Policy process values
Open
Anyone can propose policies
Everyone can discuss policy proposals
Transparent
Archives of all policy discussions and decisions are available publicly
Bottom-up
The community drives policy development
APNIC keeps a public record of all policy discussions and decisions. This transparency means you can always understand why policies were decided. You will find the results of all policy discussions in
Policy Proposals
.
The Policy Cycle
Related links
APNIC Policy Development Process
Submit a policy proposal
See also
Template for proposal presentations
Community demographics
Community Consultations
Send us feedback
Resource Policies
Participate
Current policies
Policy SIG
Policy Development
Policy Development Process
Guidelines for Proposal Authors
The APNIC Consensus Process
Policy proposals
APNIC drafts for public comment
Editorial comment period for APNIC 54 and APNIC 55 Policies
Policies for IPv4 address space management in the Asia Pacific region
Experimental allocations policy
IPv6 address allocation and assignment policy
Criteria for the recognition of NIRs in the APNIC region
APNIC Internet Number Resource Policies
Operational policies for National Internet Registries in the APNIC region
Policy environment for Internet number resource distribution in the Asia Pacific
APNIC transfer, merger, acquisition, and takeover policy
Fellowship
APNIC in the Internet ecosystem
Participate
Community Technical Support
Security at APNIC
IPv6@APNIC
APNIC Foundation
APNIC IPv4 post-exhaustion
APNIC Home
Connect with us
Facebook
Twitter
YouTube
Flickr
Weibo
Slideshare
LinkedIn
RSS
©
2026
APNIC
ABN 42 081 528 010
Privacy
Contact
Help Centre
NRO News
Service Status
Careers
Feedback


RFC 9364: DNS Security Extensions (DNSSEC) | RFC Editor
Skip to content
Primary navigation
The RFC Series
For Authors
About Us
Home
RFC 9364
Info
RFC
9364
:
BCP
237
:
DNS Security Extensions (DNSSEC)
P. Hoffman
Best Current Practice
Abstract
This document describes the DNS Security Extensions (commonly called "DNSSEC") that are
specified in RFCs 4033, 4034, and 4035, as well as a handful of others. One purpose is to introduce
all of the RFCs in one place so that the reader can understand the many aspects of DNSSEC.
This document does not update any of those RFCs.
A second purpose is to state that using DNSSEC for origin authentication of DNS data is the best current practice.
A third purpose is to provide a single reference for other documents that want to refer to DNSSEC.
¶
Status of This Memo
This memo documents an Internet Best Current Practice.
¶
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further information
on BCPs is available in Section 2 of RFC 7841.
¶
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
https://
www
.rfc
-editor
.org
/info
/rfc9364
.
¶
Copyright Notice
Copyright (c) 2023 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
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
¶
1.
Introduction
The core specification for what we know as DNSSEC (the combination of
[
RFC4033
]
,
[
RFC4034
]
, and
[
RFC4035
]
) describes a set of protocols that provide origin
authentication of DNS data.
[
RFC6840
]
updates and extends those core RFCs
but does not fundamentally change the way that DNSSEC works.
¶
This document lists RFCs that should be considered by someone
creating an implementation of, or someone deploying, DNSSEC as it is currently standardized.
Although an effort was made to be thorough, the reader should not assume this list is comprehensive.
It uses terminology from those documents without defining that terminology.
It also points to the relevant IANA registry groups that relate to DNSSEC.
It does not, however, point to standards that rely on zones needing to be signed by DNSSEC,
such as DNS-Based Authentication of Named Entities (DANE)
[
RFC6698
]
.
¶
1.1.
DNSSEC as a Best Current Practice
Using the DNSSEC set of protocols is the best current practice for adding
origin authentication of DNS data. To date, no Standards Track RFCs offer any other
method for such origin authentication of data in the DNS.
¶
More than 15 years after the DNSSEC specification was published,
it is still not widely deployed. Recent estimates are that fewer than 10% of the domain names
used for websites are signed, and only around a third of queries to recursive resolvers
are validated. However, this low level of deployment does not affect whether using DNSSEC
is a best current practice; it just indicates that the value of deploying DNSSEC is often
considered lower than the cost.
Nonetheless, the significant deployment of DNSSEC beneath some top-level domains (TLDs)
and the near-universal deployment of DNSSEC for the TLDs in the DNS root zone
demonstrate that DNSSEC is applicable for implementation by both ordinary and highly sophisticated domain owners.
¶
1.2.
Implementing DNSSEC
Developers of validating resolvers and authoritative servers,
as well as operators of validating resolvers and authoritative servers,
need to know the parts of the DNSSEC protocol that would affect them.
They should read the DNSSEC core documents and probably at least be familiar
with the extensions.
Developers will probably need to be very familiar with the algorithm documents as well.
¶
As a side note, some of the DNSSEC-related RFCs have significant errata, so reading the
RFCs should also include looking for the related errata.
¶
2.
DNSSEC Core Documents
What we refer to as "DNSSEC" is the third iteration of the DNSSEC specification;
[
RFC2065
]
was the first, and
[
RFC2535
]
was the second.
Earlier iterations have not been deployed on a significant scale.
Throughout this document, "DNSSEC" means the protocol initially defined in
[
RFC4033
]
,
[
RFC4034
]
, and
[
RFC4035
]
.
¶
The three initial core documents generally cover different topics:
¶
[
RFC4033
]
is an overview of DNSSEC, including how it might change the resolution of DNS queries.
¶
[
RFC4034
]
specifies the DNS resource records used in DNSSEC.
It obsoletes many RFCs about earlier versions of DNSSEC.
¶
[
RFC4035
]
covers the modifications to the DNS protocol incurred by DNSSEC.
These include signing zones, serving signed zones, resolving in light of
DNSSEC, and authenticating DNSSEC-signed data.
¶
At the time this set of core documents was published, someone could create a DNSSEC
implementation of signing software, of a DNSSEC-aware authoritative server, and/or of
a DNSSEC-aware recursive resolver from the three core documents, plus a few older
RFCs specifying the cryptography used. Those two older documents are the following:
¶
[
RFC2536
]
defines how to use the DSA signature algorithm (although it refers to other
documents for the details).
DSA was thinly implemented and can safely be ignored by DNSSEC implementations
.
¶
[
RFC3110
]
defines how to use the RSA signature algorithm (although refers to other
documents for the details).
RSA is still among the most popular signing algorithms for DNSSEC.
¶
It is important to note that later RFCs update the core documents. As just one example,
[
RFC9077
]
changes how TTL values are calculated in DNSSEC processing.
¶
2.1.
Addition to the DNSSEC Core
As with any major protocol, developers and operators discovered issues with the original
core documents over the years.
[
RFC6840
]
is an omnibus update to the original core documents and thus itself has
become a core document.
In addition to covering new requirements from new DNSSEC RFCs, it describes many important
security and interoperabilit
y issues that arose during the deployment of the initial
specifications, particularly after the DNS root was signed in 2010.
It also lists some errors in the examples of the core specifications.
¶
[
RFC6840
]
brings a few additions into the core of DNSSEC.
It makes NSEC3
[
RFC5155
]
as much a part of DNSSEC as NSEC is.
It also makes the SHA-256 and SHA-512 hash functions defined in
[
RFC4509
]
and
[
RFC5702
]
part of the core.
¶
3.
Additional Cryptographic Algorithms and DNSSEC
Current cryptographic algorithms typically weaken over time as computing power improves and new cryptoanalysis emerges.
Two new signing algorithms have been adopted by the DNSSEC community: Elliptic Curve Digital Signature Algorithm (ECDSA)
[
RFC6605
]
and Edwards-curve Digital Signature Algorithm (EdDSA)
[
RFC8080
]
.
ECDSA and EdDSA have become very popular signing algorithms in recent years.
The GOST signing algorithm
[
GOST-SIGN
]
was also adopted but has seen very limited use, likely
because it is a national algorithm specific to a very small number of countries.
¶
Implementation developers who want to know which algorithms to implement in DNSSEC software
should refer to
[
RFC8624
]
.
Note that
this specification is only about what algorithms should and should
not be included in implementations
, i.e., it is not advice about which
algorithms zone operators should or should not use for signing, nor
which algorithms recursive resolver operators should or should not use
for validation.
¶
4.
Extensions to DNSSEC
The DNSSEC community has extended the DNSSEC core and the cryptographic algorithms, both
in terms of describing good operational practices and in new protocols. Some of the
RFCs that describe these extensions include the following:
¶
[
RFC5011
]
describes a method to help resolvers update their DNSSEC trust anchors in an
automated fashion. This method was used in 2018 to update the DNS root trust anchor.
¶
[
RFC6781
]
is a compendium of operational practices that may not be obvious from reading
just the core specifications.
¶
[
RFC7344
]
describes using the CDS and CDNSKEY resource records to help automate the maintenance
of DS records in the parents of signed zones.
¶
[
RFC8078
]
extends
[
RFC7344
]
by showing how to do initial setup of trusted relationships
between signed parent and child zones.
¶
[
RFC8198
]
describes how a validating resolver can emit fewer queries in signed zones that
use NSEC and NSEC3 for negative caching.
¶
[
RFC9077
]
updates
[
RFC8198
]
with respect to the TTL fields in signed records.
¶
5.
Additional Documents of Interest
The documents listed above constitute the core of DNSSEC, the additional cryptographic algorithms,
and the major extensions to DNSSEC.
This section lists some additional documents that someone interested in implementing or operating
DNSSEC might find of value:
¶
[
RFC4470
]
"describes how to construct DNSSEC NSEC resource records that cover a smaller range of
names than called for by
[
RFC4034
]
. By generating and signing these records on demand, authoritative name
servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a
signed zone".
¶
[
RFC6975
]
"specifies a way for validating end-system resolvers to signal to a server which digital signature
and hash algorithms they support".
¶
[
RFC7129
]
"provides additional background commentary and some context for the NSEC and NSEC3
mechanisms used by DNSSEC to provide authenticated denial
-of
-existence responses".
This background is particularly important for understanding NSEC and NSEC3 usage.
¶
[
RFC7583
]
"describes the issues surrounding the timing of events in the rolling of a key in a DNSSEC-secured zone".
¶
[
RFC7646
]
"defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling
DNSSEC validation at specified domains".
¶
[
RFC7958
]
"describes the format and publication mechanisms IANA has used to distribute the DNSSEC trust anchors".
¶
[
RFC8027
]
"describes problems that a Validating DNS resolver, stub-resolver, or application might run into within
a non-compliant infrastructure"
.
¶
[
RFC8145
]
"specifies two different ways for validating resolvers to signal to a server which keys are
referenced in their chain of trust".
¶
[
RFC8499
]
contains lists of terminology used when talking about DNS; Sections
10
and
11
cover DNSSEC.
¶
[
RFC8509
]
"specifies a mechanism that will allow an end user and third parties to determine the trusted key
state for the root key of the resolvers that handle that user's DNS queries".
¶
[
RFC8901
]
"presents deployment models that accommodate this scenario [when each DNS
provider independently signs zone data with their own keys] and describes these key-management requirements".
¶
[
RFC9276
]
"provides guidance on setting NSEC3 parameters based on recent operational
deployment experience".
¶
There will certainly be other RFCs related to DNSSEC that are published after this one.
¶
6.
IANA Considerations
IANA already has three registry groups that relate to DNSSEC:
¶
DNSSEC algorithm numbers
¶
DNSSEC NSEC3 parameters
¶
DNSSEC DS RRtype digest algorithms
¶
The rules for the DNSSEC algorithm registry were set in the core RFCs and
updated by
[
RFC6014
]
,
[
RFC6725
]
, and
[
RFC9157
]
.
¶
This document does not update or create any registry groups or registries.
¶
7.
Security Considerations
All of the security considerations from all of the RFCs referenced in this document
apply here.
¶
8.
References
8.1.
Normative References
[RFC3110]
Eastlake 3rd, D.
,
"RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)"
,
RFC 3110
,
DOI 10
.17487
/RFC3110
,
May 2001
,
<
https://
www
.rfc
-editor
.org
/info
/rfc3110
>
.
[RFC4033]
Arends, R.
,
Austein, R.
,
Larson, M.
,
Massey, D.
, and
S. Rose
,
"DNS Security Introduction and Requirements"
,
RFC 4033
,
DOI 10
.17487
/RFC4033
,
March 2005
,
<
https://
www
.rfc
-editor
.org
/info
/rfc4033
>
.
[RFC4034]
Arends, R.
,
Austein, R.
,
Larson, M.
,
Massey, D.
, and
S. Rose
,
"Resource Records for the DNS Security Extensions"
,
RFC 4034
,
DOI 10
.17487
/RFC4034
,
March 2005
,
<
https://
www
.rfc
-editor
.org
/info
/rfc4034
>
.
[RFC4035]
Arends, R.
,
Austein, R.
,
Larson, M.
,
Massey, D.
, and
S. Rose
,
"Protocol Modifications for the DNS Security Extensions"
,
RFC 4035
,
DOI 10
.17487
/RFC4035
,
March 2005
,
<
https://
www
.rfc
-editor
.org
/info
/rfc4035
>
.
[RFC4509]
Hardaker, W.
,
"Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)"
,
RFC 4509
,
DOI 10
.17487
/RFC4509
,
May 2006
,
<
https://
www
.rfc
-editor
.org
/info
/rfc4509
>
.
[RFC5155]
Laurie, B.
,
Sisson, G.
,
Arends, R.
, and
D. Blacka
,
"DNS Security (DNSSEC) Hashed Authenticated Denial of Existence"
,
RFC 5155
,
DOI 10
.17487
/RFC5155
,
March 2008
,
<
https://
www
.rfc
-editor
.org
/info
/rfc5155
>
.
[RFC5702]
Jansen, J.
,
"Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC"
,
RFC 5702
,
DOI 10
.17487
/RFC5702
,
October 2009
,
<
https://
www
.rfc
-editor
.org
/info
/rfc5702
>
.
[RFC6840]
Weiler, S., Ed.
and
D. Blacka, Ed.
,
"Clarifications and Implementation Notes for DNS Security (DNSSEC)"
,
RFC 6840
,
DOI 10
.17487
/RFC6840
,
February 2013
,
<
https://
www
.rfc
-editor
.org
/info
/rfc6840
>
.
8.2.
Informative References
[GOST-SIGN]
Belyavsky, D.
,
Dolmatov, V., Ed.
, and
B. Makarenko, Ed.
,
"Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC"
,
Work in Progress
,
Internet-Draft, draft
-ietf
-dnsop
-rfc5933
-bis
-13
,
30 November 2022
,
<
https://
datatracker
.ietf
.org
/doc
/html
/draft
-ietf
-dnsop
-rfc5933
-bis
-13
>
.
[RFC2065]
Eastlake 3rd, D.
and
C. Kaufman
,
"Domain Name System Security Extensions"
,
RFC 2065
,
DOI 10
.17487
/RFC2065
,
January 1997
,
<
https://
www
.rfc
-editor
.org
/info
/rfc2065
>
.
[RFC2535]
Eastlake 3rd, D.
,
"Domain Name System Security Extensions"
,
RFC 2535
,
DOI 10
.17487
/RFC2535
,
March 1999
,
<
https://
www
.rfc
-editor
.org
/info
/rfc2535
>
.
[RFC2536]
Eastlake 3rd, D.
,
"DSA KEYs and SIGs in the Domain Name System (DNS)"
,
RFC 2536
,
DOI 10
.17487
/RFC2536
,
March 1999
,
<
https://
www
.rfc
-editor
.org
/info
/rfc2536
>
.
[RFC4470]
Weiler, S.
and
J. Ihren
,
"Minimally Covering NSEC Records and DNSSEC On-line Signing"
,
RFC 4470
,
DOI 10
.17487
/RFC4470
,
April 2006
,
<
https://
www
.rfc
-editor
.org
/info
/rfc4470
>
.
[RFC5011]
StJohns, M.
,
"Automated Updates of DNS Security (DNSSEC) Trust Anchors"
,
STD 74
,
RFC 5011
,
DOI 10
.17487
/RFC5011
,
September 2007
,
<
https://
www
.rfc
-editor
.org
/info
/rfc5011
>
.
[RFC6014]
Hoffman, P.
,
"Cryptographic Algorithm Identifier Allocation for DNSSEC"
,
RFC 6014
,
DOI 10
.17487
/RFC6014
,
November 2010
,
<
https://
www
.rfc
-editor
.org
/info
/rfc6014
>
.
[RFC6605]
Hoffman, P.
and
W.C.A. Wijngaards
,
"Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC"
,
RFC 6605
,
DOI 10
.17487
/RFC6605
,
April 2012
,
<
https://
www
.rfc
-editor
.org
/info
/rfc6605
>
.
[RFC6698]
Hoffman, P.
and
J. Schlyter
,
"The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA"
,
RFC 6698
,
DOI 10
.17487
/RFC6698
,
August 2012
,
<
https://
www
.rfc
-editor
.org
/info
/rfc6698
>
.
[RFC6725]
Rose, S.
,
"DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates"
,
RFC 6725
,
DOI 10
.17487
/RFC6725
,
August 2012
,
<
https://
www
.rfc
-editor
.org
/info
/rfc6725
>
.
[RFC6781]
Kolkman, O.
,
Mekking, W.
, and
R. Gieben
,
"DNSSEC Operational Practices, Version 2"
,
RFC 6781
,
DOI 10
.17487
/RFC6781
,
December 2012
,
<
https://
www
.rfc
-editor
.org
/info
/rfc6781
>
.
[RFC6975]
Crocker, S.
and
S. Rose
,
"Signaling Cryptographic Algorithm Understanding in DNS Security Extensions (DNSSEC)"
,
RFC 6975
,
DOI 10
.17487
/RFC6975
,
July 2013
,
<
https://
www
.rfc
-editor
.org
/info
/rfc6975
>
.
[RFC7129]
Gieben, R.
and
W. Mekking
,
"Authenticated Denial of Existence in the DNS"
,
RFC 7129
,
DOI 10
.17487
/RFC7129
,
February 2014
,
<
https://
www
.rfc
-editor
.org
/info
/rfc7129
>
.
[RFC7344]
Kumari, W.
,
Gudmundsson, O.
, and
G. Barwood
,
"Automating DNSSEC Delegation Trust Maintenance"
,
RFC 7344
,
DOI 10
.17487
/RFC7344
,
September 2014
,
<
https://
www
.rfc
-editor
.org
/info
/rfc7344
>
.
[RFC7583]
Morris, S.
,
Ihren, J.
,
Dickinson, J.
, and
W. Mekking
,
"DNSSEC Key Rollover Timing Considerations"
,
RFC 7583
,
DOI 10
.17487
/RFC7583
,
October 2015
,
<
https://
www
.rfc
-editor
.org
/info
/rfc7583
>
.
[RFC7646]
Ebersman, P.
,
Kumari, W.
,
Griffiths, C.
,
Livingood, J.
, and
R. Weber
,
"Definition and Use of DNSSEC Negative Trust Anchors"
,
RFC 7646
,
DOI 10
.17487
/RFC7646
,
September 2015
,
<
https://
www
.rfc
-editor
.org
/info
/rfc7646
>
.
[RFC7958]
Abley, J.
,
Schlyter, J.
,
Bailey, G.
, and
P. Hoffman
,
"DNSSEC Trust Anchor Publication for the Root Zone"
,
RFC 7958
,
DOI 10
.17487
/RFC7958
,
August 2016
,
<
https://
www
.rfc
-editor
.org
/info
/rfc7958
>
.
[RFC8027]
Hardaker, W.
,
Gudmundsson, O.
, and
S. Krishnaswamy
,
"DNSSEC Roadblock Avoidance"
,
BCP 207
,
RFC 8027
,
DOI 10
.17487
/RFC8027
,
November 2016
,
<
https://
www
.rfc
-editor
.org
/info
/rfc8027
>
.
[RFC8078]
Gudmundsson, O.
and
P. Wouters
,
"Managing DS Records from the Parent via CDS/CDNSKEY"
,
RFC 8078
,
DOI 10
.17487
/RFC8078
,
March 2017
,
<
https://
www
.rfc
-editor
.org
/info
/rfc8078
>
.
[RFC8080]
Sury, O.
and
R. Edmonds
,
"Edwards-Curve Digital Security Algorithm (EdDSA) for DNSSEC"
,
RFC 8080
,
DOI 10
.17487
/RFC8080
,
February 2017
,
<
https://
www
.rfc
-editor
.org
/info
/rfc8080
>
.
[RFC8145]
Wessels, D.
,
Kumari, W.
, and
P. Hoffman
,
"Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)"
,
RFC 8145
,
DOI 10
.17487
/RFC8145
,
April 2017
,
<
https://
www
.rfc
-editor
.org
/info
/rfc8145
>
.
[RFC8198]
Fujiwara, K.
,
Kato, A.
, and
W. Kumari
,
"Aggressive Use of DNSSEC
-Validated Cache"
,
RFC 8198
,
DOI 10
.17487
/RFC8198
,
July 2017
,
<
https://
www
.rfc
-editor
.org
/info
/rfc8198
>
.
[RFC8499]
Hoffman, P.
,
Sullivan, A.
, and
K. Fujiwara
,
"DNS Terminology"
,
BCP 219
,
RFC 8499
,
DOI 10
.17487
/RFC8499
,
January 2019
,
<
https://
www
.rfc
-editor
.org
/info
/rfc8499
>
.
[RFC8509]
Huston, G.
,
Damas, J.
, and
W. Kumari
,
"A Root Key Trust Anchor Sentinel for DNSSEC"
,
RFC 8509
,
DOI 10
.17487
/RFC8509
,
December 2018
,
<
https://
www
.rfc
-editor
.org
/info
/rfc8509
>
.
[RFC8624]
Wouters, P.
and
O. Sury
,
"Algorithm Implementation Requirements and Usage Guidance for DNSSEC"
,
RFC 8624
,
DOI 10
.17487
/RFC8624
,
June 2019
,
<
https://
www
.rfc
-editor
.org
/info
/rfc8624
>
.
[RFC8901]
Huque, S.
,
Aras, P.
,
Dickinson, J.
,
Vcelak, J.
, and
D. Blacka
,
"Multi-Signer DNSSEC Models"
,
RFC 8901
,
DOI 10
.17487
/RFC8901
,
September 2020
,
<
https://
www
.rfc
-editor
.org
/info
/rfc8901
>
.
[RFC9077]
van Dijk, P.
,
"NSEC and NSEC3: TTLs and Aggressive Use"
,
RFC 9077
,
DOI 10
.17487
/RFC9077
,
July 2021
,
<
https://
www
.rfc
-editor
.org
/info
/rfc9077
>
.
[RFC9157]
Hoffman, P.
,
"Revised IANA Considerations for DNSSEC"
,
RFC 9157
,
DOI 10
.17487
/RFC9157
,
December 2021
,
<
https://
www
.rfc
-editor
.org
/info
/rfc9157
>
.
[RFC9276]
Hardaker, W.
and
V. Dukhovni
,
"Guidance for NSEC3 Parameter Settings"
,
BCP 236
,
RFC 9276
,
DOI 10
.17487
/RFC9276
,
August 2022
,
<
https://
www
.rfc
-editor
.org
/info
/rfc9276
>
.
Acknowledgements
The DNS world owes a depth of gratitude to the authors and other contributors
to the core DNSSEC documents and to the notable DNSSEC extensions.
¶
In addition, the following people made significant contributions to early draft versions
of this document:
Ben Schwartz
and
Duane Wessels
.
¶
Author's Address
Paul Hoffman
ICANN
Email:
paul
.hoffman
@icann
.org
RFC
9364
: DNS Security Extensions (DNSSEC)
Best Current Practice
Contents
About this RFC
Errata
In this section
1 Introduction
1.1 DNSSEC as a Best Current Practice
1.2 Implementing DNSSEC
2 DNSSEC Core Documents
2.1 Addition to the DNSSEC Core
3 Additional Cryptographic Algorithms and DNSSEC
4 Extensions to DNSSEC
5 Additional Documents of Interest
6 IANA Considerations
7 Security Considerations
8 References
8.1 Normative References
8.2 Informative References
Acknowledgements
Author's Address
Footer
rfc-editor.org is maintained by the
Internet Engineering Task Force
System Status
·
Report a Bug
·
Version 1.76.1
Useful links
IETF.org
IRTF.org
IAB.org
Datatracker
Author Resources
Contact Us
RFC Editor
rfc-dist Info Page
rfc-interest Info Page
Expand sidebar


Contact Us - American Registry for Internet Numbers
Skip to main content
Your IP
address is
Log in
Log in
User
Dashboard
Settings
Profile and security information
Log Out
Search
all requests subject to
terms of use
Search
IP Addresses & ASNs
Get Started
ARIN Account Management
Requesting IP Addresses or ASNs
IPv6 Information
IPv4 Addressing Options
Autonomous System Numbers
Legacy Resources at ARIN
Fee & Billing Information
Fee Schedule
Premier Support Plan (PSP)
Make a Payment
How Billing Works
Resource Revocation, Returns, and Reinstatement
IP & ASN Registry Services
Managing Resource Records
Automating Record Management with Reg-RWS
Transferring IP Addresses & ASNs
Reporting Reassignments
Using Whois
Routing Security
Resource Public Key Infrastructure (RPKI)
Internet Routing Registry (IRR)
Securing DNS (DNSSEC)
Reverse DNS
Routing Security Eligibility FAQs
Policy & Participation
Policy
Number Resource Policy Manual
Policy Development Process (PDP)
Draft and Recommended Draft Policies
Policy Proposals
Meetings & Events
Public Policy and Members Meetings
Outreach Events
ARIN Fellowship Program
Sponsorship
Past Meetings
Membership & Elections
Membership
Elections
Community Interaction
ARIN Community Satisfaction Surveys
Mailing Lists
Consultations & Suggestions
Reference & Tools
Tools
Operational Test and Evaluation (OT&E) Environment
CIDR Calculator
Community Software Repository
Internet Number Resource Fraud Reporting
Reference
Spam & Network Abuse Reporting
Registry Data Description
Data Accuracy
Information Security at ARIN
ARIN Software Releases
Research
Statistics & Reporting
Historical Whois Data (WhoWas)
Bulk Whois Data
Training & Education
ARIN Leadership Development Program
Instructional Webinars
Resource Materials
ARIN Online Help Videos
About
Welcome to ARIN
Organization Structure & Staff
Our Region
ARIN Board of Trustees
Advisory Council
NRO Number Council
Careers
Corporate Documentation
Corporate Documents
Annual Reports
Strategic Planning & Budgeting
Agreements
History of ARIN
Third-Party Vendors and IPv6
Community Grants
ARIN Community Grant Program
Community Grant Program Recipients
External Relations
Internet Governance
Memberships, Sponsorships, and MOUs
ARIN, Law Enforcement, and Public Safety
Technical Community
Blog
Pay Now
Feedback
Home
Contact Us
Home
Contact Us
On this page
Skip to main text
Scroll for more
Ask ARIN
Email Contacts
Financial Services
Communications Department
Legal Department
Engineering Department
Web Forms
Operating Hours
Holidays
Inclement Weather
Careers
Jump to related content
Notice
To protect our systems, ARIN may block traffic from IP address ranges known to be associated with malicious activity, which may impact your ability to reach our website and customer portal. If you are unable to reach
https://www.arin.net
or
https://account.arin.net/public/login
, please contact our Customer Service Desk by calling +1.703.227.0660 between 7:00 AM and 7:00 PM ET.
Report Service Issues
Service issues and outages can be reported directly to Registration Services during our regular
operating hours
. Outside operating hours, issues can be reported through the Feedback button found on every page of the website or via the “
Report a Service Issue
” form found on the
Service Status page
.
Need Help? Ask ARIN!
ARIN Online Users can take advantage of
Ask ARIN to answer most questions.
Help Desks
Registration Services
Hours: 7 AM-7 PM ET, Monday-Friday
Phone: +1.703.227.0660
Fax: +1.703.997.8844
Tips for Calling the Registration Services Help Desk
Billing
Hours: 9 AM-5 PM ET, Monday-Friday
Email:
billing@arin.net
Phone: +1.703.227.9886
Fax: +1.703.997.8708
Physical Addresses
Mailing Address
P.O. Box 232290
Centreville, VA 20120 USA
Phone: +1.703.227.9840
Fax: +1.703.263.0417
Remittance Address
(For Payment Only)
American Registry for Internet Numbers, Ltd
P.O. Box 719477
Philadelphia, PA 19171-9477
Ask ARIN
ARIN Online users who are logged in may submit questions through the
Ask ARIN
feature. Questions may be about anything ARIN-related: policy process, meetings, elections, billing, help with ARIN Online, etc., and will be routed to the appropriate department for response. All ARIN Online correspondence is tracked using web messaging.
Email Contacts
Please review the relevant portions of this website before sending email, as most answers can be found online. Be sure to visit our
site map
or take advantage of our site search engine, available through a link in the footer of every page. If you cannot find the information you are seeking, review the list below for the appropriate email address.
Financial Services
(Open 9 AM-5 PM ET, Monday-Friday)
Use
billing@arin.net
for help with:
Invoices
Payments status inquiries
Billing Contact changes
Service fees
Agreement Inquiries
Communications Department
(Open 9 AM-5 PM ET, Monday-Friday)
Use
info@arin.net
for help with:
Suggestions and general questions about ARIN
Mailing lists
Use
media@arin.net
for help with:
Media inquiries, including interview requests and story information
Request a speaker from ARIN for your event
Use
meetings@arin.net
for help with:
Meeting registration questions
Meeting invitation letter requests
Sponsorship opportunities
General meeting-related questions or comments
Use
members@arin.net
for help with:
ARIN Membership
Voting Contact updates
Elections
Use
training@arin.net
for help with:
Training and education inquiries
Suggestions for training events and webinars
Use
webmaster@arin.net
for help with:
ARIN’s web servers
Forms at ARIN
Use
blog@arin.net
for help with:
Writing a guest blog post
Contributing an IPv6 case study
Legal Department
(Open 9 AM-5 PM ET, Monday-Friday)
Use
compliance@arin.net
for help with:
Reporting Whois discrepancies
Privacy Policy
inquiries
Use our
Report a Violation page
to let us know of any violations of the ARIN Participants Expected Standards of Behavior. Please review the
ARIN Mission Statement
and the
Standards of Behavior
before submitting reports.
Engineering Department
(Open 9 AM-5 PM ET, Monday-Friday)
Use
projects@arin.net
for help with:
Posting tools to the Community Projects Software Repository (
http://projects.arin.net
)
Web Forms
Each of the forms below is associated with a described process, and details for each process are linked to within the “Description” below each form link. Please be sure to review the detailed processes and requirements before submitting information via the online forms.
Suggestions
This form is for the suggestion portion of the
ARIN Consultation and Suggestion Process (ACSP)
. The suggestion process provides the members of ARIN or the broader community in the ARIN region a formal means to suggest changes or additions to ARIN services and practices. Any person in the ARIN community is welcome to make a suggestion regarding an existing or potential ARIN service or practice.
Whois Inaccuracy Reporting
This service is to be used to notify ARIN of inaccurate Whois records, including Point of Contact records (POCs), Organization Identifiers (Org IDs)/Org Handles, Network records (NETs), and Autonomous System Numbers (ASNs) with outdated or erroneous organization or contact information.
Number Resource Fraud Reporting
This form is part of the
Fraud Reporting Process
and is to be used to notify ARIN of suspected Internet number resource fraud including the submission of falsified utilization or organization information, unauthorized changes to data in ARIN’s WHOIS, hijacking of number resources in ARIN’s database, or fraudulent transfers.
Operating Hours
The ARIN office is open from 7:00 AM to 7:00 PM ET, Monday through Friday, except for
certain holidays
. Outside operating hours, messages may be left for the ARIN Registration Services Help Desk (703.227.0660), ARIN’s Billing Help Desk (703.227.9886), or on ARIN’s main number (703.227.9840).
Email to ARIN will continue to be processed when the office is closed; however in the event of holidays or closings due to inclement weather, responses or the processing of resource requests may be delayed.
Holidays
ARIN closes its office for the following holidays and notes these closings at
https://www.arin.net
.
2026 Holiday Schedule
Holiday
Day of the Week
Date
New Year’s Day
Thursday
1 January 2026
Martin Luther King Jr. Day
Monday
19 January 2026
Presidents’ Day
Monday
16 February 2026
Memorial Day
Monday
25 May 2026
Juneteenth
Friday
19 June 2026
Independence Day
Friday
3 July 2026
Labor Day
Monday
7 September 2026
Veterans Day
Wednesday
11 November 2026
Thanksgiving
Thursday - Friday
26-27 November 2026
December Holiday
Thursday - Friday
24-25 December 2026
New Year’s Day
Friday
1 January 2027
The ARIN office also closes early on 22 May, 4 September, and 25 November 2026. On these days, the main office, Financial Services Help Desk, and Registration Services Help Desk close beginning at 3:00 PM ET.
Inclement Weather
Should the ARIN office close due to inclement weather or other extreme circumstance, such closings are noted at
https://www.arin.net/.
Careers
For information about current job openings and specific email addresses to contact regarding them, please see the
Careers page
.
Related
New to ARIN
Acronym Guide
Back to top
Back
to top
Terms of Service
Site Map
Privacy Policy
Network Abuse
Accessibility
Standards of Behavior
© Copyright 1997
– 2026
, American Registry for Internet Numbers, Ltd.
A member of the Number Resource Organization
Service Status
Contact Us
Registration Services:
+1.703.227.0660
Financial Services:
+1.703.227.9886
Main:
+1.703.227.9840
Visit ARIN on LinkedIn
Visit ARIN on Instagram
Visit ARIN on Facebook
Visit ARIN on X
Visit ARIN on YouTube
Media


Resources - ICANN

Resources - ICANN
Skip to main content
Search ICANN.org
Log In
Sign Up
Get Started
About ICANN
ICANN for Beginners
Fellowship Program
NextGen@ICANN Program
History
News and Media
Announcements
Blog
Media Resources
Press Releases
Global Newsletters
ICANN News Subscriptions
Regional Reports
Policy
Develop Policy
Operational Design Phase (ODP)
Implement Policy
Community Participation Guidelines
Public Comment
Public Comment Home
Upcoming Proceedings
Open Proceedings
Closed Proceedings
About Public Comment
Other Public Consultations
Resources
Board Activities and Meetings
Accountability Mechanisms
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
Contractual Compliance
Domain Name Security Threats
Privacy and Proxy Services
Government Engagement
Careers
Complaints Office
I Need Help
ICANN 25th Anniversary Photo Mosaic
Community
Engagement Calendar
Address Supporting Organization (ASO)
Country Code Names Supporting Organization (ccNSO)
Generic Names Supporting Organization (GNSO)
At-Large Advisory Committee (ALAC)
Governmental Advisory Committee (GAC)
Root Server System Advisory Committee (RSSAC)
Security and Stability Advisory Committee (SSAC)
Quicklinks
Board Activities and Meetings
Data Protection and Privacy
Domain Name Registrants
Engagement Calendar
IANA Services
ICANN Acronyms and Terms
ICANN Grant Program
New gTLD Program
Public Technical Identifiers (PTI)
Open Data
Question About A Domain Name?
Technology @ ICANN
WSIS+20 Outreach Network
Resources
About ICANN
Academic Engagement
Acronyms and Terms
Courses and Learning
ICANN for Beginners
Participate
What ICANN Does
Effect on the Internet
What's Going On Now
How to Participate
Fellowship Program
Committee
Terms & Conditions
NextGen@ICANN Program
President's Corner
ICANN Management Organization Chart
Staff
Careers
In Focus
ICANN Response Planning Framework
DNSSEC
Standards
IANA DNSSEC Root Information
TLD DNSSEC Report
Root Deployment
Deployment Graph
Tools
Training
Key Ceremony
News
Blog Posts
Presentations
Related Sites
GNSO Improvements
Travel Support
Media Resources
ICANN News
About ICANN
Subscribe and Follow
Contacts
Board Activities and Meetings
Accountability
Accountability Mechanisms
Reconsideration
Independent Review Process
Updating the IRP
Ombuds
About the Ombuds Office
Contact the Ombuds Office
Ombuds Office Services
Complaints About Unfairness
Complaints About Harassment
Collaborative Conflict Resolution
Request for Reconsideration
Resources for Community Members
Ombuds Office Accountability
Ombud's Blogs
Empowered Community
Empowered Community Administration
Empowered Community Administration Mailing List
Empowered Community Correspondence
Document Disclosure
Reviews
Organizational Reviews
ALAC
ASO
Board
ccNSO
GNSO
Nominating Committee
RSSAC
SSAC
Technical Liaison Group
Specific Reviews
Accountability & Transparency
Registration Directory Service
Security, Stability, and Resiliency
Competition, Consumer Trust & Consumer Choice
CCT Metrics
Expected Standards of Behavior
Employee Practices and Resources
Enhancing ICANN Accountability – Work Stream 2 Implementation
Governance
Governance Documents
Evolving ICANN’s Multistakeholder Model
Agreements
NTIA IANA Functions' Stewardship Transition
Call for Public Input: Draft Process to Develop the Proposal (8 April-8 May 2014
Process to Develop the Proposal and Next Steps
Registry
Archive
Affirmation of Commitments
AOC Tracking
ccTLD
Partnership Memorandums of Understanding
Registrar
Archive
Annual Reports
Financials
Financial Reports
Policies, Guidelines and Procedures
Annual Disclosure of Payments to Suppliers
Lobbying Disclosures & Contribution Reports
Planning
Strategic Plan
ICANN Strategic Plan for FY26-30
ICANN's Annual Strategy Review Program
ICANN Strategic Plan for FY21-25
Strategic Outlook Trends Program
ICANN Strategic Plan for FY16-20
Operating Plan
Presentations
RFPs
Litigation
Newsletter
Correspondence
2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006
2005
2004
2003
2002
2001
2000
1999
1998
Quarterly Reports
Groups
2023 ICANN CEO Search Committee
RSSAC
Charter
SSAC
GAC
At-Large
ASO
ccNSO
GNSO
Technical Liaison Group
Technical Experts Group (TEG)
NomCom
Past NomComs
Customer Standing Committee
Root Zone Evaluation Review Committee (RZERC)
Business
Civil Society
Complaints Office
Complaints Report
Domain Name System Abuse
Contractual Compliance
About
Enforcement of DNS Abuse Obligations
Formal Enforcement Notices
Archive
Contractual Compliance Metrics
Blogs
Contractual Compliance Audit Program
Notice of Bankruptcy, Convictions and Security Breaches
Contractual Compliance Reports
Audit Reports
Enforcement of DNS Abuse Mitigation Requirements: Periodic Reviews
Contractual Compliance Monthly Reports
gTLD Registry Compliance
Accredited Registrar Compliance
General Questions
Outreach
Contracted Parties (Registry Operators and Accredited Registrars)
Domain Name Registrants
About Domain Names
ICANN Policies
Registration Data Policies
WHOIS and Registration Data Directory Services
The Domain Name Registration Process
Using Domain Name Registration Data
Keeping Registration Data Accurate
Access and the Evolution of the WHOIS System
Domain Name Industry
Registering Domain Names
Managing Domain Names
Contact Information and WDRP
Securely Managing Your Domain Name
Transferring Domain Names
Renewing Domain Names
Rights and Responsibilities
Spam, Phishing, and Website Content
Trademark Infringement
GDS Metrics
Identifier Systems Security, Stability and Resiliency (OCTO-SSR)
ccTLDs
Background Materials
Agreements
Delegation
Root Zone Database
Model MOU
Workshops
ICANN and ISO
Internationalized Domain Names
Root Zone Label Generation Rules (LGR)
Generation Panel Update
Maximal Starting Repertoire
Proposals for Root Zone Label Generation Ruleset
IDN Variant TLD Implementation
LGR Toolset
IDN ccTLD Fast Track
IDN Implementation Guidelines
Second-Level LGR Reference
Resources
Announcements and Blogs Posts
New gTLD Program
Universal Acceptance Initiative
Make your systems UA-ready
UA Training
UA Day
UA Readiness Evaluations
UA Initiatives
Announcements and Blogs Posts
Policy
Policy Mission
Policy Staff Goals
Presentations
Global Addressing
IPv6 Allocation
ASN Allocation
Post Exhaustion IPv4 Allocation
New RIRs Criteria
Review Procedures
Policy Updates
Operational Design Phase (ODP)
Implementation
Public Comment
Open
Upcoming
Archive
Root Zone KSK Rollover
Technical Functions
Tech Day Archive
ICANN Locations
Report Security Issues
PGP Keys
Certificate Authority
Registry Liaison
Ombudsman
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Charter Eligibility Dispute Resolution Policy
Providers
Rules
Eligibility Requirements Dispute Resolution Policy
Providers
Rules
Intellectual Property Defensive Registration Challenge Policy
Providers
Rules
Qualification Challenge Policy
Providers
Rules
Restrictions Dispute Resolution Policy
Providers
Rules
Transfer Dispute Resolution Policy
Providers
Uniform Domain Name Dispute Resolution Policy
Policy Document
Providers
Provider Approval Process
Rules
Principal Documents
Proceedings
Historical Documents
Timeline
Name Collision
Registrar Problems
Whois Data Correction
Independent Review Process
Request for Reconsideration
Document
Explore Our Resources
Take a course, connect with peers for support, or explore multimedia resources including guides, podcasts, videos, and webinars. Many resources are provided in multiple languages.
Resources by Department
ccTLDs
References useful to country code managers and operators, including: letters of agreement between each ccTLD and ICANN; documents related to ccTLDs from entities such as ICANN Board, Staff, IANA, and the GAC; the full text of ICP-1; and more.
Complaints Office
If you have a complaint about the ICANN Organization, this is where you’ll find an overview of the Complaints Office, information on how to submit a complaint, and other relevant resources.
Contractual Compliance
Every ICANN-accredited registrar and registry has a contract with ICANN. Here’s where you can learn about all facets of ICANN’s Contractual Compliance Program, which helps both ICANN and the contracted parties each fulfill their end of the agreement.
Internationalized Domain Names
You’ll find the lengthy, detailed history of IDNs here, along with technical implementation guidelines, publications and presentations about IDNs, an IDN glossary, ICANN blog entries about IDN updates, and more.
Policy
Links here present background, updates, and announcements about important areas of Internet policy currently being addressed by the ICANN community’s bottom-up, consensus based, policy development process.
Registrars
Information found here related to Registrars ranges widely, including a list of all accredited registrars, how to become a registrar, the registrar data escrow program, how dispute resolution works, and updates on domain-related policies.
Registries
Registry personnel can find a variety of help here, such as: agreements, consensus policies, key ICANN contacts for registries, a list of valid top-level domains, a list of all accredited registries, and much more.
ICANN is not responsible for profile content or verification of user details.
YouTube
Twitter
LinkedIn
Flickr
Facebook
Newsletters
Community Wiki
ICANN Blog
Who We Are
ICANN For Beginners
ICANN Learn
Participate
Groups
Board Members
CEO Corner
Staff
Careers
Public Responsibility
Contact Us
Locations
Report Security Issues
Certificate Authority
Registry Liaison
Ombuds
Complaints Office
Media Resources
Accountability And Transparency
Accountability Mechanisms
Document Disclosure
Independent Review Process
Request for Reconsideration
Empowered Community
Employee Anonymous Hotline Policy and Procedures
Governance
Governance Documents
Agreements
Organizational Reviews
Specific Reviews
Annual Report
Financials
Planning
RFPs
Litigation
Correspondence
Help
I Need Help
Dispute Resolution
Domain Name Dispute Resolution
Name Collision
ICANN Lookup
Registration Data Request Service (RDRS)
Data Protection
Data Privacy Practices
Privacy Policy
Terms of Service
Cookies Policy
© Internet Corporation for Assigned Names and Numbers.
Privacy Policy
Terms of Service
Cookies Policy
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."