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. > 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 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ 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
