Hi I have an newbie point of view for CNAME cloaking problem.
Using PiHole V5.0
When looking for abs.twimg.com (twitter video and picture host)
host abs.twimg.com
abs.twimg. com is an alias for cs196.wac.edgecastcdn. net.
cs196.wac.edgecastcdn. net is an alias for cs2-wac.apr-8315.edgecastdns .net.
cs2-wac.apr-8315.edgecastdns. net is an alias for cs2-wac-eu.8315.ecdns. net.
cs2-wac-eu.8315.ecdns. net is an alias for cs45.wac.edgecastcdn. net.
cs45.wac.edgecastcdn. net has address 93.184.220.70
cs672.wac.edgecastcdn.net has IPv6 address 2606:2800:134:fa2:1627:1fe:edb:1665
This is lots of redirection (aliasing)
So I have made a static input for abs.twimg .com but this is not a good solution for long term. I can use this ip approx. for 5 days.
host abs.twimg.com
abs.twimg.com has address 93.184.220.70
When the ip for abs.twimg. com changed, this solution will not help. And must be changed manually again.
So is it possible to make this automated.
1- When a CNAME contain a blocked host for aliasing,
2- Make a static input to Custom DNS (for v5.0), if input already exist
3- Control, is this IP adress same with static input, if not
4- Change the static input IP with new one.
I can use it non-automated with high performance. Wish this point of wiev help something. (I am not an DNS enthusiastic so I made a simple solution for my needs)
The entire chain is resolved to the end very quickly by the upstream DNS resolver, so there is little delay. Why not just let the DNS server find the correct IP rather than mapping this locally?
so I was overriding this adresses with unbound on opnsense.
Then I have found that this problem was CNAME Cloaking and can pass my Squid ACL list, Lots of chineese sites using this method for passing firewalls.
(This is not thecnical explanation only my thoughts )
When using "Hardened DNSSEC" option on OpnSense unbound, responses resolved from a different dns resolver than unbound server does not accepted by unbound.
If I understand correctly, your unbound setup does not respond as you would like it to respond. How does CNAME blocking in Pi-Hole relate to this problem?
Look at the manual for unbound.conf on this topic. They note that if you are behind an intrusive firewall you may need to turn off this option:
harden-dnssec-stripped: <yes or no>
Require DNSSEC data for trust-anchored zones, if such data is
absent, the zone becomes bogus. If turned off, and no DNSSEC
data is received (or the DNSKEY data fails to validate), then
the zone is made insecure, this behaves like there is no trust
anchor. You could turn this off if you are sometimes behind an
intrusive firewall (of some sort) that removes DNSSEC data from
packets, or a zone changes from signed to unsigned to badly
signed often. If turned off you run the risk of a downgrade
attack that disables security for a zone. Default is yes.
Unbound can not make CNAME blocking, It sees an external resolver and block everything if I have not override with static ip. Unbound is slow resolver, when you make a change it forgets every cached record (you can also make dump backup of records but not practical)
So I start to test PiHole as DNS Resolver on my system apart from firewall. And I see you were trying to deal with CNAME Cloacking and I have shared my experience. No problem with my PiHole, Only an idea for developing PiHole (maybe).
Why are you using unbound if it does not do what you want it to do? If it is slow and won't resolve, and you are only using it as a forwarder, have you considered using a commercial upstream resolver directly?
Or, have you looked at changing the configuration of unbound so it will resolve CNAMEs?
It appears quite unusual that unbound cannot resolve a CNAME to the end. Here is the output of a dig via unbound (in recursive mode) that shows the complete reply.
I do not need for my self.
Can it help for CNAME Cloaking problem? and block tracking for sites like this.
I also have my simple solution and using it, I have 5 sites like this and maintain them frequently. But this tracking trick is dangerous. I see lots of chineese sites using this method to forward you malware sites. This can be a security layer.
I concur with what @jfb said before. The entire process is not happening in a ping-pong mode. Instead, the upstream server will give you the entire chain, including the end-result at once. And once you did the chain once, everything will be in your local cache, so I can see no advantage in having a local IP short-circuiting here. In contrast, there is much risk with outdated data involved. Pi-hole's internal caching already seems to address this issue entirely.
When an blocked domain found in a CNAME no answer given for ip. All alias chain blocked, and ip result blocked.
My point was this. If a blocked domain found in a CNAME and the asked domain is not in a blocked list automated ip mapping can help.
As I said before I am not an expert. Only an emd user with questions.
Thanks,
What is your end goal. Tell us what it is that you want to do, and we can try to understand and see if it's something possible and compliant with RFCs.
Edit:
From what I can understand you are trying to optimize things where there is no room for optimization. Your client requests abs.twimg.com from Pi-hole, this is one query. Pi-hole doens't have it in cache or available so it asks it's upstream for that domain to IP match. One request. The upstream responds with a single message that contains the entire chain. One message.
dig abs.twimg.com
; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> abs.twimg.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42220
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;abs.twimg.com. IN A
;; ANSWER SECTION:
abs.twimg.com. 296 IN CNAME cs196.wac.edgecastcdn.net.
cs196.wac.edgecastcdn.net. 358 IN CNAME cs2-wac.apr-8315.edgecastdns.net.
cs2-wac.apr-8315.edgecastdns.net. 44 IN CNAME cs2-wac-us.8315.ecdns.net.
cs2-wac-us.8315.ecdns.net. 44 IN CNAME cs45.wac.edgecastcdn.net.
cs45.wac.edgecastcdn.net. 1056 IN A 72.21.91.70
;; Query time: 7 msec
;; SERVER: 2001:4860:4860::8844#53(2001:4860:4860::8844)
;; WHEN: Thu Mar 26 02:02:50 UTC 2020
;; MSG SIZE rcvd: 195
There is no way to shave of nanoseconds from the process by trying to short circuit the upstream response. It doesn't matter if there Answer section is:
;; ANSWER SECTION:
abs.twimg.com. 296 IN CNAME cs196.wac.edgecastcdn.net.
cs196.wac.edgecastcdn.net. 358 IN CNAME cs2-wac.apr-8315.edgecastdns.net.
cs2-wac.apr-8315.edgecastdns.net. 44 IN CNAME cs2-wac-us.8315.ecdns.net.
cs2-wac-us.8315.ecdns.net. 44 IN CNAME cs45.wac.edgecastcdn.net.
cs45.wac.edgecastcdn.net. 1056 IN A 72.21.91.70
or
;; ANSWER SECTION:
abs.twimg.com. 296 IN A 72.21.91.70
I perfectly agree. The only thing we could do here is re-writing the packet itself. While this would reduce the payload by about 300 bytes in this case (not too convincing), it would certainly add extra processing time (and code complexity!) as we would first have to discard the already ready-to-be-sent package in order to construct our own reply with just the A record. Just saying, doing this is much more complicated than the (human-readable!) output of dig suggests. The DNS reply is not a chain of text as shown here, but a binary protocol containing checksums, etc. which we would need to compute for self-crafted DNS records + replies.
)
