minimal-response, additional-from-...

Mark Andrews Mark_Andrews at
Fri Jul 6 06:39:19 UTC 2007

> On Fri, Jun 22, 2007 at 01:15:23PM +1000, Mark Andrews wrote:
> > 
> > > In article <f5cusf$b9c$1 at>,
> > >  Mark Andrews <Mark_Andrews at> wrote:
> > > > 	The key word above was "referral".  They are not returning
> > > > 	referrals so there is no RFC requirement to return anything
> > > > 	in the additional section.
> > > 
> > > I think the OP is claiming that including the additional section is a 
> > > best practice, not necessarily a requirement.  Is there a good excuse 
> > > why someone might disable this, as they apparently do?
> > 
> > 	It consumes bandwidth.  In many cases it is ignored/rejected
> > 	by the client who just re-queries for it.  It does break
> > 	stub zones but they are not part of the protocol anyway.
> Which config, exactly, "breaks stub zones"?  
> I'm using minimal-response on the few servers I control; one large zone 
> at work is served by a set of AD-integrated MS DNS servers, which at 
> one time numbered 46(!).  Every recursive query to my servers for 
> names in that zone resulted in a TCP retry and the impact was significant.

	The NS query response doesn't return additional data if
	"minimal-response yes;" is set.  Stub zones require the
	additional data (glue) to be sent.

	A stub slave could work around this by querying for the
	address records of nameservers that are at or below the
	stub zone name using the addresses in the masters clause.

	Alternatively priming query exception could be extended to
	all NS queries not just those for the root.  The later would
	be a case of removing the test for the root zone.

2110.   [bug]           "minimal-response yes;" interacted badly with BIND 8
                        priming queries. [RT #16491]

	One could also make minimal-response a per zone option.  In
	that way only the AD zone responses would have "minimal-response
	yes;" applied.

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at

More information about the bind-users mailing list