The document provides an overview of the history and operational considerations for country code top-level domains (ccTLDs) and internationalized domain names (IDNs). It discusses the early history of DNS and the establishment of ccTLDs in the 1980s. It then covers basic concepts like the designation of ccTLD codes based on ISO standards and the role of ccTLD operators. The document also summarizes some common policy decisions for ccTLDs as well as technical and security requirements for operating a TLD registry.

1. 5/21/15
1
CcTLD and IDN Operations
John Crain & Champika Wijayatunga | BDNOG3| 19 May 2015
| 2
History & Basic
Concepts
Policy Decisions
Operational
Decisions
IDN Program
1 2
3 4
Agenda

2. 5/21/15
2
| 3
History
1983 DNS was designed/invented by Paul Mockapetris (RFC882 &
883)
1984 Berkeley Internet Name Domain (BIND) Server developed
Original Seven Generic TLDs (.com,
.edu,
.gov,
.int,
.mil,
.net,
and
.org)
1985 First country codes assigned .us,
.uk,
and
.il
1986 .au,
.de,
.fi,
.fr,
.jp,
.kr,
.nl
and
.se
1987 RFC1034 (Considered the first full DNS Specification)
…….. Country Code TLDs continue to be added….
2000 Seven new TLDs added
(.aero,
.coop,
.museum,
.biz,
.info,
.name,
and
.pro)
2012 New round of applications for gTLDs opened by ICANN
Some Basic Concepts for a
CcTLD

3. 5/21/15
3
| 5
Designation of codes
ccTLDs
are
given
a
DNS
string
based
on
the
Alpha-­‐2
codes
within
ISO-­‐3166
hMp://www.iso.org/iso/home/standards/country_codes.htm
| 6
CcTLD as a Public Trust
ccTLDs
are
designated
to
operators
who
would
operate
them
in
the
best
interests
of
the
local
communiQes
they
served.
Operators
should
strive
to
tailor
operaQons
to
best
serve
the
users:
‣
Ensure
minimum
technical
standards
are
met
‣
Strive
to
meet
best
pracQces
‣
Operate
with
policy
that
suits
local
requirements

4. 5/21/15
4
| 7
Who Currently Operate CcTLDS
Many
of
the
CcTLDs
were
assigned
in
the
1980’s.
They tended to be assigned to whomever was involved in
building the Internet in a specific country
Some changed hands over the years
What types of organisations?
Universities
ISPs/Telcos
Regulators
Dedicated entities
http://www.iana.org/domains/root/db
| 8
Types of Contacts that IANA is aware of
.BD
Sponsoring Organisation:
Ministry
of
Post
&
TelecommunicaQons
Bangladesh
Secretariat
Administrative contact:
Director
(Telecom)
Ministry
of
Post
&
TelecommunicaQons
Bangladesh
Secretariat
Technical Contact:
Divisional
Engineer
(Telex
&
TP)
Bangladesh
TelecommunicaQons
Company
Limited
(BTCL)
http://www.iana.org/domains/root/db/bd.html

5. 5/21/15
5
Policy Decisions
What are they?
| 10
What do I mean by “Policies”
Anything
that
defines
how
and
by
whom
names
can
be
registered.
Typically CcTLDs have no contract with ICANN
And are bound by local rather than ICANN
policies
Can participate in global discussion through
ICANN’s CCNSO
http://ccnso.icann.org

6. 5/21/15
6
| 11
There is no ONE model for CcTLDs
Different models work well in different
environments.
This is driven by many things including
operational considerations on the ground, local
business practices and local culture.
Policy and operations of a CcTLDs are often built
over time and reflect the local environment.
| 12
Who should decide the policies
Whoever
has
the
role
of
Sponsoring
organisaQon
has
the
role
of
ensuring
that
policies
are
developed
and
implemented.
Many CcTLDs have a model that follow a multi-stakeholder
Solution.
This can take many forms from formal “Policy boards” to
processes for gathering public input.
Often inclusive of Government, Industry and Civil Society
as well as registrants

7. 5/21/15
7
| 13
Some policy discussions
Which
sales
model?
Direct
registra2on:
‣
No
middle
man
-­‐
easier
to
control
most
aspects
of
RegistraQon
Registry-­‐registrar
model
‣
Requires
an
interface
between
registry
and
registrar
‣
Offloads
end-­‐user
interface
from
registry
Both:
| 14
Some policy discussions
Scope
of
Registra2ons?
Local
or
Global
sales?
There
are
examples
of
CcTLDs
of
both
types
Decide
which
best
serves
the
community
‣
Consider
that
the
legal
implicaQons
are
different
‣
Consider
that
the
risks
are
different

8. 5/21/15
8
| 15
Some policy discussions
Dispute
Resolu2on:
Ensure
that
local
law
prevails?
You
don’t
want
to
be
arguing
in
foreign
courts
Alternate
Dispute
Resolu2on
(ADR)?
Design
to
be
lightweight!
UDRP
is
ogen
used
as
a
base
model
hMp://www.icann.org/udrp/udrp.htm
| 16
Not really Policy matters
Who runs the technical operations?
This is really a business decision.
Policy can define the type of organisation but
business decisions should guide the actual
choice.
Technology choices
These are generally operational matters.
The important factor to ensure that the
“operator” is bound by the policies created and
that choices they make meet those
requirements.

9. 5/21/15
9
| 17
Outsourcing
There
are
an
increasing
number
of
companies
that
will
provide
services
to
TLD
managers.
Whole
registry
back-­‐end
providers
AuthoritaQve
name
server
providers
ccTLD
managers
should
understand
the
basics
of
how
to
run
the
services
themselves
before
they
outsource
them.
Allows
you
to
manage
and
monitor
performance
of
suppliers
Have
a
back-­‐up
strategy!
What
if
your
supplier
fails?
Operational Decisions
What does it take to run a
TLD?

10. 5/21/15
10
| 19
Technical Requirements for a TLD
‣
Networks
and
Servers
(redundant)
‣
Back
office
systems.
‣
Physical
and
Electronic
Security
‣
Quality
of
Service
(24/
7
availability!)
‣
Name
Servers
‣
DNS
sogware
(BIND,
NSD,
etc.)
‣
Registry
sogware
‣
DiagnosQc
tools
(ping,
traceroute,
zonecheck,
dig)
‣
Registry
Registrar
Protocol
| 20
Name Server Considerations
‣
Support
technical
standards
‣
Handle
load
mulQple
Qmes
the
measured
peak
‣
Diverse
bandwidth
to
support
above
‣
Must
answer
authoritaQvely
‣
Turn
off
recursion!
‣
Should
“NOT”
block
access
from
a
valid
Internet
hosts

11. 5/21/15
11
| 21
Secondary name server choice
Diversity,
diversity
and
diversity!
‣
Don’t
place
all
on
the
same
LAN/building/segment
‣
Network
diversity
‣
Geographical
diversity
‣
InsQtuQonal
diversity
‣
Sogware
and
hardware
diversity
‣
How
many?
‣
1<x<13
(x
will
vary
dependent
on
circumstances)
| 22
Security, Stability & Resliency Considerations
‣
Physical
security
‣
Deploy
stringent
access
controls
‣
Fire
detecQon
and
retardaQon
‣
Other
environmental
sensors
(Flood,
Humidity
etc.)
‣
Power
conQnuity
for
48
hours
(or
more)
‣
Backups
‣
MulQple
secure
copies
locally
and
offsite
‣
Test,
test
and
test!!

12. 5/21/15
12
| 23
Separations of Services
Registries
generally
start
small
and
evolve
SeparaQon
of
services
means
separaQng
the
logical
funcQons
and
elements
of
the
registry
Two
key
benefits:
SECURITY:
Clear
separaQon
of
services
is
a
manner
in
which
to
create
logical
security
zones
SCALABILITY:
You
can
scale
only
the
services
that
need
to
grow
as
they
need
to
grow
| 24
Separations of Services
‣
Consider
whether
services
are
public-­‐facing
‣
If
they
are
not,
place
them
in
an
area
inaccessible
from
the
public
Internet
‣
Constrain
access
as
much
as
possible
with
a
basQon
host
‣
Consider
finer-­‐grained
security
‣
Is
billing
data
more
sensiQve
than
WHOIS
data?
‣
Perhaps
separate
these
services
internally?

13. 5/21/15
13
| 25
Separations of Services
Separate
by
exposure!
Back-­‐office,
Public
facing
Place
each
funcQon/service
in
its
own
logical
box
Work
out
what
interfaces
the
funcQons
must
have
between
each
other
Open
firewall
to
connecQons
along
these
explicit
paths
Provide
clear
APIs
between
the
funcQons
The
clear
APIs
should
allow
scaling
of
parQcular
funcQons
by
adding
extra
servers,
etc.
| 26
Know your SLAs
‣
FuncQoning
name
servers
are
the
most
criQcal/visible
service
‣
All
other
services
also
need
to
be
considered
‣
Billing
‣
Whois
server,
webservers
‣
Registrar
APIs
‣
Consider
your
service
level
targets
and
how
you
will
meet
them
‣
DNS
servers
always
on,
other
systems
mostly
on?

14. 5/21/15
14
| 27
When it all goes wrong
DNS is a known target for hackers.
You will be targeted at some point!
Have plans in place to deal with attacks, failures and disasters.
Test those plans regularly!
Other resources

15. 5/21/15
15
| 29
Forums
Regional
organisaQons:
APTLD
(www.aptld.org)
-­‐
Your
local
group
CENTR
(www.centr.org)
LACTLD
(www.lactld.org)
AfTLD
(www.agld.org)
Also
see
the
CCNSO
(ccnso.icann.org)
| 30
Useful references
RFC
1591
-­‐
ccTLD
governance
hMp://www.rfc-­‐editor.org/rfc/rfc1591.txt
RFC
2870Bis
&
RSSAC001
-­‐
Root
Server
BCP
hMps://wiki.tools.ieq.org/html/drag-­‐iab-­‐2870bis-­‐02
hMps://www.icann.org/en/system/files/files/rssac-­‐001-­‐drag-­‐20nov14-­‐en.pdf

16. 5/21/15
16
IDN Program @ ICANN
Sarmad Hussain | IDN Program Sr. Manager
| 32
ASCII Domain Name Label
www.cafe.com
Second Level
Domain
Top Level
Domain (TLD)
Third Level
Domain
Forming ASCII Labels
Use LDH
• Letters [a-z]
• Digits [0-9]
• Hyphen (LDH)
Label length = 63
Other constraints (e.g. on hyphen)
Forming ASCII Labels
Use only Letters
• Letters [a-z]
Label length = 63

17. 5/21/15
17
| 33
Internationalized Domain Name (IDN) Labels
ตัวอย่าง‫۔‬ไทย
IDN Second
Level
Domain
IDN Top
Level
Domain
Syntax of IDN Labels
Valid U-Label: Unicode
code points as
constrained by IDNA2008
Valid A-Label - “xn--”
followed by punycode of
U-Label of length 59
Syntax of IDN Labels
Valid U-Label, further
constrained by the “letter”
principle for TLDs
Valid A-Label
বাংলা
Бел
‫ﺭر‬‫ﺍاﻝلﺝجﺯزﺍاﺉئ‬
հայ
中国
!ర#
한국
ලංකා
| 34
IDN TLD Program
Reports and documentation of all completed projects available at:
https://www.icann.org/resources/pages/reports-2013-04-03-en
PHASE
1
(2011)
Case
Studies:
Arabic
Chinese
Cyrillic
Devanagari
Greek
LaQn
PHASE
2
(2011-­‐12)
Integrated
Issues
Report
PHASE
3
(2012-­‐13)
Projects:
P1
LGR
XML
SpecificaQon
P2.1
LGR
Process
for
the
Root
Zone
P6
User
Experience
Study
for
TLD
Variants
PHASE
4
(Since
2013)
Projects:
P2.2
LGR
Development
P1
LGR
SpecificaQon
and
Toolset
P7
LGR
ImplementaQon
Community agreed to define a Label Generation Rules (LGR)

18. 5/21/15
18
| 35
Label Generation Rules (LGR) for Root Zone
¤ For the Root Zone, single “table” containing data for all scripts
¤ Must be conservative and secure
¤ For each script or writing system:
¤ Which code points are valid for use?
¤ Are any of these code points variants of each other?
¤ Are the any additional constraints on the labels?
| 36
IDN TLD Program

19. 5/21/15
19
| 37
Label Generation Rules (LGR)
¤ Valid code points
¤ Variants code points
‫ﭖپﺍا‬‫ﮎک‬‫ﺱسﺕتﺍاﻥن‬
‫ﭖپﺍا‬‫ﻙك‬‫ﺱسﺕتﺍاﻥن‬
¤ Label constraints
¤ Cannot mix ‫ﮎک‬ and ‫ﻙك‬ in a label
ü ‫ﮎک‬‫ﻝل‬‫ﮎک‬‫ﮎکﻝلﮎکﺕت‬
ü ‫ﻙك‬‫ﻝل‬‫ﻙك‬‫ﻙكﻝلﻙكﺕت‬
x ‫ﮎک‬‫ﻝل‬‫ﻙك‬‫ﮎکﻝلﻙكﺕت‬
x ‫ﻙك‬‫ﻝل‬‫ﮎک‬‫ﻙكﻝلﮎکﺕت‬
| 38
Root LGR by Generation and Integration Panels

20. 5/21/15
20
| 39
LGR Specification and Toolset
¤ LGR machine-readable specifications at
https://datatracker.ietf.org/doc/draft-davies-idntables
¤ Toolset functional priority
¤ Create LGR
¤ Use LGR
¤ Manage LGRs
¤ Open source LGR
Tool
Code
Point
Rules
Variant
Rules
WLE
Rules
IDN ccTLD Fast Track Process
Implementation

21. 5/21/15
21
IDN ccTLD Fast Track Process
IDNs at Second Level

22. 5/21/15
22
| 43
¤ IDN registration policies and practices at the second level
¤ Designed to minimize consumer risk or confusion
Respect interests of local languages and character sets
¤ Last updated in 2011: Version 3.0
¤ New IDN terminology due to IDN Variant TLD projects
¤ Consistent machine readable format for language tables
¤ Updated content analysis: IANA IDNA table with Unicode
versions, MSR, LGR
¤ Additional guidelines: informational RFC 6912, IDN TLD
Variants User Experience study
¤ GNSO community at ICANN asked to initiate review
¤ Current status – initiating next revision
IDN Impl. Guidelines for the Second Level
| 44
IDN Tables for the Second Level
¤ IDN Tables submitted by new gTLDs intending to offer IDNs at
second level
¤ Varied in the character repertoire and contextual rules
¤ Develop reference Label Generation Rulesets (LGRs) for
facilitation and consistency in Pre-Delegation Testing (PDT)
and the Registry Service Evaluation Process (RSEP)
¤ Promote reuse for secure and consistent end-user experience

23. 5/21/15
23
Get Involved:
Speak up for your language
| 46
¤ IDN Program sessions at ICANN meetings
¤ IDN Program updates to SOs/ACs at ICANN meetings
¤ Presentations at meetings
¤ APTLD, APrIGF, ArabIGF, IGFs, TLDCON, AFRINIC, RIPE NCC
¤ Email communication to SOs/ACs – call to action
¤ Blog for general community:
http://blog.apnic.net/2014/09/30/speak-up-for-your-language/
¤ IDN pages at ICANN Community Wiki and ICANN Website
¤ IDN mailing lists
¤ {vip, lgr, ArabicGP, ArmenianGP, ChineseGP, …}@icann.org
Communication and Outreach Efforts

24. 5/21/15
24
| 47
How to get involved?
Volunteer for your script Generation Panel (GP)
To contribute expertise, contribute to the GP for your script. You
can get involved by simply emailing your CV and a brief statement
of interest to idntlds@icann.org
Volunteer
Review
Listen
Review work through public comments
Sign up for the IDN mailing list vip@icann.org (to sign up, visit
https://mm.icann.org/listinfo/vip) and participated in the review of
IDN work being done at ICANN through the public comments
Keep yourself updated
Attend regular IDN Program Update sessions at ICANN meetings
and sign up on the IDN mailing list vip@icann.org to get updates
on the IDN Program at ICANN
| 48
Useful Links for IDN Program @ ICANN
• To join a Generation Panel for your language, submit CV and statement of
interest at: idntlds@icann.org; Call for Generation Panels:
http://www.icann.org/en/news/announcements/announcement-11jul13-en.htm
• LGR Document Repository:
https://community.icann.org/display/croscomlgrprocedure/Document+Repository
• Community Wiki for LGR Project:
https://community.icann.org/display/croscomlgrprocedure/Root+Zone+LGR
+Project
• IDN ccTLD Fast Track Page:
https://www.icann.org/resources/pages/string-evaluation-completion-2014-02-19-
en
• IDN Implementation Guidelines:
https://www.icann.org/resources/pages/implementation-guidelines-2012-02-25-en

25. 5/21/15
25
| 49
Reach us at:
Email: john.crain@icann.org
champika.wijayatunga@icann.org
Thank You and Questions
gplus.to/icann
weibo.com/ICANNorg
flickr.com/photos/icann
slideshare.net/icannpresentations
twitter.com/icann
facebook.com/icannorg
linkedin.com/company/icann
youtube.com/user/icannnews
Come talk to us!