Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added specific domain forwarding to other name server #5096

Open
wants to merge 1 commit into
base: development
Choose a base branch
from

Conversation

ImDaBigBoss
Copy link

@ImDaBigBoss ImDaBigBoss commented Dec 28, 2022

What does this PR aim to accomplish?:

This PR is made so you can create a list of domains that would be forwarded to a different name server.
This is useful if you have run Pi-hole but don't maintain the internal domains. For example, you are on a network that relies on services that use domain names, domain names that are issued internally by a DNS server that you don't control. If you still want access to these local domains, what they point to and their subdomains, you can do so without relying on that DNS server for all requests.
It also applies to VLANs and their hostname resolution (https://discourse.pi-hole.net/t/multiple-subnets-vlans-and-hostname-resolution/31746)

How does this PR accomplish the above?:

Much like the DNS records (A/AAAA records) or the CNAME records, this adds a section under "Local DNS" where you can register domain forwarding.
This creates a new file in the dnsmasq directory and adds server=/my.domain/1.2.3.4 into it.

Link documentation PRs if any are needed to support this PR:

None


By submitting this pull request, I confirm the following:

  1. I have read and understood the contributors guide, as well as this entire template. I understand which branch to base my commits and Pull Requests against.
  2. I have commented my proposed changes within the code and I have tested my changes.
  3. I am willing to help maintain this change if there are issues with it later.
  4. It is compatible with the EUPL 1.2 license
  5. I have squashed any insignificant commits. (git rebase)
  6. I have checked that another pull request for this purpose does not exist.
  7. I have considered, and confirmed that this submission will be valuable to others.
  8. I accept that this submission may not be used, and the pull request closed at the will of the maintainer.
  9. I give this submission freely, and claim no ownership to its content.

  • I have read the above and my PR is ready for review. Check this box to confirm

Signed-off-by: ImDaBigBoss <67973871+ImDaBigBoss@users.noreply.github.com>
@ImDaBigBoss
Copy link
Author

This depends on #2471

@PromoFaux
Copy link
Member

Echo comments: pi-hole/web#2471 (comment)

@jpgpi250
Copy link
Contributor

jpgpi250 commented Mar 10, 2023

If I understand this correctly, I've been doing this for a very long time, with an additional /etc/dnsmasq.d file, entries like:

server=/b2discourse.b-cdn.net/127.10.10.5#5555
server=/b2discourse.pi-hole.net/127.10.10.5#5555

127.10.10.5#5555 being knot-resolver, also running on my pi, the default upstream resolver is unbound (127.10.10.2#5552)

however....

In the files changed section of this PR, I noticed this code uses RestartDNS to apply the changes, If I'm correct RestartDNS actually does service pihole-FTL restart. This is totally unnecessary.
the dnsmasq man page states:

--servers-file=<file>
A special case of --conf-file which differs in two respects. Firstly, only --server and --rev-server are allowed in the configuration file included. Secondly, the file is re-read and the configuration therein is updated when dnsmasq receives SIGHUP.

this implies adding a configuration line (I added this line in a separate config file - could be added to 01-pihole.conf):

servers-file=/etc/dnsmasq.d/07-pihole-custom-ns.conf

doesn't require RestartDNS but would activate the changes, using RestartDNS reload which actually does:

kill -HUP ${pid}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants