Subject: Re: [edu-team] DNS tutorial idea for IETF-62

From: Radia Perlman <[email-masked]>
Date: Fri, 21 Jan 2005 06:10:27 -0800

I personally think this would be quite interesting. It really is possible we
should eventually have 2 rooms so if we have a lot of topics it won't be too
long before a particular one is repeated.

Radia

----- Original Message -----
From: Ólafur Guðmundsson <[email-masked]> (by way of Ólafur Guðmundsson <[email-masked]>)
Date: Tuesday, January 18, 2005 6:59 am
Subject: [edu-team] DNS tutorial idea for IETF-62

> Edu-team
> 
> here is a draft outline for a DNS tutorial that
> Peter Koch and myself are proposing for a future IETF please
> advise on how to go forward.
> 
> 	Olafur
> =============================================================================
> 
> This is a draft outline for a tutorial for people who want to specify
> use of DNS and/or add DNS RR types to support their protocol.
> It doesn't cover operational aspects or gory details of e.g. server
> selection algorithms, protocol details or DNSSEC.
> 
> =============================================================================
> Motivation: recently, more and more IETF groups with different 
> backgroundshave been having in their charter or in their self 
> determined solution
> space one or another DNS based approach to data delivery, service 
> location,and so forth. While DNS appears trivial, devil is in the 
> detail and a lack
> of in-depth understanding of concepts and constraints can lead to 
> ineffectivesolutions, pointless discussion and frustration late in 
> the process. This
> is an attempt to offer expertise as a matter of cross-area or 
> cross-wg
> ``fertilization''.
> =============================================================================
> 
> General theory  about the DNS, what it is and what it isn't
> 	-> RFC 3254 Definitions for talking about directories. Harald 
> Alvestrand
> usage example
>    www.foo.example -> A, AAAA
> 	including iterative name resolution process illustrated
> 	multiple severs, redundancy, reliability
> 	caching illustrated: cnn.com's next
> 
> name space 'is' tree (hierarchical)
> hierarchy, replication, caching, loose consistency, TTL's
> 
> labels, '.' as label separator
> 
> DNS != BIND, i.e. just because it works/doesn't work there,
>  doesn't mean you can/should do it; there are lots of
>  implementations
> 
> DNS is quite universal, IP  over DNS has been done, but please do not
>  repeat that
> 
> general DNS functions
>  servers, including root servers
>  resolvers ("recursive servers")
> 
> terminology: primary/secondary, server/resolver
>   RRSet (terminology)
>   how RDATA looks like
>   IPv6:AAAA
> 
>   the root, the '.' and trailing dots, FQDNs
>   domain vs zone
> 
> Design choices: old RR type(s), new RR type
> 
> empty non-terminals	(maybe too advanced)
> 
> wildcards
>   -> wildcard clarification draft
> 
> design criteria (for new record types)
>   Considerations for DNS Resource Records
>     draft-hall-dns-data-04.txt
>   Design Choices When Expanding DNS
>     draft-iab-dns-choices-00.txt
> 
> domain name length considerations
> 
> IDN
> 
> DNS for service location:
>   good: remote service location: SRV, NAPTR, sNAPTR
> 	APIs/libraries for those RRs/methods
>   bad: local service location: 'tree walking',
> 	BCP 17: RFC 2219, Use of DNS Aliases for Network Services
> 	alternatives: DHCP, SLP
> 
> less known/used RR types
>   LOC, ...
>   link to IANA's web page, i.e. RR type registry
> 
> 
> putting stuff in IN-ADDR.ARPA or IP6.ARPA
>   the reverse tree (and IP6 and ENUM...)
>    anything else but PTR in the reverse tree
>   -> general 'reverse' considerations
>   name to something vs something to name
> 
> name space, own TLDs, *.arpa
>   having a particular name within each TLD (-> X42D.XX, RFC 2163)
>   no fuzzy matching, no search
> 
> server load considerations (?)
> 
> size considerations (EDNS vs 512)
> 
> dynamic update - myths, opportunities and threats
> 
> Security considerations
>   DNSSEC is specified and implemented, but not widely deployed
>   you can make DNSSEC a MUST for your own tree, but you cannot
>   assume its general availability
>   But: DNSSEC signatures are not general purpose certificates
>        may be sufficient, though
> 
> Examples and example networks
>   RFC 2606, RFC 3330 "Special-Use IPv4 Addresses"
>    (same for IPv6)
> 
> Summary: How do you make use of the DNS
>   use existing types
> 	sub typing problem
>   if you (think to) have to define your own type ...
> 	sub typing problem
> 	additional section processing - NO, doesn't work
> 	compression - you can't
> 	don't optimize it yourself - KISS {bring it to DNSEXT}
> 
> Bibliography
> 	DNS & BIND, Cricket Liu & Paul Albitz
> 	http://www.dnsnet/dnsrd/
> 	'Ask Mr DNS, Acme Byte & Wire'
> 	[...]
> 
> Warning
> 	"You've seen nothing yet"
> 	There's much more, even things you don't want to know
>          DNS classes
>          name compression in RDATA
> 	
> Who to talk to:
> 	"DNS people may be weird, but they don't bite"
> 	-> DNSEXT
> 	-> DNSOP
> 
> =============================================================================
> 
> 
> 
> _______________________________________________
> edu-team mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/edu-team
>

_______________________________________________
edu-team mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/edu-team