Survey - how many people running ISP nameservers define "minimal-responses" - was Re: What is the deal on missing "Authority Section" and "additional section" from google's DNS servers?

Mark Andrews marka at
Wed Jul 11 23:11:30 UTC 2012

In message <barmar-FDFDC6.18551211072012 at>, Barry Margolin writes:
> In article <mailman.1317.1342033147.63724.bind-users at>,
>  "Michael Hoskins (michoski)" <michoski at> wrote:
> > while it's largely personal preference -- i generally like to "be
> > conservative in what i send, and liberal in what i accept":
> > 
> >
> This doesn't refer to quantity, but to how strictly you should adhere to 
> the specification.
> > it's not violating RFCs to send the full data so it's not technically
> > "wrong".  however, if sending back too much data is known to cause
> > problems in some cases and can potentially be used against you...then it
> > seems wise to take the minimal path.
> As long as you stay under the traditional 500 byte limit, I think you're 
> being conservative enough.  "Liberal" would be depending on EDNS0 
> extensions.

EDNS is initiated by the client so there is no issue here.
> However, I think it's reasonable to adhere to the following policy:
> Caching nameserver: minimal-responses yes.  The clients of these are 
> primarily stub resolvers, which probably won't cache the additional 
> data, so it's a waste of bandwidth and could potentially cause problems.

Except for MTA's which know to look for A/AAAA records in the
additional section.  There is no cache poisioning issue with stub
resolvers as they will be talking to the same recursive servers.

> Authoritative nameserver: minimal-responses no.  The clients are almost 
> all caching nameservers, and they'll cache what they can.
> -- 
> Barry Margolin
> Arlington, MA
> _______________________________________________
> Please visit to unsubscribe from this list
> bind-users mailing list
> bind-users at
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at

More information about the bind-users mailing list