In article <mailman.1319.1342048311.63724.bind-us...@lists.isc.org>, Mark Andrews <ma...@isc.org> wrote:
> In message <barmar-fdfdc6.18551211072...@news.eternal-september.org>, Barry > Margolin writes: > > In article <mailman.1317.1342033147.63724.bind-us...@lists.isc.org>, > > "Michael Hoskins (michoski)" <micho...@cisco.com> wrote: > > > > > while it's largely personal preference -- i generally like to "be > > > conservative in what i send, and liberal in what i accept": > > > > > > http://en.wikipedia.org/wiki/Robustness_principle > > > > 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. Not necessarily. The client may initiate EDNS, but a firewall in front of it could still block the responses. > > > 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. Hence my "primarily" qualifier. > > > 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 https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users -- Barry Margolin Arlington, MA _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
