> On Aug 8, 2017, at 1:23 AM, Remi Gacogne wrote:
>
> On 08/03/2017 11:05 PM, Shawn Zhou wrote:
>>> Yes, you are right, this is known behavior in 4.0.x, we don't use
>>> subnet-specific entries as soon as we get an entry usable for all subnets.
>>
>> Will 4.0.x be updated to address the problem
On 08/03/2017 11:05 PM, Shawn Zhou wrote:
>> Yes, you are right, this is known behavior in 4.0.x, we don't use
>> subnet-specific entries as soon as we get an entry usable for all subnets.
>
> Will 4.0.x be updated to address the problem?
I'm not sure we should, to be honest. We could make sure th
Hello Shawn,
root@DFW01-CPS01:~# dig @localhost +subnet=52.57.28.138 morpheus-ien.insnw.net
local-address=127.0.0.1
dig asks ::1 if available!
Try
dig @127.0.0.1
or
local-address=127.0.0.1,::1
--
Winfried
___
Pdns-users mailing list
Pdns-user
> On Aug 3, 2017, at 1:23 PM, Remi Gacogne wrote:
>
> On 08/03/2017 07:38 PM, Shawn Zhou wrote:
>> Your explanation makes sense but that still doesn't explain the original
>> problems I see with pdns. see [1]. When pdns received the response for
>> the 1st query, it should have a cache entry for
On 08/03/2017 07:38 PM, Shawn Zhou wrote:
> Your explanation makes sense but that still doesn't explain the original
> problems I see with pdns. see [1]. When pdns received the response for
> the 1st query, it should have a cache entry for scope prefix-length of
> 16 (btw, why don't I have that inf
Your explanation makes sense but that still doesn't explain the original
problems I see with pdns. see [1]. When pdns received the response for the 1st
query, it should have a cache entry for scope prefix-length of 16 (btw, why
don't I have that information when I dig against pdns?). When the 2n
On 08/03/2017 12:04 AM, Shawn Zhou wrote:
> I don't think that's the right behavior. If Client Subnet scope set to
> 0, resolver should not cache it.
> unbound DNS gives me the expected output as it cache has different
> entries for different client subnet. Why is pdns recursor's
> implementation d
I don't think that's the right behavior. If Client Subnet scope set to 0,
resolver should not cache it.unbound DNS gives me the expected output as it
cache has different entries for different client subnet. Why is pdns recursor's
implementation different?
root@DFW01-CPS02:~# dig @localhost +subn
Hi Shawn,
On 08/02/2017 08:47 AM, Shawn Zhou wrote:
> Sorry. I meant the authoritative nameserver did respond with the correct
> answer.
The authoritative server answers with a EDNS Client Subnet scope set to
0 when we send a query with a source set to 127.0.0.1/32, meaning that
we can cache th
Sorry. I meant the authoritative nameserver did respond with the correct
answer.
Sent from my iPhone
> On Aug 1, 2017, at 11:21 PM, bert hubert wrote:
>
>> On Wed, Aug 02, 2017 at 05:52:26AM +, Shawn Zhou wrote:
>> Hi,
>> I am trying out pdns recursor 4.0.6 on Ubuntu Xenial and cache look
Hi Bert,
Thanks for your quick response. 4.1 didn't work and I already set
use-incoming-edns-subnet but I was getting timeouts. From what I could see from
my tcpdump, the authoritative server didn't return the correct answerÂ
root@DFW01-CPS01:~# service pdns-recursor restart
* Restarting PowerDN
On Wed, Aug 02, 2017 at 05:52:26AM +, Shawn Zhou wrote:
> Hi,
> I am trying out pdns recursor 4.0.6 on Ubuntu Xenial and cache lookup for
> same record with and without client subnet give me the same result which is
> not expected. I expect [3] to return a different value as the cache should
Hi,
I am trying out pdns recursor 4.0.6 on Ubuntu Xenial and cache lookup for same
record with and without client subnet give me the same result which is not
expected. I expect [3] to return a different value as the cache should have
different value based on client subnet. I wonder if that's bug
13 matches
Mail list logo
