(DNS) consensus wording resolution.

Koen Holtman and Dave Morris have expressed concerns about the
requirement being mandantory (Must vs. should), and proposed an
alternate based on a arbitrary timeout (with no defense as to how
that timeout might be chosen), believing that the implementation
is difficult.

I talked to both Don Eastlake (Mr. DNS security) and Paul Vixie (Mr. Bind),
about the implementation difficulty and the MUST issue.  Don's comment
was that this requirement "should be a MUST".  Paul also believed this should
be a MUST, and that the implementation effort to do a DNS query to
get the TTL was "60 lines of code" (I'm not sure I believe this number,
but it is clearly not a large amount of coding effort, though it may
be more effort in terms of learning about DNS). 

Those who I believe I have data on include:
	MUST		Should
Jim Gettys		Koen Holtman
Paul Leach		Dave Morris
Paul Vixie		Anawat Chankhunthod
Don Eastlake
Maurizio Codogno
Phill Hallam-Baker
Henryk Frystyk

Let me know if I am mis-representing your opinion.

Given that:
	o the current usage of DNS by many web clients is violating
		mandantory parts of the DNS specification,
	o the Web now represents the bulk of the network traffic and DNS lookups,
	o the implementation difficulty does not look too large,
	o the opinions of those most familiar with DNS both agree 
		this should be a MUST,
	o that several people are already implementing code to perform
		this function that will become publically availabile, 
	o clear majority believe this should be a mandantory requirement,
I am proceeding with incorporating the requirement as previously circulated.
			- Jim

====================

Section 14 (new subsection to Security Considerations):

DNS Spoofing
------------

Clients using HTTP rely heavily on the Domain Name Service, and are
thus generally prone to security attacks based on the deliberate
mis-association of IP addresses and DNS names.  The deployment of
DNSSEC[DNSSEC] should help this situation.  In advance of this deployment,
however, clients need to be cautious in assuming the continuing
validity of an IP number/DNS name association.

In particular, HTTP clients should rely on their name resolver for
confirmation of an IP number/DNS name association, rather than caching
the result of previous host name lookups.  Many platforms already can
cache host name lookups locally when appropriate, and they should be
configured to do so.  These lookups should be cached, however, only
when the TTL (Time To Live) information reported by the name server
makes it likely that the cached information will remain useful.

If HTTP clients cache the results of a host name lookups in order to
achieve a performance improvement, they MUST observe the TTL
information reported by DNS.

If HTTP clients do not observe this rule, they could be spoofed when a
previously-accessed server's IP address changes.  As renumbering is
expected to become increasingly common [RFC 1900], the possibility of
this form of attack will grow.  Observing this requirement thus
reduces this potential security vulnerability.

This requirement also improves the load-balancing behavior of clients
for replicated servers using the same DNS name and reduces the
likelihood of a user's experiencing failure in accessing sites which
use that strategy.


Addition to 16. References:
[dnssec]	Whatever is appropriate; it is up for a vote at the IESG this
		month, and may be issued as an RFC in time.
[RFC 1900]
B. Carpenter, Y. Rekhter,
<a href="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1900.txt">
Renumbering Needs Work</a>. RFC 1900, IAB, February 1996.

Received on Monday, 8 April 1996 11:06:24 UTC