> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@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
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@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
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 go
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.examp
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 CNAMES
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
>>
>> 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 yo
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
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 client
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
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 perf
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 is returned with
> the CNAME in the first answer?
>
>
> Using dig, I fi
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.examp
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
Makes sense. Better safe than sorry.
Thanks,
Steve.
>
> On October 21, 2015 at 4:01 PM 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
On Wed, 2015-10-21 at 20:42 +, Lightner, Jeff wrote:
> Because the purpose of DNS primarily is to equate a name with an IP as
> applications talk to IPs not to names. When you have a CNAME you’re
> equating one name with another name. That other name then has to be
> looked up so the applic
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
:bind-users-boun...@lists.isc.org] On Behalf Of Steve Arntzen
> Sent: Wednesday, October 21, 2015 4:33 PM
> To: bind-users
> Subject: Why two lookups for a CNAME?
>
>
>
> I'm sure there's a good, simple reason for this, I just can't seem t
it is so you
go the A record route instead.
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Steve Arntzen
Sent: Wednesday, October 21, 2015 4:33 PM
To: bind-users
Subject: Why two lookups for a CNAME?
I'm sure there's a good, simple
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 is returned with
the CNAME in the first answer?
Using dig, I find play.google.com is a CNAME for play.l.google.com.
Whe
20 matches
Mail list logo