Why two lookups for a CNAME?

[Reindl Harald]

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.reindl at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151022/bbcd574f/attachment.bin>