请教各位下对这种x.x.x.x.in-addr.arpa域名的请求正确的处理方式是什么？ #39

mkanako · 2021-01-15T08:13:26Z

mkanako
Jan 15, 2021

看日志出现不少这种请求

2021-01-15T15:49:18.254+0800	warn	dns_server	handler/server.go:83	entry returned an err	{"query": "250.255.255.239.in-addr.arpa. 12 1 6781 1713", "error": "dns_diversion: forward_local: no response"}
2021-01-15T15:59:19.404+0800	warn	dns_server	handler/server.go:83	entry returned an err	{"query": "251.0.0.224.in-addr.arpa. 12 1 44152 1777", "error": "dns_diversion: forward_local: no response"}
2021-01-15T15:59:20.295+0800	warn	dns_server	handler/server.go:83	entry returned an err	{"query": "250.255.255.239.in-addr.arpa. 12 1 10260 1778", "error": "dns_diversion: forward_local: no response"}

mosdns我是装在本地自己用而已，不太明白这是谁发的请求，我应该是直接屏蔽掉还是转发个网关处理？
如果转发个网关，但网关还不是固定的，可能192.168.1.1或者192.168.0.1.。。。连不同网络网关都不一样，很疑惑不知道该怎么处理比较好

Answered by laggardkernel

Jan 16, 2021

Update 1: 配置方案放在了最后

这是 PTR (Pointer to a canonical name) 记录查询，查询对应于某个 IP 的 host 名。我把 mosdns 作为了 dnsmasq 的下游，并在 dnsmasq 开启了 log。根据 dnsmasq 中记录的查询日志，常见的 PTR 查询有以下几种（本地路由器网段 192.168.2.x）

# 反查 192.168.2.1 路由器域名
Jan 16 00:43:51 dnsmasq[39918]: 20643 127.0.0.1/60387 query[PTR] 1.2.168.192.in-addr.arpa from 127.0.0.1

# 224.0.0.251 是 multicast DNS 组播地址，多办由 macOS 上 mDNSResponser 发起，反查组播的域名？
Jan 16 01:23:53 dnsmasq[39918]: 21265 127.0.0.1/50233 query[PTR] 251.0.0.224.in-addr.arpa from 127.0.0.1

# 239.255.255.250是SSDP（简单服务发现协议），UPNP服务使用。和上边差不多，查询 SSDP 服务对应域名
Jan 16 00:43:52 dnsmasq[39918]: 20645 127.0.0.1/65052 query[PTR] 250.255.255.239.in-addr.arpa from 127.0.0.1

# DNS Service Discovery (DNS-S…

View full answer

IrineSistiana · 2021-01-16T05:05:27Z

IrineSistiana
Jan 16, 2021
Maintainer

我也不清楚....我是直接没管....

0 replies

laggardkernel · 2021-01-16T07:12:18Z

laggardkernel
Jan 16, 2021

Update 1: 配置方案放在了最后

这是 PTR (Pointer to a canonical name) 记录查询，查询对应于某个 IP 的 host 名。我把 mosdns 作为了 dnsmasq 的下游，并在 dnsmasq 开启了 log。根据 dnsmasq 中记录的查询日志，常见的 PTR 查询有以下几种（本地路由器网段 192.168.2.x）

# 反查 192.168.2.1 路由器域名
Jan 16 00:43:51 dnsmasq[39918]: 20643 127.0.0.1/60387 query[PTR] 1.2.168.192.in-addr.arpa from 127.0.0.1

# 224.0.0.251 是 multicast DNS 组播地址，多办由 macOS 上 mDNSResponser 发起，反查组播的域名？
Jan 16 01:23:53 dnsmasq[39918]: 21265 127.0.0.1/50233 query[PTR] 251.0.0.224.in-addr.arpa from 127.0.0.1

# 239.255.255.250是SSDP（简单服务发现协议），UPNP服务使用。和上边差不多，查询 SSDP 服务对应域名
Jan 16 00:43:52 dnsmasq[39918]: 20645 127.0.0.1/65052 query[PTR] 250.255.255.239.in-addr.arpa from 127.0.0.1

# DNS Service Discovery (DNS-SD) ，这个不清除是怎么工作的
Jan 16 00:35:21 dnsmasq[39918]: 20477 127.0.0.1/60195 query[PTR] b._dns-sd._udp.0.2.168.192.in-addr.arpa from 127.0.0.1

对于常见的反向查询，某些 DNS 服务（如 unbound）默认对这些地址返回不存在的信息。这在 unbound.conf manual 有提示用户可以反注释掉对应内容，以便配置自定义响应。

unbound.conf 中某些默认 local-zone，针对 PTR 和一些保留地址的请求处理

	# By default, for a number of zones a small default 'nothing here'
	# reply is built-in.  Query traffic is thus blocked.  If you
	# wish to serve such zone you can unblock them by uncommenting one
	# of the nodefault statements below.
	# You may also have to use domain-insecure: zone to make DNSSEC work,
	# unless you have your own trust anchors for this zone.
	# local-zone: "localhost." nodefault
	# local-zone: "127.in-addr.arpa." nodefault
	# local-zone: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." nodefault
	# local-zone: "onion." nodefault
	# local-zone: "test." nodefault
	# local-zone: "invalid." nodefault
	# local-zone: "10.in-addr.arpa." nodefault
	# local-zone: "16.172.in-addr.arpa." nodefault
	# local-zone: "17.172.in-addr.arpa." nodefault
	# local-zone: "18.172.in-addr.arpa." nodefault
	# local-zone: "19.172.in-addr.arpa." nodefault
	# local-zone: "20.172.in-addr.arpa." nodefault
	# local-zone: "21.172.in-addr.arpa." nodefault
	# local-zone: "22.172.in-addr.arpa." nodefault
	# local-zone: "23.172.in-addr.arpa." nodefault
	# local-zone: "24.172.in-addr.arpa." nodefault
	# local-zone: "25.172.in-addr.arpa." nodefault
	# local-zone: "26.172.in-addr.arpa." nodefault
	# local-zone: "27.172.in-addr.arpa." nodefault
	# local-zone: "28.172.in-addr.arpa." nodefault
	# local-zone: "29.172.in-addr.arpa." nodefault
	# local-zone: "30.172.in-addr.arpa." nodefault
	# local-zone: "31.172.in-addr.arpa." nodefault
	# local-zone: "168.192.in-addr.arpa." nodefault
	# local-zone: "0.in-addr.arpa." nodefault
	# local-zone: "254.169.in-addr.arpa." nodefault
	# local-zone: "2.0.192.in-addr.arpa." nodefault
	# local-zone: "100.51.198.in-addr.arpa." nodefault
	# local-zone: "113.0.203.in-addr.arpa." nodefault
	# local-zone: "255.255.255.255.in-addr.arpa." nodefault
	# local-zone: "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." nodefault
	# local-zone: "d.f.ip6.arpa." nodefault
	# local-zone: "8.e.f.ip6.arpa." nodefault
	# local-zone: "9.e.f.ip6.arpa." nodefault
	# local-zone: "a.e.f.ip6.arpa." nodefault
	# local-zone: "b.e.f.ip6.arpa." nodefault
	# local-zone: "8.b.d.0.1.0.0.2.ip6.arpa." nodefault
	# And for 64.100.in-addr.arpa. to 127.100.in-addr.arpa.

说一下怎么解决：可以放着不管，但默认情况下把局域网内的发现服务请求发送到外网总感觉有点怪怪的。建议还是匹配到这些请求就拒绝掉或者返回 NXDOMAIN.

我对 PTR 和 mDNS, DNS-SD 也不是非常了解。只是大致知道这些 PTR 请求是和那些服务有关。哪里说得不对还请指正。

只给出了部分必要配置，根据情况套用即可。

  - tag: chinadns_before_request
    type: sequence
    args:
      exec:
        # pre-process
        - if:
          - match_local_ptr
          exec:
            # 不确定 nxdomain 响应是否合适
            - _block_with_nxdomain
          goto: _end
        # 后续略


  - tag: match_local_ptr
    type: query_matcher
    args:
      logical_and: true
      # 保险起见，只匹配了 PTR 请求
      qtype: [12]
      domain:
        - ./local-ptr.raw.txt

local-ptr.raw.txt

# from unbound.conf
127.in-addr.arpa
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
onion
test
invalid
10.in-addr.arpa
16.172.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
168.192.in-addr.arpa
0.in-addr.arpa
254.169.in-addr.arpa
2.0.192.in-addr.arpa
100.51.198.in-addr.arpa
113.0.203.in-addr.arpa
255.255.255.255.in-addr.arpa
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
d.f.ip6.arpa
8.e.f.ip6.arpa
9.e.f.ip6.arpa
a.e.f.ip6.arpa
b.e.f.ip6.arpa
8.b.d.0.1.0.0.2.ip6.arpa
# 100.64.0.0/10 保留地址
64.100.in-addr.arpa
65.100.in-addr.arpa
66.100.in-addr.arpa
67.100.in-addr.arpa
68.100.in-addr.arpa
69.100.in-addr.arpa
70.100.in-addr.arpa
71.100.in-addr.arpa
72.100.in-addr.arpa
73.100.in-addr.arpa
74.100.in-addr.arpa
75.100.in-addr.arpa
76.100.in-addr.arpa
77.100.in-addr.arpa
78.100.in-addr.arpa
79.100.in-addr.arpa
80.100.in-addr.arpa
81.100.in-addr.arpa
82.100.in-addr.arpa
83.100.in-addr.arpa
84.100.in-addr.arpa
85.100.in-addr.arpa
86.100.in-addr.arpa
87.100.in-addr.arpa
88.100.in-addr.arpa
89.100.in-addr.arpa
90.100.in-addr.arpa
91.100.in-addr.arpa
92.100.in-addr.arpa
93.100.in-addr.arpa
94.100.in-addr.arpa
95.100.in-addr.arpa
96.100.in-addr.arpa
97.100.in-addr.arpa
98.100.in-addr.arpa
99.100.in-addr.arpa
100.100.in-addr.arpa
101.100.in-addr.arpa
102.100.in-addr.arpa
103.100.in-addr.arpa
104.100.in-addr.arpa
105.100.in-addr.arpa
106.100.in-addr.arpa
107.100.in-addr.arpa
108.100.in-addr.arpa
109.100.in-addr.arpa
110.100.in-addr.arpa
111.100.in-addr.arpa
112.100.in-addr.arpa
113.100.in-addr.arpa
114.100.in-addr.arpa
115.100.in-addr.arpa
116.100.in-addr.arpa
117.100.in-addr.arpa
118.100.in-addr.arpa
119.100.in-addr.arpa
120.100.in-addr.arpa
121.100.in-addr.arpa
122.100.in-addr.arpa
123.100.in-addr.arpa
124.100.in-addr.arpa
125.100.in-addr.arpa
126.100.in-addr.arpa
127.100.in-addr.arpa

保险起见，只匹配了 PTR 请求和 PTR 相关 domain。单个人觉得匹配 A, AAAA，顺便反注释掉列表中 onion, test, invalid 等保留域名也没什么问题。

对应的 debug 日志，可以看到已经拦截后返回 NXDOMAIN

# 接收到 PTR 请求
2021-01-27T17:16:01.928+0800	debug	chinadns_server	server/udp.go:86	new query	{"query": "1.2.168.192.in-addr.arpa. 12 1 3444 16", "from": "127.0.0.1:49318"}
2021-01-27T17:16:01.928+0800	debug	chinadns_server	utils/server_handler.go:81	exec entry	{"query": "1.2.168.192.in-addr.arpa. 12 1 3444 16", "entry": "chinadns_entry"}
2021-01-27T17:16:01.928+0800	debug	chinadns_entry	utils/executable_sequence.go:47	exec executable plugin	{"query": "1.2.168.192.in-addr.arpa. 12 1 3444 16", "exec": "match_hosts"}
2021-01-27T17:16:01.928+0800	debug	chinadns_entry	utils/executable_sequence.go:47	exec executable plugin	{"query": "1.2.168.192.in-addr.arpa. 12 1 3444 16", "exec": "chinadns_before_request"}
2021-01-27T17:16:01.928+0800	debug	chinadns_before_request	utils/executable_sequence.go:137	exec matcher plugin	{"query": "1.2.168.192.in-addr.arpa. 12 1 3444 16", "exec": "match_block_domain", "result": false}
# 这里开始匹配到 PTR 并执行 _block_with_nxdomain
2021-01-27T17:16:01.928+0800	debug	chinadns_before_request	utils/executable_sequence.go:137	exec matcher plugin	{"query": "1.2.168.192.in-addr.arpa. 12 1 3444 16", "exec": "match_local_ptr", "result": true}
2021-01-27T17:16:01.928+0800	debug	chinadns_before_request	utils/executable_sequence.go:47	exec executable plugin	{"query": "1.2.168.192.in-addr.arpa. 12 1 3444 16", "exec": "_block_with_nxdomain"}
2021-01-27T17:16:01.928+0800	debug	chinadns_before_request	utils/executable_sequence.go:627	goto plugin	{"query": "1.2.168.192.in-addr.arpa. 12 1 3444 16", "goto": "_end"}
# 响应结果
2021-01-27T17:16:01.928+0800	debug	chinadns_server	utils/server_handler.go:87	entry returned	{"query": "1.2.168.192.in-addr.arpa. 12 1 3444 16", "status": "rejected"}