Re: [dnsdist] dnsdist and Let's Encrypt (ACME)
>certbot renew --standalone --deploy-hook >/usr/local/sbin/restart-dnsdist There is no need to restart dnsdist. /usr/sbin/dnsdist -e 'reloadAllCertificates()' is sufficient Winfried ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] ComboAddress truncate function?
My guess is that dq.remoteaddr:truncate(24) doesn't truncate the address in dq.
Instead it *returns* the truncated address.
Winfried
Am 28. August 2019 17:35:24 MESZ schrieb Brian Sullivan
:
>Hi All,
>
>I am trying to use the truncate function associated with the
>CombAddress
>object.
>
>Here is the config:
>
>
>
>
>
>
>*-- Any traffic that exceeds max qps will be loggedfunction
>rateLimitRule(dq) dq.remoteaddr:truncate(24) errlog("Rate Limit
>Exceeded:
>DNSDistRateLimiting "..dq.remoteaddr:toString()) return
>DNSAction.None,
>""endaddAction(MaxQPSIPRule(10, 24, 48), LuaAction(rateLimitRule))*
>
>Unfortunately I see the following output:
>
>
>*dnsdist[882]: Rate Limit Exceeded: DNSDistRateLimiting 10.51.13.64*
>
>I know this must work so I must be doing something wrong.
>
>Regards,
>brian
>--
>
>
>
>Brian M. Sullivan
>Senior Staff Security Intelligence Engineer
>bsulli...@lookout.com | www.lookout.com
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist 1.4 and Debian Buster
I read Debian Buster is shipped with nftables. Am 9. August 2019 09:57:36 MESZ schrieb Chris : >Hi Winfried, > >On 9/08/2019 3:50 pm, ab...@t-ipnet.net wrote: >> Hi Chris, >> >> Maybe I missed that in this thread, but did you try with turning off >> connection tracking or rising conntrack kernel table size? dmesg >might >> you show wether connection tracking limit was exceeded. >> >> Winfried > >Thanks for the suggestion. By default I raise the conntrack table size >as normally this server is using iptables with stateful rules to allow >management. I also tried with no iptables rules and the conntrack >module >not loaded. > >Thanks >___ >dnsdist mailing list >dnsdist@mailman.powerdns.com >https://mailman.powerdns.com/mailman/listinfo/dnsdist ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist 1.4 and Debian Buster
Hi Chris, Maybe I missed that in this thread, but did you try with turning off connection tracking or rising conntrack kernel table size? dmesg might you show wether connection tracking limit was exceeded. Winfried Am 9. August 2019 05:46:54 MESZ schrieb Chris : >Hi Remi, > >I deployed a new copy of a PowerDNS authoritative server on Debian >Buster and ran into a similar problem but with a slight twist. As with >dnsdist I use multiple instances of PowerDNS which use different SQL >DB's. > >As with dnsdist, after a period of time I stopped being able to make >UDP >queries but TCP queries worked fine. The built in web server also works > >(I guess because its TCP). This happened to all instances on the server > >at the same time (even an instance which only gets health check queries > >from a few dnsdist servers). > >I wanted to see if I could see anything different comparing a working >instance with a not working instance on the same server so I restarted >one of the instances. When I restart that one instance all started >working again as expected. With that in mind it sounds like some sort >of >limit gets hit. I do raise 'LimitNOFILE' and 'TasksMax' settings in a >systemd service.d file for each instance already. > >As with dnsdist I couldn't find anything in the system logs indicating >why. The auth servers have the same configuration and server setup as I > >was running on Debian Stretch - I deploy a minimal install with puppet >installed and it will deploy the rest. > >On 8/08/2019 9:15 pm, Remi Gacogne wrote: >> Be careful that dig (the 9.14.4 I have here at least) uses TCP by >> default for ANY queries so you might need a +notcp to actually test >UDP. > >Thanks, I double checked and it is using UDP for those queries. > >I'll have to keep digging to see if I can find out why, as of now I >don't understand why its happening like this. > >Thanks >___ >dnsdist mailing list >dnsdist@mailman.powerdns.com >https://mailman.powerdns.com/mailman/listinfo/dnsdist ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist NOTIFY distribution
Hello Martin, Am 26. Februar 2019 17:07:25 MEZ schrieb Martin Toth : >Hi, > >Thanks for your interest. I am using dnsdist as a loadbalancer and >slave nodes are in DMZ behind dnsdist. Only dnsdist server has public >IPs that can be reached from Master public IP (master is located in >other datacentre). >Is my usecase not designed well? I thought dnsdist was designed to be >used as LB for DNS services. Do you have any suggestions how to solve >this or what workround should I use ? Did not try it myself, but could be an option: https://doc.powerdns.com/authoritative/manpages/nproxy.1.html > >Thanks. > >BR, > >> On 26 Feb 2019, at 16:59, Remi Gacogne >wrote: >> >> Hi Martin, >> >> On 2/26/19 3:58 PM, Martin Toth wrote: >>> I just want to ensure myself how NOTIFY distribution in DNSDIST >>> exactly works. My setup looks like this - MASTER -> DNSDIST -> SLAVE >>> PDNSs (pool of 4 nodes) >>> >>> My Question is if MASTER will send NOTIFY to DNSDIST, will DNSDIST >>> redistribute these NOTIFY to all SLAVES in DNSDIST backend? How to I >>> achieve situation that all slaves in dnsdist backend will be >notified >>> of zone change on MASTER? >> >> I'm afraid you can't, dnsdist can route a query only to a single >> backend, with the exception of the TeeAction, but I would advise >against >> trying to use it for that case. >> Is there a reason your master doesn't speak to the slaves directly? >> >> Best regards, >> -- >> Remi Gacogne >> PowerDNS.COM BV - https://www.powerdns.com/ Winfried ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] anyone using RemoteLogAction()?
Hi Jonathan, Remote logger is a Protobuf receiver. There is a implementation in the PowerDNS repository: https://github.com/PowerDNS/pdns/blob/master/contrib/ProtobufLogger.py Winfried Am 30. Oktober 2018 20:39:39 MEZ schrieb Jonathan Reed : >Hi, > >I'd like to try out RemoteLogAction but I've been unable to find any >examples of it out there yet. The docs say "Send the content of this >query >to a remote logger via Protocol Buffer". What exactly is this sending >to, a >syslog-ng listener on the remote system or something of the sort? > >Short of that I would try jumping into 1.3 and testing out dnstap for >this >instead, but Remote log action may be a much simpler approach? > >Thanks. ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Handling auth and recursive queries
Am 12.12.2016 um 04:42 schrieb Chris:
The part I am stuck on is it does not appear to be possible to direct
queries to certain IP's to certain pools. As an example, my caching
resolver IP's are 10.254.1.1, 10.254.1.2. I use addLocal like this:
addLocal("10.254.1.1:53")
addLocal("10.254.1.2:53")
I want to direct all queries destined to those two IP's to the
dnscache pool. I want to do the same thing for the other "addLocal"
IP's as well, queries to the IP's for our own domains should go to
pool dnsauth-internal, queries for the IP's for shared hosting should
go to pool dnsauth-shared etc. Is this possible with dnsdist? I can
see how I can do it based on filtering the domains but at the scale I
am using this it isn't really possible for me, the dnsauth-shared pool
for example has over 2M domains, dnsauth-dnshosting has over 4M
domains and there are very frequent changes to the domains for these.
See http://dnsdist.org/README/
"NetmaskGroupRule(nmg, [*src-bool*]):
matches traffic from the specified network range. Pass false as second
parameter to *match NetmaskGroup against destination address instead of
source address*"
So this should work:
dnscache_NMG = newNMG()
dnscache_NMG:addMask("10.254.1.1/32")
dnscache_NMG:addMask("10.254.1.2/32")
newServer({address="10.254.1.10", pool="dnscache"})
newServer({address="10.254.1.11", pool="dnscache"})
addPoolRule(NetmaskGroupRule(dnscache_NMG , false), "dnscache")
--
Winfried
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
