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

Proposal: Add option to use DNSMasq #70

Closed
Bourne-ID opened this issue Jul 10, 2022 · 5 comments
Closed

Proposal: Add option to use DNSMasq #70

Bourne-ID opened this issue Jul 10, 2022 · 5 comments

Comments

@Bourne-ID
Copy link
Contributor

Good day.

Issue statement

The use of dhcpd is great for air-gap solutions where a new DHCP is required. However for some home networks which does not have the VLAN capability or for users who would like to use common router DHCP services, the use of DHCPD will cause duplicate DHCP servers and will result in potential network disruption, or will limit the ability to auto-provision the Metal stage of this project.

Proposed Solution: DHCP Proxy

Use DHCP Proxy services to add PXE features such as Next Server into this project. This allows for users to use the existing DHCP servers which may be locked down or incapable of using Next Server/PXE settings on their network to be able to auto-provision hardware through PXE (with certain common configurations, like static IP allocation or reduction in DHCP request ranges on the DHCP server)

Proposed Application: DNSMasq

DNSMasq in Proxy mode interoperates with existing DHCP servers over IPv4 to add features such as next-server, TFTP, etc. where such hardware is either locked or unconfigurable for such services. This would be an opt-in change, configurable through the pxe_server defaults file.

Proposed Target Audience

Users who either do not want to create their own VLAN or lack the hardware to configure such services. Users who want to use common router services for DHCP and have router access to configure static IP and/or DHCP allocation ranges.

Additional Risks with Proposed Change

  • Additional Surface Area for Break-Out Attacks: Originally this project is locked to its own DHCP/VLAN, so any break-outs should be contained accordingly. Using common home networks increases the surface area of break-out attacks if the deployment is compromised.
    • Mitigation: Enrolment into this change is opt in only.

Proposed Next Steps

  1. Trial/Adopt/Halt - A discussion with all or a decision by the project maintainers to identify if this change should exist in this project or live on a fork.
  2. Documentation (This is in flight in any situation).
@Bourne-ID
Copy link
Contributor Author

PR #69 Relates to this change

@khuedoan
Copy link
Owner

khuedoan commented Jul 10, 2022

Thanks for a very detailed proposal, I planned to move to dnsmasq for the DNS proxy feature but got side tracked (prior attempt c26db4d), so this is a welcome change 🎉

I prefer we replace dhcpd and tftpd with dnsmasq instead of adding a new opt-in option because:

  • We can still have the previous behavior with dnsmasq
  • Backward compatibility is not a problem because we're still in the Alpha stage
  • Reduce the complexity

@Bourne-ID
Copy link
Contributor Author

Sounds good - I'll make the changes on my fork, test and comment again when ready for review :)

@Bourne-ID
Copy link
Contributor Author

Bourne-ID commented Jul 11, 2022

PR #69 ready for candid review.

(This change will help with #57 and other architectures ;) )

@khuedoan
Copy link
Owner

#69 is merged.

zanehala added a commit to zanehala/homelab that referenced this issue Apr 20, 2023
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

No branches or pull requests

2 participants