Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ccTLD Infrastructure & IDN Operation


Published on

ccTLD Infrastructure & IDN Operation

Published in: Internet
  • Be the first to comment

  • Be the first to like this

ccTLD Infrastructure & IDN Operation

  1. 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. 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. 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://   | 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. 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 | 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)
  5. 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  
  6. 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. 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. 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://   | 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. 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. 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. 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. 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. 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. 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. 15. 5/21/15   15   | 29 Forums Regional  organisaQons:            APTLD      (        -­‐      Your  local  group   CENTR      (   LACTLD  (   AfTLD      (       Also  see  the  CCNSO  (   | 30 Useful references RFC  1591  -­‐  ccTLD  governance       hMp://www.rfc-­‐     RFC  2870Bis  &  RSSAC001  -­‐  Root  Server  BCP     hMps://­‐iab-­‐2870bis-­‐02   hMps://­‐001-­‐drag-­‐20nov14-­‐en.pdf      
  16. 16. 5/21/15   16   IDN Program @ ICANN Sarmad Hussain | IDN Program Sr. Manager | 32 ASCII Domain Name Label 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. 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: 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. 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. 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. 20. 5/21/15   20   | 39 LGR Specification and Toolset ¤  LGR machine-readable specifications at ¤  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. 21. 5/21/15   21   IDN ccTLD Fast Track Process IDNs at Second Level
  22. 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. 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: ¤  IDN pages at ICANN Community Wiki and ICANN Website ¤  IDN mailing lists ¤  {vip, lgr, ArabicGP, ArmenianGP, ChineseGP, …} Communication and Outreach Efforts
  24. 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 Volunteer Review Listen Review work through public comments Sign up for the IDN mailing list (to sign up, visit 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 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:; Call for Generation Panels: •  LGR Document Repository: •  Community Wiki for LGR Project: +Project •  IDN ccTLD Fast Track Page: en •  IDN Implementation Guidelines:
  25. 25. 5/21/15   25   | 49 Reach us at: Email: Thank You and Questions Come talk to us!