Domain rewriting


Didn´t found anything in the category of "Feature request" so I am creating this topic now. :slight_smile:

I would love to a possibillity to rewrite a domain. In a professional term it´s NATing. I am missing the feature to change a domain to another. For example: If my mobile is requesting the page for, I would like to redirect it to I want this to have a single source of time and to minimize differences between,, etc... Because PiHole is a DNS-Server, it´s not needed to have a port based NATing. A redirection, based on my manual redirection-Entrys would be create.

Did you get the idea of my request? I know, that "Adguard" does provide this feature, but PiHole works better for me. So I really want this feature for piHole!

Actually, pihole can do this to, because it is based on dnsmasq. Most people forget they can always use features from dnsmasq by simply creating an additional conf file in /etc/dnsmasq.d

Read the dnsmasq man page, in order to find out what it can do for you.

To solve your problem, this works (tested). There are multiple ways to achieve this!
Create a file (DON'T add anything to 01-pihole.conf, it will be overwritten by 'pihole -up' and 'pihole -r') /etc/dnsmasq.d/xx-myconf.conf (xx is any free number, optional, all conf files are processed), content:


restart pihole-FTL




change time.localdomain into your desired domain name, change the IP address into your time source IP address

check the dnsmasq man page for a detailed explanation of what is happening, after you configured this (search for --address=).

1 Like

The time provider stated "never configure fixed ip-addresses". So, do i need to tell him already an IP or is the ip-param optional? it is just an example... I think, I will cover much more with this in the future.

The IP address is NOT optional.

This is correct for external NTP sources, the IP might change, this is not under your control.
If you're using internal NTP sources (for example, you're pi is configured to be an NTP source), this becomes only a problem if your pi's IP address changes, which, under normal circumstances, it never does.

So, configure your internal time server(s) to use domains, configure you're clients, that use the internal server(s) with the IP (or use the dnsmasq configuration - see above).

using IP's as opposed to domain names, requires discipline (or static entries, MAC address based, on your DHCP server).

1 Like

The IP address is NOT optional.

That is really bad, because I just have a FQDN of the other time-provider. And brings me back to my feature-request. I would like to have the possibillity to change a domain to another. In this case, rewrite and to

I would like this feature for more usecases than this NTP-Thing...

This is correct for external NTP sources

configure your internal time server(s)

I don´t have any internal NTPs and I don´t want to maintain any internalNTP.

And of course, the NTPUseCase is just one of many cases, that I need the possibility to redirect a Domain to another.

...I updated my introductional post to overome these misunderstanding.

to achieve redirection without IP address, use,time.localdomain

change time.localdomain into your desired domain name, again see the dnsmasq man page

Thanks again!
Because I think you´re a native english speaker, maybe you can tell me, if this is the right achivement:

Man page of DNSMASQ (
There is a significant limitation on the target; it must be a DNS record which is known to dnsmasq and NOT a DNS record which comes from an upstream server

So I think, rewriting to (for example) wouldn´t work, because Pihole had to do the following

Client: Who is
PiHole: It is
Client: Who is
PiHole: ....

So the DNSRecord comes from a upstream dns, doesn´t it? So this solution would be wrong!?

correct, works only for known addresses. so, currently no solution, without specifying an IP, or running an internal NTP server...

This is the reason, why I am starting this feature request! WTF! Would be great if someone could implement this. I mean, adguard seems to have a solution!

Maybe with a database again. And if this domain is in the "redirect-db" replace the requested string (aka FQND) with the domain in the corresponding string.

The problem is that this won't actually work in most cases. has to know that it will be addressed as and respond in the proper way. This might be functional for something like NTP that doesn't care what FQDN it is but for any other service it will fail hard.

The common example is to try to redirect to Problem is that your browser is going to request and get back an IP for has no idea who is and will respond with an HTTP error. Even if you could find some way of correcting that error you'd then end up with TLS issues since impersonation is near impossible unless you start to mess with certificates.

And as we note on the CNAME webpage, you can only CNAME to a domain that Pi-hole is authoritative to.

The example case you describe breaks a few RFCs and really only works because of how NTP works.

1 Like

There shouldn't actually be any differences between them. And if there are, it's on the order of nanoseconds and something that truly will never be of any effect to you.


No, NAT is a different thing. NAT is taking a packet with the IP of in it's header and mangling the packet to put in it's place and then updating the header checksum.

Blockquote has no idea who is and will respond with an HTTP error.
Why? doesn´t have to know who is. I don´t get, why it would fail hard.

I´ve got the chance to play with a coporate compatible FireWall. And changing one FQDN to another (on ports based) was in the category of "NAT". I know. NATing is normally for changing many private IPs to one public IP...

Because every request would be for and sent to the IP address of the server that handles Your browser isn't going to change every URL from to or to The webserver at is going to tell you that it has no idea who or what is.

Since you mention that AdGuard has the feature, try it. Try to rewrite the domains and see what actually happens. Without a proxy to rewrite the html and URLs, it won't work. And with TLS involved you'd have to create a new TLS certificate and Certificate Authority that lets you impersonate domains. That means MITM and is a really dangerous thing to do.

I don't quite see what ports have to do with FQDNs.

Not really, it's just changing one IP for another. Doesn't matter the IP. Consumer routers do that for home users without routeable IP address space but it's really pretty common for internetworking.

If I am saying is redirecting to

My imagination, what will happen, if I am visiting

  1. Client will ask the pihole "who is"
  2. PiHole will reply, "I am told, that I should answer with everytime, I am asked for I don´t know who is, I will ask a upstream dns.
  3. Upstream DNS will answer, I don´t know who it is, I am going to ask the .com-Rootserver.
  4. RootServer will reply, "go, ask,, that is the responsible NS for"
  5. PiHole asks, "Who is"
  6. NS for google, will reply, " is"
  7. PiHole will answer my client "The IP you´re looking for is"
  8. My client will do it´s job: "Okay, I am opening"

Your imagination is incorrect. If there was a way to do Step 3 then this is the flow.

  1. Client asks "I want".
  2. Client resolves via Pi-hole.
  3. Pi-hole sees request for, substitutes IP address for
  4. Client sends http request for to server at the IP address for

You're confusing TCP/IP | OSI layers. Your step 8 doesn't exist. The browser doesn't send to an IP address. And again, even if it did, it's not going to take /index.html and convert <a href> tags from FQDN to FQDN. And even if it could it's not going to accept the certificate that signed the traffic as one FQDN to be valid for a completely different FQDN.

To your step 4:
I thought, it will take the IP, that it was given from pihole. In my example. So the request will be: "Hey 2.0.0., give me your index.html" Or in the case of this post "Hey, please give me your t/domain-rewriting/46352/16.html" So I am asking for a case, where the folder-path is the same, only the domain is different -> and
So, there should be no need, to convert <a href>.
I am exclusivly speaking for http and not for https.

I really thought, that "" is just a human-readable label and the PC is instead asking

No, that's not how it works.

For TLS, there is SNI

You can use but that's generally not how webservers are configured to run.

Edit: A bit more on HTTP requests:

Try it, you said, so I did, because I'm NOT happy with users that say AGH can do what pihole can't.

I setup an AGH, some basic configuration, nothing fancy, and defined a DNS Rewrite (it has that option). I defined the domain to be redirected to

this is what dig says, after saving.

dig @

; <<>> DiG 9.16.4 <<>> @
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11006
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:        10      IN      CNAME         110     IN      A

;; Query time: 7 msec
;; WHEN: Sat Apr 17 19:02:35 Romance Daylight Time 2021
;; MSG SIZE  rcvd: 85

Dig does return an IP address!

and this is what firefox says...

after hitting advanced and "accept the risk and continue", the duckduckgo page opened.

Doesn't look like something I want to do all day....

Now I tried NTP, using this tool
I defined another DNS rewrite, -> pfsense.localdomain (NOT defined on AGH, but on the upstream, e.g. pihole)

Again, dig shows it is a simple CNAME, but the redirection works, there is actually an IP in the reply. The NTP tools shows correct results, the pihole query log shows a query for pfsense.localdomain.

In conclusion, the AGH feature works for some protocols, like NTP, but is useless to redirect HTTPS trafic. Looks like the AGH CNAME implementation doesn't have the requirement, the redirect domain needs to be defined on the local system, dnsmasq does...