[dnsdist] Recursion to wrong server?!
Djerk Geurts
djerk at maizymoo.com
Tue Sep 12 15:21:20 UTC 2023
Ah! I hadn’t considered that, time to look at changing the request as for internal lookups recursion may not work for that record.
—
Thanks,
Djerk Geurts
> On 12 Sep 2023, at 15:50, Chen, Christof <christof at chen.de> wrote:
>
> Isn't that just the default health check for your defined pool servers?
>
> BR Christof Chen
>
> Djerk Geurts via dnsdist <dnsdist at mailman.powerdns.com <mailto:dnsdist at mailman.powerdns.com>> schrieb am Di., 12. Sept. 2023, 16:44:
>> Hi all,
>>
>> While doing a tcpdump of DNS traffic to determine if also-notify was working I noticed root queries being received by an internal authoritative server that I wasn’t expecting. And according to the DNSdist configuration I don’t think I should be seeing these either. So I think I need some help making sense of it all.
>>
>> I run FreeIPA as authoritative for zones of internal (sub.)domains. There are two PowerDNS recursors fronted by two DNSdist machines. The desired logic is as follows:
>>
>> Both DNSdist servers forward all requests to the primary PowerDNS server. For now ignore I have two, they’re identical and uses are the primary and secondary DNS servers for everything that needs a dns server.
>> DNSdist servers have a mgmt IP and a service IP:
>> Service IP bound to DNSdist: 10.0.1.13
>> Mgmt. IP, not bound to DNSdist: 10.0.2.13
>> The second PowerDNS-recursor is backup
>> The IPA server(s) should only be used for updates (by IPA-clients)
>>
>> -- define downstream servers, aka backends
>> newServer({address="10.0.1.11", name="rns00", useProxyProtocol=true})
>> newServer({address="10.0.1.12", name="rns01", pool={"backup"}, useProxyProtocol=true})
>> newServer({address="10.0.0.10", name="ipa0", pool={"auth"}})
>> newServer({address="10.0.0.11", name="ipa1", pool={"auth"}})
>>
>> -- Send queries to default pool when servers are available
>> addAction(PoolAvailableRule(""), PoolAction(""))
>> -- Send queries to fallback pool if not
>> addAction(AllRule(), PoolAction("backup"))
>> -- Send UPDATES to IPA
>> addAction(AndRule({OpcodeRule(DNSOpcode.Update)}), PoolAction("auth"))
>>
>> -- Refuse incoming AXFR, IXFR, NOTIFY and UPDATE
>> ----addAction(OrRule({OpcodeRule(DNSOpcode.Notify), OpcodeRule(DNSOpcode.Update), QTypeRule(DNSQType.AXFR), QTypeRule(DNSQType.IXFR)}), RCodeAction(DNSRCode.REFUSED))
>> -- Refuse incoming AXFR, IXFR and NOTIFY
>> addAction(OrRule({OpcodeRule(DNSOpcode.Notify), QTypeRule(DNSQType.AXFR), QTypeRule(DNSQType.IXFR)}), RCodeAction(DNSRCode.REFUSED))
>>
>> -- Drop incoming requests with X-Proxied-For fields
>> addAction(RecordsTypeCountRule(DNSSection.Additional, 65280, 1, 65535), DropAction())
>>
>> The tcpdump shows repeated queries for a.root-servers.net <http://a.root-servers.net/>:
>>
>> IP 10.0.2.13.42939 > 10.0.0.10.domain: 19831+ A? a.root-servers.net <http://a.root-servers.net/>. (36)
>> IP 10.0.0.10.domain > 10.0.2.13.42939: 19831 1/0/0 A 198.41.0.4 (52)
>>
>> This is a DNS query from the server running DNSdist, from an IP address that DNSdist doesn’t listen on. I assume DNSdist just uses whatever source address the OS deems suitable for egress traffic, which in my case would indeed be 10.0.2.13.
>>
>> So my questions are:
>>
>> Why are A queries sent to the IPA server, when only UPDATE queries should be sent there?
>> Why the repeated queries? I see repeated A record lookups for a.root-servers.net <http://a.root-servers.net/> from both DNSdist servers and both PowerDNS-recursors. I would expect at least the recursors to cache these requests.
>> How do I fix the DNSdist behaviour? Should I move the primary DNS server into a pool? None of the failover examples I’ve seen show the primary DNS servers in a named pool.
>>
>> —
>> Thanks,
>> Djerk Geurts
>>
>> _______________________________________________
>> dnsdist mailing list
>> dnsdist at mailman.powerdns.com <mailto:dnsdist at mailman.powerdns.com>
>> https://mailman.powerdns.com/mailman/listinfo/dnsdist
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/dnsdist/attachments/20230912/19cab8d9/attachment.htm>
More information about the dnsdist
mailing list