[ga-abuse] Strong Moderation

["Patrick Corliss" <patrick@corliss.net>]

Here's an typical example of a posting from a strongly moderated list.

----- Original Message ----- 
From: D. J. Bernstein <djb@cr.yp.to>
To: <ipng@sunroof.eng.sun.com>
Cc: <namedroppers@ops.ietf.org>
Sent: Wednesday, May 02, 2001 12:53 PM
Subject: Re: AAAA/A6 thing


RFC 1034 does not correctly describe the behavior of real DNS caches,
such as BIND and dnscache. In particular:

   * The RFC 1034 resolution algorithm loops and eventually fails when
     glue A records expire before NS records. Real caches fall back to
     the roots and succeed.

   * The RFC 1034 resolution algorithm saves information from servers
     that are not authorized to provide the information. Real caches
     reject the unauthorized information.

Yes, these are differences between RFC 1034 and reality. RFC 1034 is
clearly wrong in both cases: it creates a reliability problem in the
first case and a security problem in the second case.

http://cr.yp.to/djbdns/notes.html explains these issues in detail. The
section on gluelessness includes the same type of example that Ohta is
talking about now, with servers that follow the RFC 1034 rules but that
can't be reached by DNS caches:

   espn.tv NS ns-1.disney.corp
   espn.tv NS ns-2.disney.corp

   disney.corp NS zone.espn.tv
   disney.corp NS night.espn.tv

Ohta is wrong when he blames the DNS cache for throwing away the glue
here. RFC 1034 _does not_ require glue in this situation. The espn.tv
servers don't know the ns-1.disney.corp address.

http://cr.yp.to/djbdns/killa6.html explains why A6 and DNAME will make
these failures much more common.

---Dan


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.