3 Zář
2017
3 Zář
'17
21:08
Lisa,
If you use recvmmsg, also sendmmsg is used. And an empty response is
handled in a different way for each of these functions. It's possible
that sendmmsg sends also empty response in your case. What is your
environment/operation system? But with sendmsg there is an explicit
check
in the code which prevents sending empty response
(--enable-recvmmsg=no).
Could you test the empty_packet_test branch with some debug messages
and with a simple RRL module modification which inhibits every response
message?
-----------------------------------
# My test config
server:
listen: "127.0.0.1@28296"
mod-rrl:
- id: "test"
rate-limit: "100"
zone:
- domain: "spare."
file: "spare.rndzone"
module: [mod-rrl/test]
-----------------------------------
$ knotd -c ./test.conf
2017-09-03T20:59:50 info: Knot DNS 2.6.0-dev starting
2017-09-03T20:59:50 info: binding to interface 127.0.0.1@28296
...
2017-09-03T20:59:51 info: [spare.] loaded, serial 2737793557
...
DBG: sendmmsg, empty packet check
DBG: sendmmsg, empty packet check
$ kdig @127.0.0.1 -p28296 spare. any +retry=0
;; WARNING: response timeout for 127.0.0.1@28296(UDP)
;; WARNING: failed to query server 127.0.0.1@28296(UDP)
$ dig @127.0.0.1 -p28296 spare. any +retry=0
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @127.0.0.1 -p28296 spare. any
+retry=0
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Btw, could you please show me your module implementation?
Daniel
On 2017-09-03 03:00, Lisa Bahler wrote:
Daniel,
I tried with both recvmmsg set to yes and to no. Made no difference.
Not sure why it would.
When I use the dig client to send to the server, I can see from the
module log that dig tries three times to receive a valid response
before giving up.
It appears that knot is still sending a response each time, but
because pkt->size was set to 0 in an attempt to have the server drop
the message, dig complains about the length.
What I see is(actual address obscured with XXX.XXX.XXX.XXX):
dig ANY test.com @XXX.XXX.XXX.XXX
;; Warning: short (< header size) message received
;; Warning: short (< header size) message received
;; Warning: short (< header size) message received
; <<>> DiG 9.10.3-P4-Ubuntu <<>> ANY test.com @XXX.XXX.XXX.XXX
;; global options: +cmd
;; connection timed out; no servers could be reached
It would be great if the server would send nothing at all and truly
drop the message. Are you seeing a true drop? Again, I'm working
with the latest 2.6 code from the git repo.
Thanks,
Lisa
On 9/2/2017 2:38 AM, daniel.salzman(a)nic.cz wrote:
> Hi Lisa,
>
> Setting packet size to 0 and returning KNOTD_STATE_DONE is the proper
> way
> how to inhibit a response. It also work in my simple test. Which
> version
> of Knot do you have? Is recvmmsg utilized (see configure summary)?
>
> Daniel
>
> On 2017-09-01 19:45, Lisa Bahler wrote:
>> I've written aknot module, which is functioning well. I've been
>> asked
>> to add functionality to it that would inhibit any response from knot,
>> based upon the client's identity. I know the identity; I just need
>> to
>> figure out how to inhibit a response.
>>
>> I just noticed the rrl module, and I looked at what it does. I
>> emulated what I saw and set pkt->size = 0 and returned
>> KNOTD_STATE_DONE.
>>
>> When I ran host -a, it returned that no servers could be reached.Â
>> When I ran dig ANY, I ultimately got the same response, but dig
>> complained three times about receiving a message that was too short
>> in
>> length.
>>
>> I really want NO message to be returned. How do I force this?
>>
>>
>>
>> _______________________________________________
>> knot-dns-users mailing list
>> knot-dns-users(a)lists.nic.cz
>> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
> _______________________________________________
> knot-dns-users mailing list
> knot-dns-users(a)lists.nic.cz
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users