15 Říj
2020
15 Říj
'20
12:12
On 15. 10. 20 12:02, Petr Špaček wrote:
On 15. 10. 20 11:51, Balakrishnan Balasubramanian
wrote:
I'm sorry, I misread attachement in your previous e-mail. You are right, AAAA query
should not fail. Given that it works fine from our test server debug.knot-resolver.cz
linked above I guess it is a local problem.
If you want to dig deeper please provide full verbose log with policy.DEBUG_ALWAYS
enabled. (This policy enables extra extra verbose logging.)
Petr Špaček @ CZ.NIC
Thanks for checking! For some domains,
'A' record works fine but AAAA record
crashes. May be it has do with some ipv6 issue in my router.
As far as I can tell from verbose log here
https://debug.knot-resolver.cz/query.py?qname=mail.smtp2go.com&qtype=AA…
this domain does not have AAAA records so the answer seems to be correct. Is there a way to enable a backup resolver only
for failed queries? I can see
policy.FORWARD and policy.TLS_FORWARD functions. But I think they forward all
queries, not just the failed ones.
You are right, policy.FORWARD* policies are unconditional. Currently Knot Resolver does
not have this Frankenstein-style feature to combine direct queries with forwarding for a
single request.
Also is there a way to get all the direct dns
queries (excluding name server
ones) without turning on full verbose logging?
I'm not sure what you mean. Maybe
https://knot-resolver.readthedocs.io/en/v5.1.3/modules-policy.html#policy.D…
could help?
Petr Špaček @ CZ.NIC
>
> Thanks,
> Bala
>
> On Thursday, October 15, 2020 3:06:02 AM EDT Vladimír Čunát wrote:
>> On 10/14/20 8:48 PM, Balakrishnan Balasubramanian wrote:
>>> Thanks! Got verbose logging. But not sure what is the issue. Attaching
>>> logs.
>> I'm not sure either. It looks like kresd is doing nothing wrong. The
>> two servers in **.ns.els-gms.att.net. don't appear to reply over UDP at
>> all and send garbage over TCP. When I query the same IP addresses from
>> here they reply OK(-ish) and apparently also from other places (like
>> from other public resolvers or dnsviz.net).
>>
>> It's possible that something in your network is interfering with the
>> queries. Overall I suspect the cause will be hard to track down.
>>
>> --Vladimir