cctld infrastructure & idn operation
TRANSCRIPT
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
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
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
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/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
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
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
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.
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?
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
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!!
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?
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?
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
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
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
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
PHAS
E 1 (2011)
Case Studies: Arabic Chinese Cyrillic Devanagari Greek LaQn
PHAS
E 2 (2011-‐12) Integrated Issues
Report
PHAS
E 3 (2012-‐13) Projects:
P1 LGR XML SpecificaQon P2.1 LGR Process for the Root Zone P6 User Experience Study for TLD Variants PH
ASE 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)
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
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
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
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
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
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 [email protected]
Volunteer
Review
Listen
Review work through public comments Sign up for the IDN mailing list [email protected] (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 [email protected] 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: [email protected]; 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
5/21/15
25
| 49
Reach us at: Email: [email protected]
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!