Safe Browsing/Parental Control static bootstrap uses 94.140.14.16 instead of 94.140.15.16 #8637

Prerequisites

• I have checked the Wiki and Discussions and found no answer identifying this address discrepancy.
• I have searched other issues and found no duplicate reporting this exact incorrect address. Related reports are linked below.
• I want to report a bug, not ask for configuration help.
• AdGuard Home is configured and serving DNS clients.

Platform (OS and CPU architecture)

Linux, ARM64. Connection checks were performed on three local hosts; these are not three independent Internet locations.

Installation

Upstream release binaries, deployed through configuration management.

Setup

Multiple standalone Linux DNS servers with Safe Browsing enabled.

AdGuard Home version

v0.107.79. The same constant is present in upstream master at fe415923abb65b7a3f26eca079cd0891b6792796 (2026-10-02).

Action

While investigating occasional slow DNS responses, I inspected setupDNSFilteringConf and tested its static bootstrap addresses for https://family.adguard-dns.com/dns-query.

The second IPv4 address is 94.140.14.16:

// 94.140.14.16.
netip.AddrFrom4([4]byte{94, 140, 14, 16}),

• Installed version source
• Current master source
• Official AdGuard DNS addresses list the Family Protection IPv4 pair as 94.140.14.15 and 94.140.15.16.

The static resolver options are shared by the Safe Browsing and Parental Control checkers. Parental Control was not enabled in our runtime tests.

For the connection comparison, I used curl with --resolve family.adguard-dns.com:443:ADDRESS, an HTTPS POST containing a valid DNS wire-format query, Content-Type: application/dns-message, and a two-second connection timeout. The hostname/SNI was preserved and certificate verification was enabled; no insecure TLS option was used. The same Safe Browsing TXT query payload was used for the address comparisons.

Expected result

The secondary IPv4 bootstrap address should match the documented Family Protection endpoint, 94.140.15.16, so there is a usable alternate target if the primary cannot connect.

Actual result

Tests on 2026-10-03:

This appears to be a one-octet typo in the compiled-in secondary address. The measurements establish the difference from our network, not global reachability of either address.

Additional information

The proposed correction is the secondary IPv4 literal (and its comment):

- // 94.140.14.16.
- netip.AddrFrom4([4]byte{94, 140, 14, 16}),
+ // 94.140.15.16.
+ netip.AddrFrom4([4]byte{94, 140, 15, 16}),

The installed dnsproxy version dials bootstrap addresses sequentially. This report concerns the unusable alternate target when the primary connection fails; it does not claim that correcting the secondary will remove latency from successful primary connections. We did not deliberately interrupt the production primary or run a patched binary failover test.

Related reports contain the address or describe service failures, but do not identify this specific correction:

• DNS lookups totally break when "browsing security web service" is down #7175: the incorrect address appears in timeout logs; closed as a duplicate of DNS stop working #6817.
• My server becomes slow when resolving DNS while experiencing issues to https://family.adguard-dns.com:443/dns-query #7274: broader Safe Browsing service latency/availability.
• Discussion #8096: traffic to this address, without identifying the discrepancy.

This report does not request changing the Safe Browsing protection policy.