AdguardTeam / AdguardTeam/AdGuardHome

DHCP: allow configuring a secondary DNS server (option 6) via the UI for degraded-mode resilience

Offen
#8,189 5 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
feature request
Vorherrschende Sprache
TypeScript
Sterne
36.9k
Forks
2.5k
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

### Prerequisites

- [x] I have checked the [Wiki](https://github.com/AdguardTeam/AdGuardHome/wiki) and [Discussions](https://github.com/AdguardTeam/AdGuardHome/discussions) and found no answer

- [x] I have searched other issues and found no duplicates

- [x] I want to request a feature or enhancement and not ask a question

### The problem

_(I already posted "#7954" but this is more structured and goes with an incoming PR)_

### The problem

AdGuard Home’s built-in DHCP server currently advertises only itself as DNS server (DHCP option 6).

This works well in normal conditions, but it creates a **single point of failure** for the local network:

- if AdGuard Home is temporarily unavailable (update, restart, crash, host issue),
- DHCP clients lose *all* DNS resolution,
- even though a fallback DNS resolver may exist on the LAN.

This is especially problematic in **locked-down deployments** (e.g. Home Assistant OS add-on), where:
- users have **no access to `AdGuardHome.yaml`**,
- the **web UI is the only configuration surface**.

Advanced DHCP options (including option 6 overrides) are currently only configurable via YAML, which makes this use case impossible in such environments.

### Willingness to contribute

I’m willing to submit a PR implementing this behavior (UI + backend), following maintainers’ guidance on naming and API structure.

### Proposed solution

### Goal (very limited scope)

Provide a **simple, safe and explicit** way to configure **one or more additional DNS servers** advertised by DHCP **via the UI**, in order to:

- allow a *degraded but functional LAN* if AdGuard Home is down,
- without exposing generic or unsafe DHCP option editing,
- without breaking existing configurations.

This is **not** a request to expose full DHCP options editing.

---

### Proposed behavior

#### UI

- Add a new optional field in DHCP settings:

**“Additional DNS servers for DHCP clients”**

- Accepts a list of IPv4 / IPv6 addresses.
- Empty by default → current behavior unchanged.
- Display a clear warning (with translations), for example:

> “Secondary DNS servers may bypass AdGuard Home filtering.
> It is recommended to keep AdGuard Home as the first DNS server.”

#### Backend

- Internally maps this field to **DHCP option 6** (`ips` format).
- Always keeps AdGuard Home’s own IP as the **first DNS server**.
- Does **not** expose or modify any other DHCP options.
- Existing YAML configurations with custom `dhcp.options` must continue to work unchanged.

---

### Why this approach is safe

- No raw DHCP option editing.
- No UI access to arbitrary option numbers.
- Only affects **option 6**, which AdGuard Home already supports.
- Fully backward-compatible.
- Opt-in only.

---

### Example use case

Home Assistant OS + AdGuard Home add-on:

- AdGuard Home = primary DNS + DHCP.
- Secondary local resolver (or upstream DNS) configured as fallback.
- If Home Assistant restarts, the LAN keeps basic DNS functionality instead of fully breaking.

---

### Implementation notes (high-level)

- Extend DHCP config API to expose a dedicated field (e.g. `additional_dns_servers`).
- Convert this field to option 6 internally when applying DHCP config.
- UI: simple multi-IP input, reuse existing IP validation components.
- Add warning text with translations.

### Alternatives considered and additional information

### Alternatives considered

- Editing `dhcp.options` via UI → rejected (too dangerous / too broad).
- Relying on YAML only → not viable in HAOS and similar environments.

Beitragsleitfaden

Beitragsleitfaden öffnen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.