These are chat archives for CZ-NIC/knot-resolver

14th
Dec 2018
micah
@micah
Dec 14 2018 15:52
@pspacek sure, i'll check it now
micah
@micah
Dec 14 2018 15:59
only problem is I am not directing all my traffic to there now, due to some site architecture changes I need to do first
but i'll see if it fails without the traffic
micah
@micah
Dec 14 2018 16:36
ok, I can confirm I am not getting things to fail without the traffic... neither the 3.1.0 version without net.ipv6=false, nor the 3.2 dev version
so I need to send more traffic to the machines before I can test this
Petr Špaček
@pspacek
Dec 14 2018 16:56
Good to know, thank you for information!
Vladimír Čunát
@vcunat
Dec 14 2018 17:16
You might record a copy of the traffic and then separately replay it to kresd.
(That way you don't need to depend on testing a "broken" version.)
micah
@micah
Dec 14 2018 17:17
how would you do that?
Vladimír Čunát
@vcunat
Dec 14 2018 17:19
I believe tcpdump is popular for that.
On desktop I usually use the wireshark GUI, as that's nice for analyzing in details what's going on the wire.
(UDP is OK despite the name.)
Then replay with tcpreplay probably, but I have no personal experience with that.
Some other people in this channel will probably know these tools better than me, but it's weekend now.
micah
@micah
Dec 14 2018 18:32
good idea @vcunat
micah
@micah
Dec 14 2018 19:12
How can I forward all queries for 10.0.1.0/24 to another resolver? I've been trying a lot of things, but cannot seem to get it.
tried:
policy.add(policy.pattern(policy.FORWARD('204.13.164.2'), '10.0.1.0\24'))
policy.add(policy.pattern(policy.FORWARD('204.13.164.2'), '\210\10\11'))
and a few other attempts with todnames() and other tries
Vladimír Čunát
@vcunat
Dec 14 2018 19:29
To forward all you use
policy.add(policy.all(policy.FORWARD({'2001:678:1::206', '193.29.206.206'})))
micah
@micah
Dec 14 2018 19:30
@vcunat i only want to forward queries for 10.0.1.0/24
not all queries
Vladimír Čunát
@vcunat
Dec 14 2018 19:30
micah
@micah
Dec 14 2018 19:31
no I mean any query for that ip range, send it to another server
I dont think it matters what client IP, I'm already limiting based on client ip
Vladimír Čunát
@vcunat
Dec 14 2018 19:33
We don't have commands for that.
All this acts on incoming requests.
A that point the resolver doesn't even know which server it will ask (and there will be usually multiple queries to multiple servers for that single request).
micah
@micah
Dec 14 2018 19:35
but there is the forward action, that can be triggered based on patterns: policy.add(policy.pattern(policy.FORWARD('2001:DB8::1'), '\4bad[0-9]\2cz'))
Vladimír Čunát
@vcunat
Dec 14 2018 19:36
Patterns in the initial request.
micah
@micah
Dec 14 2018 19:36
that will forward queries to 2001:DB8::1 if they match \4bad[0-9]\2cz, right?
Vladimír Čunát
@vcunat
Dec 14 2018 19:36
Not patterns somewhere in DNS data related to the request.
(NS addresses in your case.)
micah
@micah
Dec 14 2018 19:37
I'm wanting to look up the reverse for 10.0.1.4 and have it ask a server, isn't that the initial request?
Vladimír Čunát
@vcunat
Dec 14 2018 19:37
Oh that, I misunderstood you.
That's just the name 4.1.0.10.in-addr.arpa.
micah
@micah
Dec 14 2018 19:38
right, so how can I do a pattern match on that, when the first octet could be 4 or it could be 256?
Vladimír Čunát
@vcunat
Dec 14 2018 19:38
Reverse (typically PTR) queries are simply transcribed into forward queries by the client already.
Not pattern, simple suffix.
micah
@micah
Dec 14 2018 19:40
so would that be like this: policy.add(policy.suffix(policy.FORWARD('204.13.164.2'), '\11\10\210\7in-addr\4arpa')) ?
Vladimír Čunát
@vcunat
Dec 14 2018 19:41
yes
except I usually prefer to use todname instead of manually inserting the lengths, but that should be the same.
micah
@micah
Dec 14 2018 19:42
like: policy.add(policy.suffix(policy.FORWARD('204.13.164.2'), {todname('1.0.10.in-addr.arpa')}))
Vladimír Čunát
@vcunat
Dec 14 2018 19:42
Yes, seems correct.
(But it's best to test. I'm not very good at syntax errors.)
Curiously we don't have any reverse-address examples in the docs so far...
micah
@micah
Dec 14 2018 19:43
yeah, I noticed that :)
Vladimír Čunát
@vcunat
Dec 14 2018 19:44
I made a TODO to fix that.
micah
@micah
Dec 14 2018 19:46
hmmm, ok, i'm not quite getting this still..
seems like it is asking higher level nameservers
actually, i can't tell, I have verbose(true) enabled, and when I try to ask for 10.0.1.4 i get no servers can be reached, but no logs
micah
@micah
Dec 14 2018 19:52
host 10.0.1.4 204.13.164.2 from that server, provides me the result... so forwarding there should work
Vladimír Čunát
@vcunat
Dec 14 2018 20:02
It's probably not providing DNSSEC proofs from the TAs, so you want to use STUB instead of FORWARD. At least that's typical for local authoritatives people have.
micah
@micah
Dec 14 2018 20:03
i get the same result with STUB
do I have something wrong in the syntax? policy.add(policy.suffix(policy.STUB('204.13.164.2'), {todname('1.0.10.in-addr.arpa')}))
micah
@micah
Dec 14 2018 20:10
edit: I thought I had a way to make it work, but it doesn't
micah
@micah
Dec 14 2018 20:32
also tried: policy:add(policy.suffix(policy.STUB('204.13.164.2'), {todname('1.0.10.in-addr.arpa')}))
micah
@micah
Dec 14 2018 20:52
and policy:add(policy.suffix(policy.STUB('204.13.164.2'), {todname('0.10.in-addr.arpa')}))
micah
@micah
Dec 14 2018 20:59
i think things were actually working, but I was not restarting things properly :P
Vladimír Čunát
@vcunat
Dec 14 2018 21:04
:-) The preferred syntax is with policy. and policy: is legacy though still probably works.
micah
@micah
Dec 14 2018 21:04
@vcunat same with view. and view:?
Vladimír Čunát
@vcunat
Dec 14 2018 21:05
No, only view: works, I believe. It's best to use what's in the docs in any case :-)
These two are inconsistent in this way.
micah
@micah
Dec 14 2018 21:06
yeah, weird!