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

Improve conditional forwarding settings #1208

Merged
merged 5 commits into from
Jul 2, 2020
Merged

Improve conditional forwarding settings #1208

merged 5 commits into from
Jul 2, 2020

Conversation

DL6ER
Copy link
Member

@DL6ER DL6ER commented Apr 9, 2020

By submitting this pull request, I confirm the following:

  • I have read and understood the contributors guide, as well as this entire template.
  • I have made only one major change in my proposed changes.
  • I have commented my proposed changes within the code.
  • I have tested my proposed changes, and have included unit tests where possible.
  • I am willing to help maintain this change if there are issues with it later.
  • I give this submission freely and claim no ownership.
  • It is compatible with the EUPL 1.2 license
  • I have squashed any insignificant commits. (git rebase)

What does this PR aim to accomplish?:

"Conditional forwarding" can be used to tell FTL to send queries to local devices (either with a local domain) and PTR requests for private ranges to a dedicated device (typically the router of the network) instead of the configured upstreams.
While this works for most users, it is not very flexible, as it implies three severe limitations (assuming the router is 10.1.2.3):

  • It is limited to IPv4
  • It automatically assumes a Class D network. i.e. 10.1.2.0/24. This is often correct (typically for 192.168.x.0/24 networks, but may also be wrong!
  • It requires the subnet to be the same Class D network the router is in (this may be a fair assumption, however).

How does this PR accomplish the above?:

This PR aims at making conditional forwarding more flexible.

  • It supports IPv4 and IPv6
  • It adds a dedicated box for the local subnet to be used (can be, e.g., 10.0.0.0/8 in above's example)
  • The router can be specified independently of the subnet, it could even be a foreign device (like "ask 13.225.3.2 for all IPs in range 10.0.0.0/8).

Screenshot from 2020-04-09 09-25-46

This feature is intended for Pi-hole v5.1 to ensure we have proper time for testing once it hits development

What documentation changes (if any) are needed to support this PR?:

It has to be checked whether/where we document conditional forwarding.

@DL6ER DL6ER added this to the v5.1 milestone Apr 9, 2020
@DL6ER DL6ER requested a review from a team April 9, 2020 07:27
@LordFlashmeow
Copy link

You've given detailed instructions on how to set it up for IPv4, but nothing for IPv6. Is any documentation going to be added for that?

@DL6ER
Copy link
Member Author

DL6ER commented May 22, 2020

Hmmm, do we really need it? It is basically the same thing with the some exception of you using an IPv6 address.

@DL6ER
Copy link
Member Author

DL6ER commented May 22, 2020

Also: I submitted a patch some longer time ago to the dnsmasq mailing list which removed the limitations on the allowed CIDR size, however, no response to this as of yet.

@LordFlashmeow
Copy link

My only concern is that IPv6 is a bit of a mystery compared to IPv4 (at least for me).

When I was looking for a way to set up conditional forwarding IPv6, all the discourse posts used a ULA in addition to the router's IP like this

Assume your ipv6 ULA-Prefix is fd0a:1234:5678::/48
also assume fd0a:1234:5678::1 is router’s ipv6 address

Add an entry into /etc/dnsmasq.d/01-pihole.conf as follows:

server=/8.7.6.5.4.3.2.1.a.0.d.f.ip6.arpa/fd0a:1234:5678::1

Sorry if I'm missing something, but would the ULA be unneeded with this update?

@pralor-bot
Copy link

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/ula-is-recursively-not-resolved/17711/8

@pralor-bot
Copy link

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/ipv6-conditional-forwarding/21541/4

@DL6ER
Copy link
Member Author

DL6ER commented Jun 4, 2020

@LordFlashmeow

Sorry if I'm missing something, but would the ULA be unneeded with this update?

No, you would simple enter

Screenshot from 2020-06-04 08-42-42

@LordFlashmeow
Copy link

Ok, in theory that makes sense. In practice, I guess we’ll see... :)

@DL6ER DL6ER force-pushed the new/rev-server branch from 3ccfcb4 to 540ebdd Compare June 4, 2020 07:25
@PromoFaux PromoFaux requested a review from XhmikosR June 4, 2020 17:03
settings.php Outdated Show resolved Hide resolved
settings.php Outdated Show resolved Hide resolved
@XhmikosR
Copy link
Contributor

XhmikosR commented Jun 4, 2020

I haven't tested this, just some general markup comments :)

settings.php Show resolved Hide resolved
Co-authored-by: Adam Warner <[email protected]>
@DL6ER DL6ER requested a review from PromoFaux June 23, 2020 19:26
@DL6ER DL6ER dismissed PromoFaux’s stale review June 23, 2020 19:27

Changes were made

@PromoFaux PromoFaux merged commit c42c06b into devel Jul 2, 2020
@PromoFaux PromoFaux deleted the new/rev-server branch July 2, 2020 09:51
{
$error .= "Conditional forwarding subnet (\"".htmlspecialchars($cidr)."\") is invalid!<br>".
"This field requires CIDR notation for local subnets (e.g., 192.168.0.0/16).<br>".
"Please use only subnets /8, /16, /24, and /32.<br>";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DL6ER This works as expected, I get an error if I try to use a /23. But I do have a question, why is /23 invalid?

My network spans 192.168.0.1-192.168.1.254

(I should have checked this before merging I guess!)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.... I tried a cursory search on discourse to see if it had already been discussed. I failed, clearly!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In any case, it works if I use /16

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there was a mailinglist patch or question to allow for non-natural masks.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

@DL6ER DL6ER Jul 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah. TL;DR dnsmasq only supports multiples of 8 for IPv4 (8, 16, 24) and multiples of 4 for IPv6 (4, 8, 12, ...). I submitted patches to allow arbitrary prefix lengths but nothing happened to them. As odd prefix-lengths cause dnsmasq to fail on startup, they are forbidden for now (until my two patches are implemented)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IPv5

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do this every now and then, usually it goes unnoticed :-)

@pralor-bot
Copy link

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/pi-hole-5-1-released/35577/1

@pralor-bot
Copy link

This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there:

https://discourse.pi-hole.net/t/text-change-on-the-settings-dns-page/27022/11

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

Successfully merging this pull request may close these issues.

7 participants