Automated CNAME mapping to an IP

Hi I have an newbie point of view for CNAME cloaking problem.
Using PiHole V5.0

When looking for (twitter video and picture host)

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 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 has address

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)

Thanks for yout time and efforts for project.

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?

1 Like

Open a Feature Request. Not a high chance of it being implemented but that's a better place to discuss.

I also have an firewall (opnsense) and using DNSSEC and Hardened DNSSEC with unbound. And Unbound blocking adresses like this.
abs. and

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.

Thanks for advance,

How/why is unbound blocking these domains? I don't understand how unbound and your firewall are impacted by CNAME behavior in Pi-hole.

(This is not thecnical explanation only my thoughts :slight_smile: )

When using "Hardened DNSSEC" option on OpnSense unbound, responses resolved from a different dns resolver than unbound server does not accepted by unbound.

On what platform are you running unbound? Is unbound running as a recursive resolver, or as a forwarding resolver?

OpnSense Hardened BSD,
Using as forwarding resolver with "DNSSEC" and "Hardened DNSSEC" activated.

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.
1 Like

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).

Only my two Cents,

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.

dig +short

Using Unbounds Override feature,
Using Unbound for blocking with Squid (because squid is passed with this cname trick if it used without Unbound)

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. problem is same with my situation.

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.

1 Like

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.

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.


From what I can understand you are trying to optimize things where there is no room for optimization. Your client requests 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 9.11.3-1ubuntu1.11-Ubuntu <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42220
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;                 IN      A

;; ANSWER SECTION:          296     IN      CNAME 358  IN      CNAME 44 IN CNAME 44   IN      CNAME 1056  IN      A

;; 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:          296     IN      CNAME 358  IN      CNAME 44 IN CNAME 44   IN      CNAME 1056  IN      A


;; ANSWER SECTION:          296     IN        A

None. You gain nothing.

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.

1 Like

Thnaks to nextdns for answer to my long term question.

CNAME Flattining was my need.