[Pdns-users] pdns-recursor issue with resolving domains which placed on ns*.domaincontrol.com name servers

[Maksym Pidlisnyi]

dig and other applications make two requests. first request doesn't have
any responses. Can pdns-recursor  do that?

On Tue, Feb 21, 2017 at 3:24 PM, Maksym Pidlisnyi <cryptspirit at gmail.com>
wrote:

> sure I did that
>
> in full trace:
> Feb 21 12:08:23 ip-172 pdns_recursor[3162]: [1] customersdomain.com.:
> Trying IP 216.69.185.24:53, asking 'customersdomain.com.|A'
> Feb 21 12:08:24 ip-172 pdns_recursor[3162]: [1] customersdomain.com.:
> timeout resolving
> Feb 21 12:08:24 ip-172 pdns_recursor[3162]: [1] customersdomain.com.:
> Failed to resolve via any of the 2 offered NS at level '
> customersdomain.com.'
> Feb 21 12:08:24 ip-172 pdns_recursor[3162]: [1] customersdomain.com.:
> failed (res=-1)
> Feb 21 12:08:24 ip-172 pdns_recursor[3162]: 0 [1] answer to question
> 'customersdomain.com.|A': 0 answers, 0 additional, took 4 packets, 0
> throttled, 2 timeouts, 0 tcp connections, rcode=2
>
> tcpdump has only requests from pdns to ns*.domaincontrol.com name
> servers. there were not any responses
> why dig works but pdns doesn't? o_0
>
> I can't increase query timeout for 3.3 version
>
> On Tue, Feb 21, 2017 at 1:13 AM, David <opendak at shaw.ca> wrote:
>
>> On 2017-02-20 2:00 PM, Максим Подлесный wrote:
>>
>>>
>>> In the log we had only:
>>> Sending SERVFAIL to 127.0.0.1 during resolve of '9p.com
>>> <http://9p.com>.' because: Too much time waiting for 9p.com.|A,
>>> timeouts: 1, throttles: 0, queries: 4, 6497msec
>>>
>>> dig works fine but slow (about 5-6 sec for this domains)
>>>
>>>
>> You may want to check a full trace to that example from your site and see
>> all the timeouts, and/or tcpdump to prove it to yourself.
>>
>> They may also be rate limiting you if one of your clients is relaying a
>> random subdomain attack against one of these domains.
>>
>> You'd need to increase two timeouts if you wanted to avoid this (the
>> per-NS 1500ms one and the overall 7000ms query timeout). Most clients will
>> give up after that long though, but hopefully a cache hit on the next try.
>>
>>
>> _______________________________________________
>> Pdns-users mailing list
>> Pdns-users at mailman.powerdns.com
>> https://mailman.powerdns.com/mailman/listinfo/pdns-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20170222/02e41ae1/attachment.html>