14 Dub
2017
14 Dub
'17
16:02
Hello,
I set it up as below and forward it to kometch.local of the internal domain which is the
stub zone, but when reverse lookup it will be output as block.
kometch@dns02:~$ drill 192.168.122.1 -x
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 43732
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; 1.122.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
;; AUTHORITY SECTION:
blocked. 900 IN SOA blocked. . 0 3600 900 604800 900
;; ADDITIONAL SECTION:
;; Query time: 1 msec
;; SERVER: 192.168.122.223
;; WHEN: Fri Apr 14 22:13:57 2017
;; MSG SIZE rcvd: 86
# kresd.conf
modules = {
'hints > iterate', -- Hints AFTER iterate
'policy > hints', -- Policy AFTER hints
'view < rrcache', -- View BEFORE rrcache
predict = {
window = 30, -- 15 minutes sampling window
period = 24*(60/15) -- track last 6 hours
},
'daf',
'stats'
}
modules.list() -- Check module call order
--stub forward
policy.add(policy.pattern(policy.FORWARD('192.168.122.223@10053',
'192.168.122.224@10053'), '\7kometch\5local'))
In this case, how should it be set?
Best regards.
18 Dub
18 Dub
10:33
Hello.
On 04/14/2017 04:02 PM, Horigome Yoshihito wrote:
I set it up as below and forward it to kometch.local
of the internal
domain which is the stub zone, but when reverse lookup it will be
output as block. [...]
The problem there is that the policy module contains an implicit rule
that blocks reverse queries to private zones (e.g. 192.168.*.*). You
can remove that rule by adding a line `policy.del(0)` to your config.
--Vladimir
13:33
Hello, Vladimír
Thank you for answering.
As you say, adding policy.del(0) no longer gets blocked.
However, it is as follows and ANSWER is not returned.
kometch@dns02:/etc/knot-resolver$ drill -x 192.168.122.223
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 9431
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; 223.122.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
;; AUTHORITY SECTION:
168.192.in-addr.arpa. 604566 IN SOA prisoner.iana.org.
hostmaster.root-servers.org. 1 604800 60 604800 604800
;; ADDITIONAL SECTION:
Do you use view and so on to reverse the 192.168.122.0/24?
I am sorry about all the questions.
Best regards.
On 2017/04/18 17:33:08, Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote:
Hello.
On 04/14/2017 04:02 PM, Horigome Yoshihito wrote:
I set it up as below and forward it to kometch.local
of the internal
domain which is the stub zone, but when reverse lookup it will be
output as block. [...]
The problem there is that the policy module contains an implicit rule
that blocks reverse queries to private zones (e.g. 192.168.*.*). You
can remove that rule by adding a line `policy.del(0)` to your config.
--Vladimir
13:40
On 04/18/2017 01:33 PM, Horigome Yoshihito wrote:
As you say, adding policy.del(0) no longer gets
blocked.
However, it is as follows and ANSWER is not returned.
The config you sent did not forward any reverse address ranges. Adding
rule for that should do what you want, if I guess your intentions correctly:
policy.add(policy.suffix(policy.FORWARD('192.168.122.223@10053',
'192.168.122.224@10053'), '168.192.in-addr.arpa'))
--Vladimir
13:56
Hello, Vladimir
Thank you for answering.
As I advised, I added policy, but it seems that I can not reverse lookup it again.
kometch@dns02:/etc/knot-resolver$ drill -x 192.168.122.223
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 16206
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; 223.122.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
;; AUTHORITY SECTION:
168.192.in-addr.arpa. 604038 IN SOA prisoner.iana.org.
hostmaster.root-servers.org. 1 604800 60 604800 604800
;; ADDITIONAL SECTION:
;; Query time: 1 msec
;; SERVER: 192.168.122.223
;; WHEN: Tue Apr 18 20:51:11 2017
;; MSG SIZE rcvd: 123
I checked the port(10053) with tcpdump, but it seems that no inquiries from kresd have
been done.
Best regards.
On 2017/04/18 20:40:56, Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote:
On 04/18/2017 01:33 PM, Horigome Yoshihito wrote:
As you say, adding policy.del(0) no longer gets
blocked.
However, it is as follows and ANSWER is not returned.
The config you sent did not forward any reverse address ranges. Adding
rule for that should do what you want, if I guess your intentions correctly:
policy.add(policy.suffix(policy.FORWARD('192.168.122.223@10053',
'192.168.122.224@10053'), '168.192.in-addr.arpa'))
--Vladimir
14:02
On 04/18/2017 01:56 PM, Horigome Yoshihito wrote:
As I advised, I added policy, but it seems that I can
not reverse
lookup it again.
Right, I made a mistake in the command :-) This time I tested it tries
to forward the query:
policy.add(policy.suffix(policy.FORWARD('192.168.122.223@10053',
'192.168.122.224@10053'), { todname('168.192.in-addr.arpa') }))
14:08
Hello, Vladimir
It was confirmed by modifying the policy of, as you say, can now be safely reverse
lookup.
I was saved.
Also, learning that the todname function can be used at such times was a study.
Thank you very much.
Best regards.
On 2017/04/18 21:02:50, Vladimír Čunát <vladimir.cunat(a)nic.cz> wrote:
On 04/18/2017 01:56 PM, Horigome Yoshihito wrote:
As I advised, I added policy, but it seems that I can not reverse lookup it again.
Right, I made a mistake in the command :-) This time I tested it tries to forward the
query:
policy.add(policy.suffix(policy.FORWARD('192.168.122.223@10053',
'192.168.122.224@10053'), { todname('168.192.in-addr.arpa') }))
2587
days inactive
2591
days old
6 comments
2 participants
participants (2)
-
Horigome Yoshihito -
Vladimír Čunát