On Thu, Oct 23, 2008 at 4:41 PM, Brian E Carpenter
<[EMAIL PROTECTED]> wrote:
> Ran and I drafted this in reaction to the earlier discussion here
> about the impracticality of renumbering. We'd like comments and, above
> all, contributions. For now, this list is suggested for any discussion,
> but I will also mention the draft on the intarea list.
>
> http://www.ietf.org/internet-drafts/draft-carpenter-renum-needs-work-00.txt


Brian,

You missed the more fundamental DNS problem:

95% of the software which interacts with the DNS does so via the
gethostbyname call. Gethostbyname does not return the TTL for the
information, thus the applications which use it do not conceive of a
hostname whose address changes during the course of the application's
operation.

Even if you were to deprecate and eventually eliminate the
gethostbyname call, painless renumbering is prevented by the rest of
the API which expects the layer-7 application to interact with the
layer-3 address. Because the application works right 99.9% of the time
(when IP addresses aren't changing) few small-time applications have
or will implement the TTL logic.

Some very large systems get it wrong too. One obvious example: Windows
XP and Windows Vista cache DNS query results for 15 minutes regardless
of the TTL reported by the DNS resolver. Windows 98 cached DNS query
results for 24 hours or until the next reboot.
(http://support.microsoft.com/default.aspx?scid=KB;en-us;263558).
Before you think to blame  all our woes on Microsoft: In Solaris 8 and
earlier, nscd also ignores the DNS TTL, passing already-stale records
back to apps which call gethostbyname.

Anecdotal reports from web server administrators suggest that a
hostname-based requests for web sites continue to trickle in at the
old IP address for months after the server address has changed in the
DNS.

Bottom line: because the APIs call for the applications to interact
with the layer-3 addresses directly instead of interacting with only
hostname targets, painless renumbering is an unattainable goal.


You also need a heading: SMTP issues.

Nearly all of the trust-management systems (aka anti-spam systems) for
email derive from the server IP address. It tends to go haywire when
the address of any large originator of email changes, already a source
of much pain and consternation for system administrators.

Regards,
Bill Herrin


-- 
William D. Herrin ................ [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
_______________________________________________
rrg mailing list
[email protected]
https://www.irtf.org/mailman/listinfo/rrg

Reply via email to