Re: repeating records

[Mark.Andrews@isc.org]

> BIND company employee Andreas Gustafsson writes:
> > D. J. Bernstein writes:
> > > Yes or no: Are you claiming that every DNS implementor, before choosing
> > > to use (for example) BIND 8's strategy of sending glue whenever it's
> > > referenced, _must_ understand and carefully weigh the implications?
> > Yes.
> 
> Let me get this straight. Because the BIND 4/8 strategy (for the sake of
> server simplicity) generates slightly more traffic (for some zones), you
> conclude that every DNS implementor _must_ understand and carefully
> weigh the implications before choosing that strategy?

	Yes.  The world is changing and zones are getting MUCH bigger.

	Part of the response to that was to support sending multiple
	records in one message so that the transfer could take
	advantage of DNS label compression.  The second response
	was to eliminate the duplicate records.
 
> After many years of BIND 4/8 working just fine without anybody worrying
> about this, why did this suddenly become an issue? Maybe the .com
> administrators care, but how does that justify demanding that _every_
> implementor worry about this? Are you sure that you aren't wildly
> exaggerating the importance of an absurdly small issue?

	Where do you think the large zone operators get there servers
	from?  They normally don't roll their own.  Large zones are
	just one thing a implementor must think of when designing
	a nameserver.

	Transmission times have been a problem in the past.  They
	currently arn't but DNSSEC is just around the corner and
	with DNSSEC comes a large increase in the volume of data
	that has to be transmitted.
 
	Also as a implementor it is not normally your bandwith (money)
	that is being wasted.

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

	Yes. The choice of database backend is important.
	Yes. The choice involved in EDNS are important.
 
> If the last two answers are no: What, precisely, is the relevant
> difference between these situations and the repeated-glue situation?
> Don't you agree that these things generate more traffic? A moment ago
> you said how important it was for all implementors to pay attention to
> efficiency issues; are you retreating from that principle?
> 
> How would you like it if other people tried to force you to imitate
> their implementation decisions by declaring that implementations SHOULD
> make those decisions---never mind actual costs and benefits?

	No one is forcing you to send each record once.  Just to
	make sure you think about it carefully before you decided
	to send a record multiple times.
 
> > > If people really are misusing ``SHOULD'' for minor efficiency issues
> > > (misinterpreting ``harm'' in section 6 of RFC 2119), we're going to need
> > > a new word to point out real dangers such as over-eager retransmission.
> > We already have one.  It's called MUST.
> 
> I'm cc'ing this to Bradner. RFC 2119 is obviously meant to stop people
> from pretending that every implementation decision is a protocol issue;
> it is not succeeding at this goal.

	It's not a minor issue to some zone operators.  It has in
	the past come close to causing the DNS to fail for a large
	portions of the net.
 
	Mark

> ---D. J. Bernstein, Associate Professor, Department of Mathematics,
> Statistics, and Computer Science, University of Illinois at Chicago
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

--
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/>