Look Out Network here come the applications

1
Look Out Network here come the applications

• Leslie L. Daigle
• VeriSign, Inc.
• APRICOT 2002

2
Current realities of networking

• NATworks -- address translation
• private networks gatewaying onto public network
• firewalls firewall avoidance
• Anycasting, closest server
• Load distribution server farms
• Its not about simple hosts in a global address
  space anymore

3
Current Trends in Application Layer Naming

• Identifying service location
• tied into the application protocol standard
  e.g., SIP addresses
• Uniform resource names URNs
• A layer above DNS?

4
SIP address/names

• Session Initiation Protocol for setting up
  media sessions (e.g., VoIP)
• draft-ietf-sip-rfc2543bis-07.txt
• An example of the current mode of service naming
• Identifiers use _at_ format
• sipme_at_example.com
• SIP server location uses NAPTR and SRV DNS
  records for indirection
• draft-ietf-sip-srv-04.txt
• look up NAPTR, then SRV, then A record for given
  server

5
SIP Resolution Example sipme_at_example.com

• example.com.
• order pref flags service regexp
  replacement
• IN NAPTR 90 50 "s" "SIPD2T" ""
  _sip._tcp.bigisp.com.
• IN NAPTR 100 40 "s" "SIPD2U" ""
  _sip._udp.bigisp.com.
• IN NAPTR 100 50 "s" "SIPD2U" ""
  _sip._udp.example.com.
• IN NAPTR 110 50 "s" "SIPD2S" ""
  tls-sip.example.com.
• _sip._tcp.bigisp.com.
• Pref Weight Port Target
• IN SRV 0 0 1000 bigiron.bigisp.com.
• IN SRV 0 0 1000 bigiron.bigisp.com.au.
• IN SRV 0 0 1000 bigiron.bigisp.com.uk.

6
Notes

• s flag in NAPTR means look up SRV record next
• the SIPD2U service has 2 entries a preferred
  service, and a backup (higher pref number)
• the example assumes were interested in the
  SIPD2T service SIP protocol, tcp transport.
  Therefore, _sip._tcp.bigisp.coms SRV records are
  looked up
• all the SRV records have the same PREF and WEIGHT
  can guess from the TLD which might be closest.

7
Discussion of SIP address/names

• Allows large-granularity load-balancing (e.g.,
  different servers across world)
• Enables distinction between label of domain of
  administration of the address (example.com) and
  the domain actually hosting the service
• Almost like e-mail addresses
• neednt correspond to mail box addresses
• same character restrictions
• Can thinkingcat.com (a very small enterprise) get
  NAPTR and SRV records hosted at a generic ISP?
• Still tied to a specific domain

8
An Issue with SRV

• Can only have one service operating per
  name/service id and hostname
• For example
• _ldap._tcp.thinkingcat.com
• Pref Weight Port Target
• IN SRV 0 0 1000 bigiron.bigisp.com.
• IN SRV 0 0 1000 bigiron.bigisp.com.au.
• IN SRV 0 0 1000 bigiron.bigisp.com.uk.
• All must be equivalent LDAP servers
• Would need whitepages.thinkingcat.com and
  certs.thinkingcat.com to reference different
  services

9
URNs

• Purpose naming of (published) resources
  location-independent identifiers
• I.e., dont want to have network identifiers,
  such as domain names, in the URN
• Created the NAPTR RRs and concept, now being used
  elsewhere (e.g., SIP)
• E.g.,
• urnietfrfc2141
• namespace identifier ietf
• namespace-specific string rfc2141
• defined in RFC2648

10
URN Resolution Example urnietfrfc2141 part 1

• ietf.urn.arpa.
• order pref flags service regexp
  replacement
• IN NAPTR 100 10 "" "I2LI2R" ""
  naptr.ietf.org.
• naptr.ietf.org.
• order pref flags service regexp
  replacement
• IN NAPTR 100 10 "" "I2LI2R" "
  !urnietf()(.)!\1.naptr.ietf.org!i" .

11
Notes

• the flag field is empty means that were still
  looking up NAPTR records for the target
• the first lookup, ietf.urn.arpa, is composed of
  .urn.arpa
• it simply redirects to naptr.ietf.org (minimal
  burden on the very top node)
• the naptr.ietf.org regular expression pulls rfc
  out of the URN and makes the new target
  rfc.naptr.ietf.org. This allows different
  servers to handle different parts of the ietf
  namespace
• note that the regular expression applies to the
  whole original URN never the outcome of the
  previous replacement or rewrite.

12
URN Resolution Example urnietfrfc2141 part
2

• rfc.naptr.ietf.org.
• order pref flags service regexp
  replacement
• IN NAPTR 100 10 s thttpI2L
  idx.ietf.org.
• IN NAPTR 100 20 s thttpI2R
  pub.ietf.org.
• pub.ietf.org.
• Pref Weight Port Target
• IN SRV 0 0 2621 bigiron.ietf.org.
• IN SRV 0 0 2621 bigiron.bigisp.com.au.
• IN SRV 0 0 2621 bigiron.bigisp.com.uk.

13
Notes

• the I2L (URI to URL) service and the I2R (URI
  to Resource) service are handled by different
  services
• the example assumes we are interested in the I2R
  service, and the appropriate SRV records are
  shown.

14
URN Resolution Example urnietfrfc2141 A
closer look

• urn.arpa is the top of the tree
• maintained by IANA
• Immediately hands off to the namespace managers
  domain naptr.ietf.org
• Namespace manager delegates based on the first
  component of the namespace specific string rfc
• !urnietf()(.)!\1.naptr.ietf.org!i"
• Others are FYI, BCP, ID, MTG
• The idea is that different parts of the namespace
  may be delegated to different managers

15
Discussion of URNs

• Very powerful tool
• identifier strings are structured to suit the
  resources, not the layout of network domains
• can delegate control of portions of the namespace
• delegation structure can change over time without
  changing the URNs
• Can be very complex
• regular expressions
• naming does get tied to domains in the NAPTR and
  SRV records (needs coordination between namespace
  and DNS administrators)

16
Discussion of URNs continued

• Doesnt allow simple DNS queries must follow
  chain from urn.arpa
• Is designed to fit with DNS caching strategies

17
A New Layer Above DNS?

• A new proposal
• Idea defined in draft-klensin-dns-search-02.txt
• Straw proposal in draft-mealling-sls-01.txt
• A non-DNS based registry of names, including
  information facets
• language
• geographical location
• network location
• industry category code
• Straw proposal is Service Lookup System (SLS)

18
Example SLS McDonalds

• http//sls.bar.com/
• 
  McDonalds
• foo.com234364
• http//acme.example.com/mcdonald/
• 
  A purveyor of fine
  examples type"rfc1766"en-uk name"location" type"sls"gb-ham
  web
  380023erty

19
Notes

• the straw proposal is XML-based
• indicates the SLS server that provided
  this response
• more than just a URI is returned information
  about language, location, business category (to
  allow selection between multiple uses of
  McDonalds
• nice is the set of business categories being
  used (Nice Agreement).
• the URI associated with this McDonalds is
  http//acme.example.com/mcdonald
• note that has nothing to do with domain names

20
SLS Discussion

• Names are not required to be unique
• No single registry or root
• Not restricted to DNS characters or naming
  conventions
• Fuzzy matching
• Specifically meant to identify real world
  services (without having to use network object
  names)
• Maps names to URIs
• Requires simplicity and a global standard
  interoperability is a Good Thing.

21
Conclusions What is too much to put in the DNS?

• DNS was built to translate machine names to
  addresses network objects.
• When the administrative control of some naming
  system doesnt correspond to the domain, things
  evolve at cross-purposes
• document (resource) names
• person identifiers
• personal keys
• When you have to come up with clever naming
  mnemonics to work around the DNS structure (SRV
  issue)

22
Other References

• NAPTR/DDDS documents
• draft-ietf-urn-ddds-toc-01.txt and referenced
  documents
• SRV DNS RR
• RFC2782
• URN namespace registry
• http//www.iana.org/assignments/urn-namespaces