Why two lookups for a CNAME?

Steve Arntzen isc at arntzen.us
Thu Oct 22 15:30:43 UTC 2015


I fully agree.


Now, please understand the following question has been asked of me and I fully
realize the implications and that it is just not a good idea.  I will gladly
forward the suggestions to my peers (and bosses).


Is there any way to accept the first response (CNAME with IP) and not perform
the second look up?


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.


As a test, I tried forwarding (and forward only) google.com to Google's public
DNS server.  Although the packets did go directly to 8.8.8.8 as expected, my
Bind server still (for safe verification) performed the second look up.  Note,
the requesting client using dig, sends out one request and receives one reply.
 The test was for "play.google.com".


If anyone has suggestions, please toss them my way.  "Let it work as designed
and deal with it" or similar comments will be graciously accepted.


Thanks again,


Steve.



> 
>     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
> 
>     _______________________________________________
>     Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
>     bind-users mailing list
>     bind-users at lists.isc.org
>     https://lists.isc.org/mailman/listinfo/bind-users
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151022/474bcde9/attachment.html>


More information about the bind-users mailing list