(DNS) draft wording for W.G. review.

JG DNS
        Issue: 
	<A href="http://www.w3.org/pub/WWW/Protocols/HTTP/Issues/dns-usage.txt">
	spec is silent about 
        clients/servers caching of DNS information.</A>
        <BR>
        Status: resolution is to add verbiage that implemeters who cache
        DNS information inside an implementation, rather than using DNS
        lookups each time MUST obey DNS TTL rules.  Add words as well
        to security considerations.


I've written a section outlining this requirement; it is currently
a sub-section to be added to the security considerations section,
as there seems to be no general discussion of how servers are contacted
elsewhere in the document.  If people think it necessary, I can
add such a section to the document, but this seems the easiest way to 
close the issue.
				- Jim Gettys


Proposed resolution:
====================

Section 14 (new subsection to Security Considerations):

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

HTTP use relies heavily on the Internet's name service (DNS), and is prone to
the attacks generally possible via name server attack.
DNSSEC deployment should improve this situation.

The current implementation of many HTTP 1.0 client libraries are prone
to a particular attack, however.

HTTP clients should generally rely on their system's name resolver for
lookup when contacting a server, rather than caching the result of host 
name lookups.  Many platforms already cache the results of name
lookups locally, or can (and should) be configured to do so.

If clients cache the results of name lookups for performance
reasons, HTTP clients MUST observe the TTL (Time To Live) information 
reported by the name server.

A server could be spoofed when that server's IP address 
changes if this rule is not observed.  As renumbering is 
expected to become increasingly common [RFC 1900], 
this problem will grow.  This requirement reduces this
potential security vulnerability.

This requirement also reduces failures observed by users,
and improves load-balancing behavior of clients for replicated servers
hiding behind the same DNS name, as often occurs with large loaded 
HTTP servers.

Section 16: (References)

[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.
Section 16: (References)

[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 Tuesday, 26 March 1996 09:18:09 UTC