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] TCP FastOpen
Since version is pre 1.2 syntax is
setLocal(address[[[, do_tcp], so_reuseport], tcp_fast_open_qsize])
You could try setLocal( "0.0.0.0", true,true,100)
https://dnsdist.org/reference/config.html?highlight=setlocal#setLocal
Winfried
Am 2. Mai 2019 19:35:45 MESZ schrieb Casey Deccio :
>Hi,
>
>I'm using dnsdist 1.1.0-2+deb9u1 on Debian. I get the following error
>when I try to enable TCP Fast Open:
>
>> setLocal("0.0.0.0:53", { tcpFastOpenSize=100 })
>Unable to convert parameter from no value to N5boost8optionalIbEE
>
>Any suggestions?
>
>The answer might be to upgrade, but I've got a running configuration,
>and I'm hoping not to have to change it (for now) if possible, due to
>time constraints.
>
>Thanks!
>Casey
>
>___
>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] downstream flapping down/up
The recursor service isn't down and if i run the below type command, i
recieve no failures.
$ while true; do dig @10.225.12.19 google.com +short; done
Since dig does 3 tries this way, you will likely not notice short outages.
Try
dig +tries=1 +time=1
Winfried
Am 12.05.2017 um 06:32 schrieb scott McGillivray:
Hi
I have dnsdist in front of pdns with this config:
# start_dnsdist.conf
local public_ipaddr = "x.x.x.x"
local rec_ipaddr = "10.200.1.19"
local hostname = "dns01"
setLocal(public_ipaddr .. ":53", true, true)
setACL({"0.0.0.0/0", "::/0"})
setECSOverride(true)
setECSSourcePrefixV4(32)
setECSSourcePrefixV6(128)
newServer{address=rec_ipaddr, source="eth0",
name=hostname.."-recursor", order=1, checkName="google.com.",
pool="recursive", useClientSubnet=true}
setServerPolicy(firstAvailable)
# end_dnsdist.conf
For some reason my dnsdist log is flooded with these entries.
May 11 15:30:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:30:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:32:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:32:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:33:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:33:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:35:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:35:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:36:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:36:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:38:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:38:34 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:40:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:40:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:43:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:43:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:44:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:44:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:45:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:45:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:46:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:46:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:47:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:47:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:48:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:48:34 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:53:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
May 11 15:53:33 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'up'
May 11 15:59:32 hdc-onl-dns01 dnsdist[24365]: Marking downstream
hdc-onl-dns01-recursor (10.225.12.19:53) as 'down'
The recursor service isn't down and if i run the below type command, i
recieve no failures.
$ while true; do dig @10.225.12.19 google.com +short; done
I'm using these packages
pdns-4.0.3-1pdns.el7.x86_64
pdns-backend-geoip-4.0.3-1pdns.el7.x86_64
dnsdist-0.0.1551g8c5dc03-1pdns.el7.x86_64
pdns-recursor-4.0.4-1pdns.el7.x86_64
pdns-backend-mysql-4.0.3-1pdns.el7.x86_64
Can you help please ?
___
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] 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
Re: [dnsdist] Fwd: dnsdist cache looks empty
> Unable to bind to webserver socket > on 192.168.1.3:8083: binding socket > to 192.168.1.3:8083: Address already > in use It seem you run another dnsdist instance on this server. This would explain the zero counters. Winfried ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] udp timeout?
Am 22.11.2016 um 09:49 schrieb Remi Gacogne: I am afraid the UDP timeout is not configurable at the moment... How long is the built-in timeout? Winfried ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
