18 Zář
2024
18 Zář
'24
11:04
Hello,
we are observing that Knot-resolver is refusing certain queries because
of enabled DNS rebinding protection to subdomains beneath apple.com.
IMHO there is no reason for that - they are not pointing to a private
addres range. For instance:
Unbound:
dig init.ess.apple.com @127.0.0.1 -p 53
; <<>> DiG 9.18.24-1-Debian <<>> init.ess.apple.com @127.0.0.1 -p
53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38044
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;init.ess.apple.com. IN A
;; ANSWER SECTION:
init.ess.apple.com. 81 IN CNAME
init-cdn-lb.ess-apple.com.akadns.net.
init-cdn-lb.ess-apple.com.akadns.net. 27 IN CNAME init.ess.g.aaplimg.com.
init.ess.g.aaplimg.com. 12 IN A 17.253.73.204
init.ess.g.aaplimg.com. 12 IN A 17.253.73.205
init.ess.g.aaplimg.com. 12 IN A 17.253.73.203
init.ess.g.aaplimg.com. 12 IN A 17.253.73.201
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Wed Sep 18 10:42:46 CEST 2024
;; MSG SIZE rcvd: 194
Knot-resolver 5.7.4-cznic.1 freshly re-installed:
dig init.ess.apple.com @127.0.0.1 -p 2053
; <<>> DiG 9.18.24-1-Debian <<>> init.ess.apple.com @127.0.0.1 -p
2053
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 17074
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 18 (Prohibited): (EIM4)
;; QUESTION SECTION:
;init.ess.apple.com. IN A
;; ADDITIONAL SECTION:
explanation.invalid. 10800 IN TXT "blocked by DNS
rebinding protection"
;; Query time: 8 msec
;; SERVER: 127.0.0.1#2053(127.0.0.1) (UDP)
;; WHEN: Wed Sep 18 10:45:40 CEST 2024
;; MSG SIZE rcvd: 124
I have also tried to remove the cache under /var/cache/knot-resolver but
without any effect. There are more domain names with this beavior:
query.ess.apple.com
comm-cohort.ess.apple.com
kt-prod.ess.apple.com
Thanks.
Ales Rygl
18 Zář
18 Zář
14:57
On 18/09/2024 11.04, Aleš Rygl wrote:
So I turned on debug logging by log_groups({'rebind'}) and it looks
blocked correctly:
[rebind][02941.10] blocking blacklisted IP in RR
'mressext-axfrdnsvip.mr.if.apple.com. 43200 A 10.52.195.168'
Note that the module is sensitive even about records that might not get
into the final answer sent to the client.
--Vladimir
15:02
On Wed, Sep 18, 2024 at 02:57:22PM +0200,
Vladimír Čunát via knot-resolver-users <knot-resolver-users(a)lists.nic.cz> wrote
a message of 73 lines which said:
So I turned on debug logging by
log_groups({'rebind'}) and it looks blocked
correctly:
...
Note that the module is sensitive even about records
that might not get into
the final answer sent to the client.
It seems a bad idea to remove all the answers if there is even one RFC
1918 address in the set. (Unless may be if it is signed.)
15:15
On 18/09/2024 15.02, Stephane Bortzmeyer wrote:
It seems a bad idea to remove all the answers if there
is even one RFC
1918 address in the set. (Unless may be if it is signed.)
I'm not sure. The design choice at that point was to avoid modifying
any record sets and instead just "fail safely". Though maybe the main
reason was that it was simpler to implement in our case if it should
include avoiding this case of referrals to local IPs.
Either way, those delegations do seem in disarray. dig + trace also
complains with lines like
;; BAD (HORIZONTAL) REFERRAL
;; communications error to 10.52.192.140#53: network unreachable
15:22
On 18. 09. 24 15:15, Vladimír Čunát via knot-resolver-users wrote:
I'm not sure. The design choice at that point was
to avoid modifying
any record sets and instead just "fail safely". Though maybe the main
reason was that it was simpler to implement in our case if it should
include avoiding this case of referrals to local IPs.
Either way, those delegations do seem in disarray. dig + trace also
complains with lines like
;; BAD (HORIZONTAL) REFERRAL
;; communications error to 10.52.192.140#53: network unreachable
--
Unfortunatelly it leads to a massive traffic amplification with real
clients. Because of RCODE 5 they keeps retrying... I had to disable
rebinding protection completely in order to make the network stable.
Refusing them is not a good idea if you have a large deployment.
1
days inactive
1
days old
knot-resolver-users@lists.nic.cz
4 comments
3 participants
participants (3)
-
Aleš Rygl -
Stephane Bortzmeyer -
Vladimír Čunát