Re: repeating records

["D. J. Bernstein" <djb@cr.yp.to>]

Andrews claims that every DNS implementor _must_ understand and
carefully weigh the implications---specifically, a minor traffic
increase for some zones---before using BIND 8's AXFR glue strategy.
(``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy.'')

The following analogies show how silly Andrews's argument is:

   * ``DNS servers SHOULD NOT use BIND 8's AXFR glue strategy'' because
     another strategy sometimes generates less traffic.

   * ``DNS servers SHOULD NOT use EDNS0'' because the opposite choice
     usually generates less traffic.

   * ``DNS servers SHOULD NOT use AXFR'' because rsync practically
     always generates less traffic.

   * ``DNS servers SHOULD use bzip2-compressed zone transfers instead of
     gzip-compressed zone transfers'' because bzip2 usually generates
     less traffic than gzip.

   * ``DNS servers SHOULD use gzip-compressed zone transfers instead of
     bzip2-compressed zone transfers'' because gzip usually takes less
     CPU time than bzip2.

   * ``DNS servers SHOULD NOT serve records from an LDAP database''
     because LDAP can be slow.

I could go on like this for a while. Is there anyone other than Andrews
who still doesn't understand why this is a misuse of ``SHOULD NOT''?

In a previous message, I specifically asked Andrews about some of these
examples:

   Do you also conclude that ... every DNS implementor _must_ understand
   and carefully weigh the implications before attempting to use EDNS0?
   (``DNS servers SHOULD NOT use EDNS0.'')

His answer: ``Yes. The choice involved in EDNS are important.'' That's a
clear, direct, specific endorsement of ``DNS servers SHOULD NOT use
EDNS0''---but Andrews now claims that he never said that! Flip, flop,
flip, flop.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>