4. Organizational Alphabet Soup
• ICANN – Internet Corporation for Assigned Names
and Numbers – coordinates unique identifiers
(names and numbers) and ensure their stable and
secure operation.
– ICANN has several technical and policy committees
which operate independently
• SSAC – Security and Stability Advisory Council
• RSSAC – Root Server System Advisory Council
• ALAC – At Large Advisory Council
• ccNSO – Country Code Name Supporting Organization
• GNSO – Generic Names Supporting Organization
• ASO - Address Supporting Organization
4
5. Organizational Alphabet Soup
• IANA – Internet Assigned Numbers Authority –
allocates and maintains unique codes and
numbering systems; manages & publishes root zone
• ISOC – Internet Society – global nonprofit
supporting Internet standards, education & policy
• IETF – Internet Engineering Task Force – produces
engineering documents that describe the design,
use and management of the Internet
• IAB – Internet Architecture Board - provides
architectural oversight of IETF, oversight & appeals
of Internet standards.
• IGF – Internet Governance Forum – multi-
stakeholder forum for discussing policy issues
5
6. Organizational Alphabet Soup
• RIR – Regional Internet Registry – perform identification
assignment (IP addresses & AS numbers) within
geographic region
– ARIN
– RIPENCC
– LACNIC
– AFRINIC
– APNIC
• gTLD – generic Top Level Domain – function as registry
for unrestricted, sponsored, geographic, or commecial
domains
• ccTLD – country code Top Level Domain - function as
registry for their respective countries
6
7. Organizational Alphabet Soup
• RO – Root Operator – an operator of one of the 13
named root servers.
• ASO – Authoritative Server Operator – an operator
of an authoritative name server; typically an
enterprise’s IT department, TLD operator, or even
outsourced providers
• RSO – Recursive Server Operator – an operator of a
recursive or caching name server; can be anyone
running DNS server software!
7
8. Organizational Alphabet Soup
• Regional TLD Organization – membership based
organizations supporting TLDs within a geographic
region
– LACTLD – Latin America, South America, Carribean
– CENTR - Europe
– AFTLD - Africa
– APTLD – Asia (including middle east) and Pacific
• Registry – an entity given the authority to operate a
top level domain; manages zone and administrative
data; typically an organization, business,
government, university or network operators center
• Registrar – an entity accredited by ICANN to register
domains at retail within one or more TLDs.
8
9. Registry Structures
• Registries Come in All Shapes and Sizes
– Structure, Technical Implementation, Goals & Policies
• “Models” Define How the Registry Operates
– 2R vs. 3R
– Thick vs. Thin
– 2 vs. 3 Levels
9
10. Registry Structures
• Registry “2R” Model
– Registry - Registrant
– Registry provides direct registrations to consumers
– Registrants request domains directly through registry
• Simple model
Registry • Doesn’t scale without
lots of work from registry
• Direct customer
relationships
Registrant Registrant
10
11. Registry Structures
• Registry “2R” Model
– Registry - Registrant
– Registry provides direct registrations to consumers
– Registrants request domains directly through registry or
optionally through a direct reseller
• Simple model
• Direct customer
Registry relationships
• Offloads some
“customer interface”
work from registry to
Reseller reseller
Registrant
Registrant
11
12. Registry Structures
• Registry “3R” Model
– Registry – Registrar – Registrant
– Registrars interface between customer and registry
Registry
• More stakeholders ->
Registrar Registrar more policies / business
models
• Less work for registry
(automation / EPP) –
Reseller
• Focus on DNS
Registrant services
Registrant
12
13. Registry Structures
• Registries can define WHERE their customer
administrative data resides (WHOIS)
– Thick – the registry stores all customer data for
registrations regardless of _WHERE_ it originates (direct,
registrar)
– Thin – Registrars manage all customer data for their
registrants and serve this information via WHOIS
TLD
TLD Registrar
WHOIS WHOIS
Registrar
Registrar
Thick Thin
13
14. Registry Structures
• Registries define how subdomains are permitted –
either at the top or second level.
• Top level – delegations fall immediately under the
top level
– E.g. www.google.jo
• Second level – delegations fall under a generic
domain, under the top level
– E.g. www.moict.gov.jo
• Registries can pick one or the other, or do both!
14
15. Policies
• Policies govern how registries operate, from internal
workings to dealing with customers.
• Policies can be derived from operational necessities,
business goals, or best practices in use by other registries
• Policies vary by registry – and vary nearly as widely as the
registries themselves.
• Its important for registries to define policies to respond
and operate in a consistent manner
• Frequently, there is no right or wrong policy – what
matters is the registry’s definition of that policy.
The wrong policy is NO policy…
15
17. Policy
• Registrant Requirements
– This policy defines the requirements to register a
domain with the registry; specifically addresses issues
like residency or ownership
• Things that may restrict registrations to only local or
national entities:
– Desire to limit competition from foreign entities
– Desire for nationalism
• Things that may encourage registration from foreign
entities:
– Access to a larger pool of customers
17
18. Policy
• Dispute Resolution
– A controversial subject; one that is used infrequently, but
must be defined before its needed!
– Disputes may arise between potential registrants for a
domain name – each claiming the “right” to register it,
- or -
- Disputes may arise between current registrant a one that
desires ownership of the domain
• Policy should define the notion of “ownership”, the
process of determining “ownership”, and process for
arbitrating a claim of “ownership”
– First come / first served = “ownership”
– International trademark or copyright = “ownership”
18
19. Policy
• Registration Process
– This policy defines how the registry accepts requests for
registrations, validates, and publishes them
– Usually defined by operational necessity
• Larger registries that process hundreds of registrations per day
will use automated processes as much as possible
• Smaller registries may use manual processes
• Policy should cover registrant data verification
– Automated, multi-factor, out-of-band, etc
– Desire to detect and restrict malicious registrations?
– How should the registry define “malicious”? Tough
Question!
19
20. Policy
• Information Release (WHOIS)
– This policy defines how the registry handles “privacy”
information and what information it publicly publishes
– The traditional approach is to publish administrative and
technical point of contact information for each domain
• BUT, some registries / registrars offer a “anonymous” registration
service which publishes “empty” or generic information
– This may be governed by local, national, or
organizational privacy policies.
• This policy should cover what information can be
published, to who & where, how the policy is
conveyed to registrants, and what to release to law
enforcement or government agencies.
20
21. Policy
• Pricing / Funding Model
– This policy defines how much domain registrations, their
renewal, transfer or other “action” cost.
– Additional or value-added services may also be defined
• This policy should address costs to registrants,
registrars and resellers accordingly and is likely defined
by the registry’s business model.
– Registries set their own prices, from free to $$$$
– Some registries are funded by their governments, some are
non-profits, some are for-profit corporations.
– Competition with gTLDs (e.g. .COM) may drive pricing
decisions
– Prices may be different for local and foreign registrants, for
resellers, and for registrars
21
22. Policy
• Permissible Registrations
– This policy defines what domain names may be
registered
• Factors affecting “permissible” registrations:
– Religion & Culture – some names may be offensive
– Technical – some characters are disallowed by the RFC,
or some may not be allowed by the registry system
– Operational – International Domain Names may not be
supported
– Business – some names may be restricted based on
international trademarks or intellectual property
22
23. Policy
• Takedown
– A very controversial topic, this defines how the registry may
temporarily or permanently deactivate a registration
– More importantly, under what circumstances it may do so.
• Policy should account for:
– Business concerns / loss of revenue
– Upset customers?
– Malicious use (what is malicious?)
– Legality of denying freedom of speech
– Fallout of not following a government / law enforcement
order
23
24. A Hypothetical Example
Let’s take the simple example of a registration made for the
purpose of conducting a phishing attack.
• The domain name closely resembles that used by an
international bank
• The registrant provides fake name and address for
registration
• The registrant uses the domain to propagate a phishing
attack, soliciting bank customers for their usernames and
passwords.
Who’s responsible and who’s accountable?
• The malicious registrant? How do you find him?
• The registry? They didn’t validate the registrant – but they get
5000 a day
• The bank? They didn’t educate their customers on phishing
attacks
24
25. Take Aways
• The DNS operationally is simple; organizationally,
it’s a much different story – there are many (widely
varying) stakeholders involved
• Policies define how registries operate, but are
frequently ill-defined and untested
• Unlike the traditional network security world, which
has CERTs and NOCs focusing on operating systems
and applications, the DNS has no equivalent
structure for focusing on security
25
26. Review
• DNS Organizations
– ICANN, IANA, RIR, IGF, … ABC, XYZ…
• Registry Structures
– 2R vs. 3R
– Thick vs. Thin
– Top vs. Second Level Domains
• Policies
– Registrations, Dispute Resolution, Price, Takedown …
26
