Am 22.10.2015 um 17:30 schrieb Steve Arntzen:
The reason is, when our Bind server is communicating over a satellite link with a 600 ms round trip time per transaction, the delay becomes noticeable (>1.2 seconds for a single CNAME resolution). Add to that, some of the CNAMES have short TTLs, so this happens periodically.
since in a normal environment that don't matter consider in case of a caching-only nameserver in such an environment using unbound instead of named because it supports "cache-min-ttl" which is also strongly recommended on a inbound mailserver using RBL's
cache-min-ttl: 600 cache-max-ttl: 10800 P.S.: please don't top-post with full-quotes (TOFU)
On October 22, 2015 at 7:07 AM Reindl Harald <h.rei...@thelounge.net> wrote: Am 22.10.2015 um 14:01 schrieb Matus UHLAR - fantomas: > On 22.10.15 08:01, Mark Andrews wrote: >> To prevent cache poisoning via cnames. It it simpler to always >> lookup the target of the cname that to figure out if we would >> accepted the following data. >> >> server A has zones foo.example and bar.example configured >> server B has zone bar.example configured >> >> bar.example is only delegated to server B of the two server above. >> >> The is a cname from www.foo.example -> www.bar.example >> >> Server A return a complete answer but the www.bar.example data is >> from the wrong zone instance. This happens accidentally in real >> life. > > I wonder if it's not enough to verify that the first response was received > from proper server. > > Since play.l.google.com is a subdomain of play.google.com, the lookup would > go throuth google.com nameservers again... > > when servers for bar.example are the same as servers for foo.example, the > already accepted answer for foo.example is expected to contain valid answer > for bar.example too... well, it's better to keep things simple and whenever possible working the same way instead premature optimization and different behavior to keep them clear and maintainable at the end it does not matter most DNS results are coming from caches and if they are not in the cache they are not frequent enough that it would matter
-- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development m: +43 (676) 40 221 40, p: +43 (1) 595 3999 33 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
