Why two lookups for a CNAME?

[Woodworth, John R]

From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of 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.





Steve, I know you have stated the "prefetch" feature may suit your needs

but would it be possible to put another resolver on the other side of the

link?  I understand it is not a zero-cost solution but it would level out

uncached queries from the other side of the link while inside would

still benefit from a local cache.  This is just an off-the-cuff idea and

I have not worked through all the little details but thought I would

share.  I am also interested in how prefetch works for you.





Thanks,

John



>

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

>

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20151023/c5c1a6bb/attachment.html>