Re: Why two lookups for a CNAME?

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

Re: Why two lookups for a CNAME?

In message <1401468033.15948.1445459552099.javamail.vpopm...@atl4oxapp02pod1.mg t.hosting.qts.netsol.com>, Steve Arntzen writes: Why does named perform a lookup for the A record when its IP is returned with the CNAME in the first answer? On 22.10.15 08:01, Mark Andrews wrote: To prevent cache

Re: Why two lookups for a CNAME?

In article , Steve Arntzen wrote: > I'm sure there's a good, simple reason for this, I just can't seem to find > the > answer searching on the Internet. > > > Why does named perform a lookup for the A record when its IP

RE: bind-users Digest, Vol 2230, Issue 1

> > From: Harshith Mulky [mailto:harshith.mu...@outlook.com] > > Hello John, > > > 1.) Are these devices some type of VoIP device? I've seen many novel DNS > > based scenarios used for VoIP before. > [Harshith] yes, they are VOIP devices which use "lwresd" to talk to > external DNS Servers >

fetches-per-zone

I've been testing fetches-per-zone and have a couple of questions: What is a good starting point for fetches-per-zone? I started with 200 but have no real evidence to say the number is low or high. On a server which peaks at 1200 queries per second during the day I have only 61 spilled due to

Re: Why two lookups for a CNAME?

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,

Re: Why two lookups for a CNAME?

Am 22.10.2015 um 17:41 schrieb Phil Mayers: On 22/10/15 16:37, Reindl Harald wrote: 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

Re: Why two lookups for a CNAME?

>> >> Using dig, I find play.google.com is a CNAME for play.l.google.com. >> >> >> When asked to resolve it, named will first look for play.google.com. The >> result >> will include the CNAME and the IP of the A record. >> >> >> Named then makes a second request to resolve the A record. > > Are

Re: Why two lookups for a CNAME?

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

Re: Why two lookups for a CNAME?

On 22/10/15 16:30, Steve Arntzen wrote: 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

Re: Why two lookups for a CNAME?

On 22/10/15 16:37, Reindl Harald wrote: 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

Re: Why two lookups for a CNAME?

Thank you all for the suggestions. Prefetch sounds like a good solution and still provides the designed behavior for integrity. I see Bind 9.10 introduces “prefetch” and I will look into it. Until we change or upgrade, a simple solution may be our own prefetch (periodic lookup) of popular