Re: [dnsdist] How to dissect proxyv2-procotol with DNS and UDP?
Hi Winfried Many thanks for this hint, that did the trick. Best regards, Tom On 2/21/24 09:48, Winfried via dnsdist wrote: Hi Tom, > When using UDP with DNS and proxy protocol, then neither tshark nor wireshark are able to decode the proxy protocol This sounds like a problem I had some time ago. But it was fixed by John from the Wireshark project. It worked for me when I built it from Git. See https://gitlab.com/wireshark/wireshark/-/issues/19237 https://gitlab.com/wireshark/wireshark/-/issues/19261 Winfried ___ 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
[dnsdist] How to dissect proxyv2-procotol with DNS and UDP?
Hi list Looking at a captured PCAP file, where the proxy procotol with DNS is used: - When using TCP with DNS and proxy protocol, then tshark/wireshark is able to dissect the proxy-protocol: $ tshark -n -r /tmp/proxy_tcp.cap 1 0.00 0.0 192.168.236.1 43317 10.100.102.21 5353 TCP 74 0 64660 0 1 0 1220 43317 → 5353 [SYN] Seq=0 Win=64660 Len=0 MSS=1220 SACK_PERM TSval=3048985939 TSecr=0 WS=128 2 0.62 0.62000 10.100.102.21 5353 192.168.236.1 43317 TCP 66 0 24400 0 1 1 1220 5353 → 43317 [SYN, ACK] Seq=0 Ack=1 Win=24400 Len=0 MSS=1220 SACK_PERM WS=128 3 0.018303 0.018241000 192.168.236.1 43317 10.100.102.21 5353 TCP 60 0 64768 1 1 1 43317 → 5353 [ACK] Seq=1 Ack=1 Win=64768 Len=0 4 0.018364 0.61000 192.168.236.1 43317 10.100.102.21 5353 PROXYv2 82 28 64768 28 1 29 1 43317 → 5353 [PSH, ACK] Seq=1 Ack=1 Win=64768 Len=28 5 0.018375 0.11000 10.100.102.21 5353 192.168.236.1 43317 TCP 54 0 24448 1 1 29 5353 → 43317 [ACK] Seq=1 Ack=29 Win=24448 Len=0 6 0.018384 0.09000 192.168.236.1 43317 10.100.102.21 5353 DNS 107 53 64768 53 29 82 1 Standard query 0x42db A google.com OPT 7 0.018387 0.03000 10.100.102.21 5353 192.168.236.1 43317 TCP 54 0 24448 1 1 82 5353 → 43317 [ACK] Seq=1 Ack=82 Win=24448 Len=0 8 0.018889 0.000502000 10.100.102.21 5353 192.168.236.1 43317 DNS 139 85 24448 85 1 86 82 Standard query response 0x42db A google.com A 172.217.168.46 OPT 9 0.042093 0.023204000 192.168.236.1 43317 10.100.102.21 5353 TCP 60 0 64768 82 82 86 43317 → 5353 [ACK] Seq=82 Ack=86 Win=64768 Len=0 10 0.042120 0.27000 192.168.236.1 43317 10.100.102.21 5353 TCP 60 0 64768 82 83 86 43317 → 5353 [FIN, ACK] Seq=82 Ack=86 Win=64768 Len=0 11 0.042237 0.000117000 10.100.102.21 5353 192.168.236.1 43317 TCP 54 0 24448 86 87 83 5353 → 43317 [FIN, ACK] Seq=86 Ack=83 Win=24448 Len=0 12 0.060066 0.017829000 192.168.236.1 43317 10.100.102.21 5353 TCP 60 0 64768 83 83 87 43317 → 5353 [ACK] Seq=83 Ack=87 Win=64768 Len=0 - When using UDP with DNS and proxy protocol, then neither tshark nor wireshark are able to decode the proxy protocol: $ tshark -n -r /tmp/proxy_udp.cap -d udp.port==5353,dns 1 0.00 192.168.236.1 38039 10.100.102.21 5353 DNS 121 Inverse query 0x0d0a Unknown (867) A OPT Unused [Malformed Packet] 2 0.000316 10.100.102.21 5353 192.168.236.1 38039 DNS 125 Standard query response 0x7188 A google.com A 172.217.168.46 OPT Any hints, how I can dissect the proxy protocol with DNS and UDP? Thanks in advance, Tom ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Client query id in the dq-object?
On 11/3/22 15:38, Otto Moerbeek wrote:
On Wed, Nov 02, 2022 at 05:19:54PM +0100, Tom via dnsdist wrote:
Hi list
A few months ago, I've asked the question below and wasn't able to find a
solution in the meantime. Does someone has a hint, how to achieve this?
Many thanks in advance.
Tom
On 7/28/22 11:17, Tom wrote:
Hi
Using dnsdist-1.7.2, I'm trying to get the query id from the
client-query, but I can't find the matching parameter in the dq-object.
My goal is to find a specific query-id (ex. ) and then use this
(same) specific query-id also for the outbound query from dnsdist to the
backend server.
Any hints how to achieve this?
Many thanks.
Tom
There is no API to get the queryid. It could maybe be added, but
*setting* the query id four outgoing queries is something else.
Keeping track of query-id's is a complex problem, think about multiple
clients, multiple backends, many queries in-flight. This is not
something to be done from Lua, but a job for dnsdist itself.
To ask a more general question: what problem are you trying to solve?
Since BIND-9.18.0 there's a feature which turns on query-debugging for
requests with query ID 0
(https://gitlab.isc.org/isc-projects/bind9/-/issues/1851). DIG supports
setting the query ID with "+qid=0". This means querying BIND with
"+qid=0" provides me a debug log of the appropriate query.
So, if a BIND is behind dnsdist, then I'm not able to trigger this
query-debugging via dnsdist, because dnsdist uses random query IDs
against a backend server. A way could be to query BIND directly (without
dnsdist), but perhaps I'm not able to do so (firewall...).
So the idea was to set a dnsdist rule on which I can set the
AllowedDebugSRC (the admin's IP, to prevent, that anybody else could
trigger the debug), check the QueryID and then send this kind of
requests to a debug-enabled BIND, which then write a debug log from the
received query. Someting like this:
AllowedDebugSRC = newNMG()
AllowedDebugSRC:addMask("1.2.3.4/32")
function qidlog(dq)
if(AllowedDebugSRC:match(dq.remoteaddr) and == 0) then
print("Debugging from " .. dq.remoteaddr:toString() ..
" with query id" .. )
return DNSAction.Pool, "bind-querylog"
end
end
addAction(AllRule(), LuaAction(qidlog))
Thanks a lot.
Tom
If we would have more insight in that, we can maybe suggest an
alternative approach to solve your problem.
-Otto
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Client query id in the dq-object?
Hi list A few months ago, I've asked the question below and wasn't able to find a solution in the meantime. Does someone has a hint, how to achieve this? Many thanks in advance. Tom On 7/28/22 11:17, Tom wrote: Hi Using dnsdist-1.7.2, I'm trying to get the query id from the client-query, but I can't find the matching parameter in the dq-object. My goal is to find a specific query-id (ex. ) and then use this (same) specific query-id also for the outbound query from dnsdist to the backend server. Any hints how to achieve this? Many thanks. Tom ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
[dnsdist] Client query id in the dq-object?
Hi Using dnsdist-1.7.2, I'm trying to get the query id from the client-query, but I can't find the matching parameter in the dq-object. My goal is to find a specific query-id (ex. ) and then use this (same) specific query-id also for the outbound query from dnsdist to the backend server. Any hints how to achieve this? Many thanks. Tom ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnstap logs CLIENT_RESPONSES only, when the queried RR is not in cache
Hi Remi That did the trick! Thanks a lot. Kind regards, Tom On 27.08.21 09:43, Remi Gacogne via dnsdist wrote: Hi Tom, On 8/27/21 8:21 AM, Tom via dnsdist wrote: Using dnsdist-1.6.0, a packet-cache-configuration and a dnstap (newFrameStreamUnixLogger) configuration, which is configured for logging responses too: I have noticed that in the dnstap-logs the CLIENT_RESPONSE only appears, when dnsdist has NO cache entry for this request. Ever client-query, which can be answered from the dnsdist-cache will only be logged with "CLIENT_QUERY" and not additional with CLIENT_RESPONSE. I can't know for sure without seeing your actual configuration but my guess is that you are using addResponseAction() to log responses, and these rules are not applied to cache hits, for historical reasons. You can apply rules to cache hits via addCacheHitResponseAction() [1]. [1]: https://dnsdist.org/rules-actions.html?#addCacheHitResponseAction Hope that helps, Remi ___ 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
[dnsdist] dnstap logs CLIENT_RESPONSES only, when the queried RR is not in cache
Hi
Using dnsdist-1.6.0, a packet-cache-configuration and a dnstap
(newFrameStreamUnixLogger) configuration, which is configured for
logging responses too:
I have noticed that in the dnstap-logs the CLIENT_RESPONSE only appears,
when dnsdist has NO cache entry for this request. Ever client-query,
which can be answered from the dnsdist-cache will only be logged with
"CLIENT_QUERY" and not additional with CLIENT_RESPONSE.
Look here:
# initial query (dnsdist hast empty cache) for mx google.com will be
logged with dnstap (CLIENT_QUERY and CLIENT_RESPONSE):
2021-08-27T06:09:35.541094903Z server01 CLIENT_QUERY NOERROR 192.168.1.1
55177 INET UDP 51b google.com MX 0.00
2021-08-27T06:09:35.557156637Z server01 CLIENT_RESPONSE NOERROR
192.168.1.1 55177 INET UDP 185b google.com MX 0.016062
# 2nd, third, fourth etc. query for the same RR will only be logged with
CLIENT_QUERY:
2021-08-27T06:11:11.711001431Z server01 CLIENT_QUERY NOERROR 192.168.1.1
54555 INET UDP 51b google.com MX 0.00
2021-08-27T06:11:13.238908856Z server01 CLIENT_QUERY NOERROR 192.168.1.1
48615 INET UDP 51b google.com MX 0.00
2021-08-27T06:11:14.16733849Z server01 CLIENT_QUERY NOERROR 192.168.1.1
57005 INET UDP 51b google.com MX 0.00
2021-08-27T06:11:14.776923103Z server01 CLIENT_QUERY NOERROR 192.168.1.1
37766 INET UDP 51b google.com MX 0.00
# the cache-dump looks like this:
; dnsdist's packet cache dump follows
;
google.com. 488 MX ; rcode 0, key 4146178086, length 185, tcp 0, added
1630044575
When I clear the cache (getPool("poolname"):getCache():expunge(0)) or
restart dnsdist, then every first not cached query is logged again with
CLIENT_QUERY and CLIENT_RESPONSE.
Any hints for this?
Many thanks.
Kind regards,
Tom
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnstap shows UDP for a DoH-query
Hi Remi I've opened a bug report: https://github.com/PowerDNS/pdns/issues/10497 Thank you. Kind regards, Tom On 14.06.21 16:09, Remi Gacogne via dnsdist wrote: Hi Tom, On 6/14/21 2:41 PM, Tom via dnsdist wrote: Why do I see the protocol "UDP" in the fstrm-log for a DoH request, although I am sure (tcpdump) that this request was made with tcp? Maybe because dnsdist queries the backend server with UDP for the DoH request? Yes, it looks like a bug. It is likely that there was indeed some confusion between the protocol the query was received on and the one used to contact the backend. I know I had to clean that up in [1], because it introduces the ability to forward UDP queries over TCP/TLS, for example, so it made things even more complicated. So I know this will be fixed in 1.7.0, but we should fix that in 1.6.x as well. Would you mind opening a bug report in GitHub [2]? Otherwise I'll do so we remember to look into it. [1]: https://github.com/PowerDNS/pdns/pull/10338 [2]: https://github.com/PowerDNS/pdns/issues/new/choose Cheers, ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
[dnsdist] dnstap shows UDP for a DoH-query
Hi I'm logging dnsdist queries/responses with newFrameStreamUnixLogger to a unix socket, where fstrm_capture takes the data and write it to a fstrm-file. When querying dnsdist with DoH (TCP), then my fstrm-log shows UDP (see below). $ dnstap-read -p 2021-06-13-dnstap.fstrm ... ... 14-Jun-2021 14:19:30.058 CQ x.x.x.x:44749 -> y.y.y.y:443 UDP 51b google.com/IN/A ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1015 ;; flags: rd ad; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 1f5e39ad95e85cd8 ;; QUESTION SECTION: ;google.com.IN A 14-Jun-2021 14:19:30.059 CR x.x.x.x:44749 <- y.y.y.y:443 UDP 83b google.com/IN/A ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1015 ;; flags: qr rd ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 1f5e39ad95e85cd8010060c74952f681b113fec0d503 ;; QUESTION SECTION: ;google.com.IN A ;; ANSWER SECTION: google.com. 266 IN A 216.58.215.238 ... ... My question is: Why do I see the protocol "UDP" in the fstrm-log for a DoH request, although I am sure (tcpdump) that this request was made with tcp? Maybe because dnsdist queries the backend server with UDP for the DoH request? Many thanks for any explanations. Kind regards, Tom ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Explanation for "drops" in "showServers()"?
Perfect Remi, thanks a lot for this explanation! Kind regards, Tom On 10.06.21 14:48, Remi Gacogne via dnsdist wrote: Note, however, that dnsdist doesn't pick UDP queries that timed out very quickly, for performance reasons. It does instead iterate over the pending UDP queries from time to time, usually once every second. That means that a response can in practice comes back after the UDP timeout and still be processed as if it did not exceed the timeout, as long as the corresponding entry has not yet been cleaned up. That would be my guess in that case. ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Explanation for "drops" in "showServers()"?
Hi Remi
Thanks a lot for this clarification.
Our UDP-Timeouts defaults to 2. With the "grepq("2000ms")" command, I
can see a lot of entries with the mentioned "T.O" (timeout). But I see
also the following entry with a latency of 2891.8ms which should be
dropped if UDP, right?:
-12.4 xx.xx.xx.xxx:50105 zz.zz.zz.zzz:53
4417 abc.example.com. A 2891.8RDNo Error. 13 answers
In the documentation I don't see a default-value for tcp-timeout. So
could the line above be a tcp-request without the default 2000ms
timeout? If not, why do grepq report this line and/or why does dnsdist
not drop this query?
Many thanks.
Kind regards,
Tom
On 10.06.21 10:16, Remi Gacogne via dnsdist wrote:
Hi Tom,
On 6/10/21 8:03 AM, Tom via dnsdist wrote:
In the case above, I see 14926 drops from backend01. According the
documentation, the backend server discards these requests. Is there a
way in dnsdist, to see which queries where dropped? What can cause a
backend server to drop requests? For example timeouts while doing name
resolution? Does "drops" mean that dnsdist has not received a response
back from the backendserver within a certain time (e.g. > setUDPTimeout)?
"Drops" values are indeed the number of queries for which dnsdist did
not a response before the setUDPTimeout value. You can see if there was
any recent "drops" by looking at the in-memory ring buffers storing a
summary of the last queries and responses. For that you need to connect
to the dnsdist console and issue a 'grepq("1000ms")' command. It will
display queries and responses that took more than 1000ms, so the "drops"
should be there with "T.O" in the response time column.
As for why the backend is not responding fast enough, or at all, to
these queries, that needs to be investigated on the backend itself.
Best regards,
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
[dnsdist] Explanation for "drops" in "showServers()"?
Hi I'm trying to understand the column "drops" in the "showServers()"-function: > showServers() # Name Address State Qps Qlim Ord WtQueries Drops Drate Lat Outstanding Pools 0 backend01192.168.1.1:53 up76.7 0 1 15121235 14926 0.0 30.7 6 primary 1 backend02192.168.1.2:53 up49.8 0 1 15163504 15051 0.0 34.5 6 primary In the case above, I see 14926 drops from backend01. According the documentation, the backend server discards these requests. Is there a way in dnsdist, to see which queries where dropped? What can cause a backend server to drop requests? For example timeouts while doing name resolution? Does "drops" mean that dnsdist has not received a response back from the backendserver within a certain time (e.g. > setUDPTimeout)? Any hints for this? Thanks a lot. Kind regards, Tom ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] Question on backend selection
Hi Stefan, Daniel
Many thanks for your feedback. I'll give a try.
Kind regards,
Tom
On 02.06.21 10:35, Stefan Schmidt via dnsdist wrote:
June 2, 2021 10:28 AM, "Daniel Stirnimann via dnsdist"
wrote:
Hello Tom,
This might come very close to what you are looking for:
newServer({name="backend01",order=1, qps=5000,...})
newServer({name="backend02",order=1, qps=5000,...})
newServer({name="backend03",order=2, qps=5000,...})
newServer({name="backend04",order=2, qps=5000,...})
setServerPolicy(firstAvailable)
"The firstAvailable policy, picks the first available server that has
not exceeded its QPS limit, ordered by increasing ‘order’. If all
servers are above their QPS limit, a server is selected based on the
leastOutstanding policy. For now this is the only policy using the QPS
limit."
https://dnsdist.org/guides/serverselection.html
Yes that does the trick.
https://dnsdist.org/reference/config.html#Server.order
https://dnsdist.org/reference/config.html?highlight=order#newServer
Since i was already writing along the same lines, here is part of an actual
configuration of mine:
-- define the good servers
newServer{address="127.0.0.1:5353", qps=300, order=1}
newServer{address="8.8.8.8", qps=2, order=2}
newServer{address="8.8.4.4", qps=2, order=2}
newServer{address="208.67.222.222", qps=1, order=2}
newServer{address="208.67.220.220", qps=1, order=2}
newServer{address="2001:4860:4860::", qps=2, order=2}
newServer{address="2001:4860:4860::8844", qps=2, order=2}
newServer{address="2620:0:ccc::2", qps=10, order=2}
newServer{address="2620:0:ccd::2", qps=10, order=2}
showServers()
# Name Address State Qps Qlim Ord Wt Queries Drops Drate Lat Outstanding Pools
0 127.0.0.1:5353 127.0.0.1:5353 up 1.0 300 1 1 435275 1304 0.0 159.3 0
1 8.8.8.8:53 8.8.8.8:53 up 0.0 2 2 1 0 0 0.0 0.0 0
2 8.8.4.4:53 8.8.4.4:53 up 0.0 2 2 1 0 0 0.0 0.0 0
3 208.67.222.222:53 208.67.222.222:53 up 0.0 1 2 1 0 0 0.0 0.0 0
4 208.67.220.220:53 208.67.220.220:53 up 0.0 1 2 1 0 0 0.0 0.0 0
5 [2001:4860:4860::888 [2001:4860:4860::]:53 up 0.0 2 2 1 0 0 0.0 0.0 0
6 [2001:4860:4860::884 [2001:4860:4860::8844]:53 up 0.0 2 2 1 0 0 0.0 0.0 0
7 [2620:0:ccc::2]:53 [2620:0:ccc::2]:53 up 0.0 10 2 1 0 0 0.0 0.0 0
8 [2620:0:ccd::2]:53 [2620:0:ccd::2]:53 up 0.0 10 2 1 0 0 0.0 0.0 0
All 0.0 435275 1304
Stefan
___
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
[dnsdist] Question on backend selection
Hi list Using dnsdist 1.5.2 with four configured backend servers (backend01-backend04). Is there a way to configure dnsdist to use backend03 and backend04 only, if backend01 and backend02 are not answering on the healthcheck? Or better: use backend03 or backend04 only if backend01 or backend02 are down. Any hints? Thank you. Kind regards, Tom ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
[dnsdist] Exceed-Warning after adding some more listeners
Hi list Using dnsdist 1.5.2. After adding some more udp/tcp-listeners on differnt IP addresses with addLocal, addTLSLocal and addDOHLocal, I got the following warning: Adding a new TCP client thread would exceed the vector capacity (10/10), skipping Is there a limit of 10 listening-sockets? Can this be increased? Or some other hints for this? Many thanks. Kind regards, Tom ___ dnsdist mailing list dnsdist@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/dnsdist
Re: [dnsdist] dnsdist-cache-questions
Hi Daniel
Thank you for your answers.
On 22.09.20 11:48, Daniel Stirnimann wrote:
Hello Tom,
On 22.09.20 11:26, Tom via dnsdist wrote:
When I now want to query the cache via console, I always get the
following error:
> getPool("bind"):getCache()
Command returned an object we can't print: Trying to cast a lua variable
from "userdata" to
Any hints for this?
getCache() returns a PacketCache class. You cannot print the class on
the console but need to do something with it e.g.:
getPool("bind"):getCache():printStats()
This make sense...
My 2nd question:
Assuming the dnsdist-cache is working, has a A-Record-cache-entry for
"www.example.com" and dnsdist is in front of a resolver and the resolver
(backend) stops working. dnsdist has the record "www.example.com" still
in his cache, because only the backend server stops working. Why does
dnsdist not answer the query for "www.example.com" from the cache, when
the backend server is "down"? Is there a configuration option for this?
From your previous config snippet it looks like you are already using
staleTTL:
staleTTL=60: int - When the backend servers are not reachable, and
global configuration setStaleCacheEntriesTTL is set appropriately, TTL
that will be used when a stale cache entry is returned.
How do you verify that dnsdist is not answering queries from the cache?
Verifying the cache before the backend server is down:
> getPool("bind"):getCache():dump("/tmp/test4")
Dumped 7 records
$ cat /tmp/test4
; dnsdist's packet cache dump follows
;
www.google.com. 223 A ; key 1016681760, length 87, tcp 0, added 1600774835
www.google.com. 223 A ; key 2656564995, length 87, tcp 0, added 1600774834
www.google.com. 223 A ; key 978655059, length 87, tcp 0, added 1600774834
www.google.com. 223 A ; key 909047115, length 87, tcp 0, added 1600774833
www.google.com. 223 A ; key 3059942742, length 87, tcp 0, added 1600774833
www.google.com. 223 A ; key 3932187633, length 87, tcp 0, added 1600774832
www.google.com. 223 A ; key 2216669160, length 87, tcp 0, added 1600774832
Then stopping the backend server. Verifying the cache again.., shows
still seven entries. Then dig'ing dnsdist (not the backend!) with "dig
@192.168.1.2 www.google.com" gives me a query timeout instead the A
record for www.google.com. There's also no ip address in the cache dump
above...?
Must the backend server being up to get a cached responses from dnsdist?
Or do I misunderstand packetcache/dnscache here?
Thank you.
Kind regards,
Tom
Keep in mind that dnsdist caches packets and not responses to DNS
queries. Recent 'dig' versions have EDNS cookies enabled by default.
Each of your queries (packets) will therefore differ. Try 'dig' with
+nocookie
Daniel
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
[dnsdist] dnsdist-cache-questions
Hi
I'm new on dnsdist (1.5.0) and have some questions:
1) I've created a simple cache-configuration (more or less copied from
the manual) like this:
packetcache = newPacketCache(1, {maxTTL=86400, minTTL=0,
temporaryFailureTTL=60, staleTTL=60, dontAge=false})
getPool("bind"):setCache(packetcache)
The backend server is "up" and joined in the pool "bind":
> showPools()
Name Cache ServerPolicy Servers
leastOutstanding
bind 6/1 leastOutstanding
testserver 192.168.1.10:5353
When I now want to query the cache via console, I always get the
following error:
> getPool("bind"):getCache()
Command returned an object we can't print: Trying to cast a lua variable
from "userdata" to
"N5boost8optionalINS_7variantISsSt10shared_ptrI15DownstreamStateEP11ClientStateSt13unordered_mapISsdSt4hashISsESt8equal_toISsESaISt4pairIKSsdEEENS_6detail7variant5void_ESJ_SJ_SJ_SJ_SJ_SJ_SJ_SJ_SJ_SJ_SJ_SJ_SJ_SJ_SJ_"
Any hints for this?
My 2nd question:
Assuming the dnsdist-cache is working, has a A-Record-cache-entry for
"www.example.com" and dnsdist is in front of a resolver and the resolver
(backend) stops working. dnsdist has the record "www.example.com" still
in his cache, because only the backend server stops working. Why does
dnsdist not answer the query for "www.example.com" from the cache, when
the backend server is "down"? Is there a configuration option for this?
Many thanks.
Kind regards,
Tom
___
dnsdist mailing list
dnsdist@mailman.powerdns.com
https://mailman.powerdns.com/mailman/listinfo/dnsdist
