My slides from Wien DNSOP session

[Rob Austein <sra+dnsop@hactrn.net>]

Since there's been a bit of mailing list discussion based on my
presentation yesteday, here are the slides.

%page

Step back a moment

	Discovery is one aspect of autoconfiguration

	What data does a DNS-consuming node need when it boots?

	All DNS consumers need addresses of some name servers
		Usually recursive name servers
		But maybe this is an iterative resolver

	Other things that some DNS consumers might want
		What search path should I use?
		What's my own name?
		How do I publish my name->address data?
		How do I publish my address->name data?
		How do I verify signed DNS data?

	"DNS Discovery" == finding recursive name servers
%page

Security model

	Issues differ greatly depending on:
		Which data one is trying to autoconfigure
		Degree to which one trusts the local network

	Recursive name server addresses ("DNS discovery")
		Issues fairly well understood, we think
		Consumer is at name server's mercy, unless consumer checks sigs
		If consumer does check sigs, it needs:
			DNSSEC policy
			DNSSEC public key(s)
			A clock (may require (S)NTP, more key(s), ...)

	Search path: Danger, Will Robinson
		Controls what questions a node asks

	"What's my name?"
		See "search path", above
		Default kerberos realm too
		Other effects unknown and system dependent, but probably scary
%page

Security model (2)

	"How do I publish my name->address data?"
		Relatively well understood (DNS UPDATE)
		Requires more policy and keying material
		Autoconfig adds no obvious new vulnerabilities

	"How do I publish my address->name data?"
		Superficially similar to name->address, but
		Very weak trust model for address ownership

	"How do I verify signed DNS data?"
		Fairly well understood
		Issues already discussed, above
%page
#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.