Why two lookups for a CNAME?

[Reindl Harald]

Am 23.10.2015 um 10:21 schrieb Matus UHLAR - fantomas:
>> Am 22.10.2015 um 14:01 schrieb Matus UHLAR - fantomas:
>>> 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...
>
> On 22.10.15 14:07, Reindl Harald wrote:
>> 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
>
> I don't see what's premature on keeping invalidated responses pending in
> cache for further validation ... I believe this is very common at many
> of DNS hosting providers that will
> return not just the answer but also the glue records so there's in fact no
> need to check for them once you make sure the NS is correct so we can spare
> us some RTTs.

i guess the opposite: large DNS hosting providers likely use 
"minimal-responses yes;" which saves here around 20% of DNS traffic, 
google nameservers do the same

> (of course DNSSEC validation will still be done, but also optimized).
>
>> 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
>
> it doesn't matter so much that nobody even asked for it on BIND mailing
> list because of noticing it...

just because someone is asking a *question* doe snot change anything in 
matters or matters not by itself

-------------- 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/20151023/7503bcbe/attachment.bin>