W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

(DNS) consensus wording

From: <jg@w3.org>
Date: Fri, 29 Mar 96 16:41:04 -0500
Message-Id: <9603292141.AA22051@zorch.w3.org>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
This sparked no fewer than 16 messages to the mailing list since I posted the
draft on Tuesday.

However, no one argued with the requirement itself; all comments appeared
to be related to the implementation of the requirement rather than the
requirement itself.  There wasn't even any comment on the wording.

So I believe consensus on this issue exists, but I am less confident
about the wording, as the discussion devolved into a discussion
of the implementation effort required.

Please let me know if you believe consensus for this requirement does not
exist, and please let me know if you believe there is better wording possible.
				- Jim Gettys

P.S.  Note that the discussion indicates that many people would like a better
(portable) DNS resolver library than exists today.  Might I suggest that
people get together and implement it?  It did not sound like a tremendous
amount of work, but long overdue.


Proposed wording:
====================

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.

------- End of Forwarded Message
Received on Friday, 29 March 1996 13:49:59 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:49 EDT