Recognition Display DNS-Over-HTTPS Policy for Managed School Kiosks

Quick answer: For most managed school recognition kiosks, the correct DoH policy is to disable browser-level DoH via Group Policy or MDM and let the school’s managed DNS resolver handle all name resolution — including internal names for recognition platform infrastructure and external names that pass through the school’s content filter. If the school operates an internal DoH resolver (such as a Cloudflare Gateway for Teams endpoint, Cisco Umbrella, or a Windows Server DNS role with DoH enabled), the policy instead points the kiosk’s OS-level DoH to that internal resolver and disables browser-level DoH overrides. Either way, the policy must be documented, enforced, and verified — especially after browser updates, which can silently revert or upgrade DoH settings.

A recognition display in a school lobby depends on DNS resolution to reach its cloud content platform — a documented DoH policy ensures that name resolution remains predictable, filterable, and consistent with the school's network security controls

What DNS-over-HTTPS Does and Why It Changes Kiosk Management

Standard DNS sends queries in plaintext on UDP or TCP port 53. Any device on the same network path — a managed switch, a firewall, an inline filtering appliance, or the school’s own DNS resolver — can read, log, and act on those queries. Schools rely on this visibility for two purposes: content filtering (blocking DNS resolution for sites on the school’s prohibited list, as required by CIPA for E-rate recipients) and activity logging (recording which domains a device has queried, for audit and compliance purposes).

DoH changes the mechanics. As defined in RFC 8484, a DoH client sends DNS queries as HTTPS POST or GET requests to a DoH resolver’s HTTPS endpoint — for example, https://dns.google/dns-query or https://cloudflare-dns.com/dns-query. The query is encrypted inside TLS and is transmitted on port 443, the same port used for all HTTPS web traffic. A network monitoring device that cannot inspect TLS traffic sees only a connection to a known resolver IP address — not the DNS query itself.

For school IT teams managing recognition displays, three specific consequences follow from this design:

DNS-based content filtering is bypassed. If a managed kiosk’s browser sends DNS queries over DoH to an external resolver, those queries bypass the school’s filtered DNS resolver entirely. Domains that the school’s resolver would have blocked resolve normally through the external DoH resolver, regardless of the filtering policy configured on the school’s DNS infrastructure.

Internal names fail to resolve. If a recognition kiosk needs to reach an internal resource — a content server at display-content.school.local, an NTP server at a private IP, a proxy at an internal hostname — that name exists only in the school’s internal DNS zone. An external DoH resolver has no knowledge of internal zones and cannot resolve those names. The browser falls back to the OS DNS resolver for names it cannot resolve over DoH depending on the browser’s DoH mode, but the fallback behavior is not guaranteed and varies by browser version.

DNS activity logs for the kiosk become incomplete. Schools that log DNS activity for audit, compliance, or forensic purposes will see no queries from the recognition display in their DNS server logs if browser-level DoH is routing all queries externally. The display will appear to generate no DNS traffic at all, which makes troubleshooting connectivity problems and auditing device activity significantly harder.

Recognition displays managed as part of a school’s device fleet — whether through Microsoft Intune, Google Chrome Enterprise, Jamf, or Group Policy — belong to the same policy framework as student Chromebooks, staff laptops, and administrative workstations. The DoH configuration for the recognition kiosk should be an explicit, documented policy decision — not a default inherited from whatever the browser vendor chose for its latest update.

For school IT teams also managing the network segment that carries recognition display traffic, the DoH policy connects directly to the broader network configuration covered in resources like the recognition display network segmentation guide — which addresses how the display’s VLAN and traffic path interact with the school’s filtering and monitoring infrastructure.

The Three DoH Policy Positions for Managed School Kiosks

Before selecting and documenting a policy, school IT administrators need to understand the three basic positions available for DoH on a managed kiosk and the trade-offs each involves.

Position 1: Disable Browser-Level DoH, Use the School’s Managed DNS Resolver

The kiosk uses the school’s internal DNS resolver for all name resolution. Browser DoH is disabled via policy. Internal names resolve normally. Content filtering applies to all DNS queries from the device. DNS activity is logged at the school’s resolver.

Appropriate when: The school uses DNS-based content filtering (common in CIPA-compliant E-rate deployments), has internal DNS zones with names the recognition platform needs to reach, or requires DNS logging for compliance. This is the most common policy for managed school kiosks.

Limitation: DNS queries from the kiosk leave the device in plaintext on the internal network and are visible to any device on the path between the kiosk and the DNS resolver. On a properly segmented school network, this is typically the school’s own infrastructure, so the exposure is limited.

Position 2: Disable Browser-Level DoH, Use an Internal DoH Resolver at the OS Level

The kiosk’s OS is configured to use an internal DoH resolver — a resolver operated by the school or its content filtering provider that supports HTTPS-based queries but applies the school’s filtering policy and logs activity. Browser-level DoH is disabled to prevent overrides. The OS-level DoH handles all queries through the internal encrypted resolver.

Appropriate when: The school wants encrypted DNS traffic even on the internal network, uses a content filtering provider that offers a DoH endpoint (such as Cisco Umbrella, Cloudflare Gateway, or Zscaler), and is able to configure OS-level DoH on managed Windows devices through Group Policy.

Limitation: Requires the school to operate or subscribe to a DoH resolver that can also resolve internal names, or to configure split-horizon name resolution so that internal names fall through to a secondary resolver.

Position 3: Allow Browser-Level DoH with a Specified Resolver

The browser is allowed to use DoH, but the policy specifies which DoH resolver to use — preventing the browser from defaulting to Google, Cloudflare, or a user-selected resolver. This is achievable in Chrome and Edge via the DnsOverHttpsTemplates policy alongside DnsOverHttpsMode.

Appropriate when: A school wants DoH for privacy on the internal network and controls a DoH endpoint. This position is less common in K-12 environments and requires more infrastructure than Position 1 or 2.

Not appropriate for CIPA-compliant deployments unless the specified DoH resolver applies the required content filtering. Routing a managed kiosk’s DNS through an unfiltered DoH resolver — even one explicitly configured via policy — removes DNS-level CIPA filtering from the device’s traffic path.

For the remainder of this guide, Policy Position 1 (browser-level DoH disabled, school’s managed resolver used) is the primary implementation target, with notes for Position 2 where the configuration differs.

Why Internal Name Resolution Matters for Recognition Kiosks

Recognition displays connect to cloud content platforms for inductee data, athletic records, award rosters, and media files. The content platform endpoint is typically a public FQDN that an external DoH resolver can resolve without issue. However, several common elements of a school recognition deployment depend on internal DNS names:

When browser-level DoH routes all queries to an external resolver and falls back to the system resolver only under specific conditions, any of these resources can become intermittently unreachable — producing connectivity failures on the recognition display that appear unrelated to DNS and resist standard troubleshooting.

The most common symptom is that the recognition platform’s cloud endpoint resolves correctly (because it is a public name) while an inline proxy or certificate validation endpoint fails silently, producing HTTPS errors on the display without a clear error message visible to the operator.

Content Filtering and CIPA Compliance on Recognition Displays

The Children’s Internet Protection Act (CIPA) requires schools and libraries receiving E-rate funding to adopt an internet safety policy and implement technology protection measures — including filtering or blocking internet access to visual depictions that are obscene, contain child pornography, or are harmful to minors. Most schools satisfy this requirement in part through DNS-based content filtering: a managed DNS resolver that returns NXDOMAIN or a block-page IP for queries matching the school’s prohibited categories.

A recognition display kiosk connected to the school network and operating a general-purpose browser is subject to this filtering requirement. If browser-level DoH bypasses the school’s filtered DNS resolver, the filtering protection that CIPA requires is no longer in effect for that device’s DNS-sourced traffic.

Content filtering vendors commonly address this by operating their own DoH endpoint — for example, Cisco Umbrella’s https://doh.opendns.com/dns-query or a Cloudflare Gateway resolver — that applies the school’s filtering policy to DoH queries. In that case, a Policy Position 2 deployment pointing the managed kiosk to the vendor’s filtered DoH endpoint preserves CIPA-compliant filtering while encrypting DNS traffic.

For school IT teams that are uncertain whether their content filtering vendor’s DoH approach is CIPA-compliant, the best conservative policy for managed kiosks is Policy Position 1: disable browser-level DoH via GPO and rely on the school’s existing filtered DNS resolver. This preserves filtering coverage, keeps internal name resolution working, and eliminates the need to evaluate each browser update’s DoH default behavior.

Network QoS monitoring and baselining for recognition displays — including DNS query latency and resolution success rate — becomes more reliable when all DNS traffic from the kiosk flows through a single, documented resolver path.

Browser-Level DoH Policy Enforcement

Each major browser that might run on a school recognition kiosk has its own DoH settings and its own enterprise policy mechanism for controlling those settings. The enforcement method varies by browser and whether the device is managed via Active Directory Group Policy, Microsoft Intune, Chrome Browser Cloud Management, or another tool.

Google Chrome

Chrome’s DoH behavior is controlled by two enterprise policies:

DnsOverHttpsMode — Controls whether Secure DNS is enabled and how it behaves.

For managed school kiosks on Policy Position 1, set this to "off". For Policy Position 2, set it to "secure" with DnsOverHttpsTemplates pointing to the school’s internal DoH endpoint.

DnsOverHttpsTemplates — Specifies the URI template (RFC 6570) of the DoH resolver. Required when DnsOverHttpsMode is "secure". Ignored when mode is "off".

Deploying via Active Directory Group Policy:

The Chrome ADMX templates (available from Google’s enterprise downloads page) add a Chrome policy path under:

Computer Configuration > Administrative Templates > Google > Google Chrome > DNS-over-HTTPS settings

Set DnsOverHttpsMode to Enabled and enter the value off. This applies to all Chrome instances on the machine and cannot be overridden by the user or a profile policy.

Deploying via Chrome Browser Cloud Management or Intune:

Configure the DnsOverHttpsMode policy in the Chrome Browser Cloud Management console or deploy it through Microsoft Intune using the Chrome ADMX administrative template ingested as a custom profile. Set the value to off for Policy Position 1.

Microsoft Edge

Edge uses the same Chromium policy infrastructure as Chrome. The policy names are identical: DnsOverHttpsMode and DnsOverHttpsTemplates. Deploy via Active Directory ADMX templates (Microsoft Edge ADMX available from Microsoft’s download center) or via Intune using the Microsoft Edge administrative template.

Group Policy path:

Computer Configuration > Administrative Templates > Microsoft Edge > DNS-over-HTTPS settings

Set DnsOverHttpsMode to off for Policy Position 1.

Mozilla Firefox

Firefox’s DoH configuration is separate from Chrome and Edge. Firefox uses its own DNS-over-HTTPS implementation called Trusted Recursive Resolver (TRR). The relevant enterprise policy is DNSOverHTTPS in the policies.json file that Firefox reads from its distribution directory.

Example policies.json for Policy Position 1:

{
  "policies": {
    "DNSOverHTTPS": {
      "Enabled": false,
      "Locked": true
    }
  }
}

Setting Enabled: false and Locked: true disables DoH and prevents users from re-enabling it in Firefox preferences. On Windows, this file belongs at C:\Program Files\Mozilla Firefox\distribution\policies.json. For Firefox managed via Active Directory, the Firefox ADMX templates are available from Mozilla’s GitHub repository and deploy the equivalent setting under:

Computer Configuration > Administrative Templates > Mozilla > Firefox > DNS over HTTPS

Firefox also responds to a network-level signal. If the school’s DNS resolver returns NXDOMAIN for the domain use-application-dns.net, Firefox interprets this as an administrative signal that the network operator intends to handle DNS resolution and disables its DoH feature automatically — without any browser-side policy configuration. Mozilla documents this mechanism as the “canary domain” approach. It provides a useful fallback for environments where browser policy management is not available for all Firefox installations, but it applies only to Firefox and should not replace explicit policy enforcement on managed kiosks.

Windows OS-Level DoH (Windows 11)

In addition to browser-level DoH, Windows 11 supports DoH at the operating system level — all DNS queries from all applications on the device can be encrypted via HTTPS when the OS is configured to use a DoH-capable resolver. This setting is configurable via:

• Settings > Network & Internet > Wi-Fi or Ethernet > DNS server assignment > Preferred DNS encryption
• Group Policy: Computer Configuration > Administrative Templates > Network > DNS Client > DNS over HTTPS (DoH)

For Policy Position 1 (disable DoH), confirm the DNS Client policy is not configured for mandatory DoH and that the system DNS servers point to the school’s managed resolver. For Policy Position 2 (internal DoH resolver), set the policy to require HTTPS and specify the school’s DoH endpoint as the resolver.

Windows 10 does not have a native DoH settings UI. Managed deployments on Windows 10 should rely on browser-level policy enforcement rather than OS-level DoH settings for those devices.

Recognition Display DNS-over-HTTPS Policy Verification Checklist

After configuring and deploying the DoH policy, verify that the enforcement is in effect on each recognition kiosk. Run this checklist after initial deployment, after any major browser update, and after any OS update that modifies network stack defaults.

Pre-Verification Information to Collect

Step 1: Confirm Browser Policy Is Applied

On the kiosk, open the browser’s policy status page:

• Chrome: chrome://policy
• Edge: edge://policy
• Firefox: about:policies

Search for DnsOverHttpsMode (Chrome/Edge) or the DNSOverHTTPS entry (Firefox). Confirm:

• The policy appears in the Active Policies section
• The value is off (Chrome/Edge) or Enabled: false, Locked: true (Firefox)
• The source shows as Machine or Group Policy — not User or Default

If the policy does not appear, the GPO or MDM profile has not applied to this machine. Run gpupdate /force in an elevated Command Prompt and wait for policy refresh, then recheck.

Step 2: Verify the System DNS Resolver Address

Confirm the kiosk is using the school’s managed DNS resolver and not a public resolver IP.

Windows Command Prompt:

ipconfig /all

Look for the DNS Servers entry under the active network adapter. The IP addresses listed should match the school’s internal DNS resolver — typically an internal IP (10.x.x.x, 172.16–31.x.x, or 192.168.x.x) or the IP of the school’s content filtering provider if DNS is handled off-premises. The addresses should not be 8.8.8.8, 8.8.4.4 (Google), 1.1.1.1, 1.0.0.1 (Cloudflare), or 9.9.9.9 (Quad9) unless those are the school’s configured filtering resolvers.

PowerShell alternative:

Get-DnsClientServerAddress -AddressFamily IPv4

This lists DNS server addresses per network adapter, which is useful if the kiosk has both a wired and wireless adapter configured with different resolvers.

Step 3: Test DNS Resolution Through the School’s Resolver

Confirm that DNS queries from the kiosk resolve through the school’s managed resolver, not through a browser DoH resolver.

Using nslookup:

nslookup <recognition-platform-domain>

The output header shows which server handled the query:

Server:  dns.school.edu
Address:  10.1.1.53

Non-authoritative answer:
Name:    platform.example.com
Address: 203.0.113.45

Confirm the Server field shows the school’s DNS resolver IP or hostname, not a public resolver address. If the server field shows an unexpected external IP, the system DNS configuration is pointing to a public resolver regardless of browser policy — investigate the network adapter’s DNS server assignment or DHCP server options.

Test an internal name:

nslookup proxy.school.internal

This query should resolve through the school’s internal DNS. If it returns NXDOMAIN or a timeout when the internal name is expected to exist, internal DNS resolution is broken — investigate whether the school’s resolver is configured with the correct internal zones.

Step 4: Confirm Browser DoH Is Not Active

Open Chrome or Edge and navigate to the browser’s security settings:

• Chrome: chrome://settings/security
• Edge: edge://settings/privacy

Look for the Use secure DNS toggle. On a policy-managed device with DnsOverHttpsMode set to "off", this toggle is grayed out and shows as off, with a note indicating it is managed by the organization.

For a more detailed view, check the network internals page:

• Chrome: chrome://net-internals/#dns
• Edge: edge://net-internals/#dns

The DoH or Secure DNS status line should show Disabled or off.

Step 5: Test DNS Resolution from Outside the Browser

To confirm that DNS queries from non-browser processes — the recognition platform application, Windows Update, other system services — are also using the school’s managed resolver, run a resolution test from the command line.

PowerShell DNS test:

Resolve-DnsName -Name <recognition-platform-domain> -Server <school-dns-ip>

This query explicitly uses the school’s DNS server and confirms the domain resolves correctly from that resolver. If the domain does not resolve from the school’s resolver but does resolve from a public resolver, the school’s resolver has a configuration gap — not a kiosk-side problem.

Check for active connections to known DoH resolver addresses:

netstat -an | findstr ":443"

If the kiosk has established persistent HTTPS connections to the IP addresses of known public DoH resolvers (8.8.8.8:443, 1.1.1.1:443, 9.9.9.9:443) shortly after the browser starts, browser-level DoH may be active despite the policy. Verify the policy application in Step 1.

Step 6: Verify Recognition Platform Content Is Updating

After confirming DNS policy enforcement, verify that the recognition platform is successfully reaching its cloud content endpoints and that content is updating normally. Check the recognition platform’s management console for:

• Last successful content sync timestamp
• Active connection status
• Any DNS resolution errors in the platform’s event log

For interactive recognition kiosk displays in school lobbies and hallways that serve updated inductee profiles, athletic records, and event recognition content, a current sync timestamp confirms that the DoH policy is not disrupting any path the platform needs. If the platform shows DNS errors after the policy is applied, check whether any recognition platform endpoint uses a hostname that differs from what is documented in the vendor’s network requirements.

Step 7: Document the Verified Configuration

After completing Steps 1–6, record the verified configuration in the display’s maintenance documentation:

This documentation serves two purposes: it provides the baseline for the next verification pass, and it satisfies any audit requirement that the school’s managed devices have a documented DNS configuration consistent with CIPA compliance requirements.

Completing the DoH verification checklist after each major browser update confirms that policy enforcement is still in effect — browser updates can silently change DoH default behavior, so verification is a recurring maintenance step rather than a one-time task

Common Recognition Display DoH Policy Issues and Fixes

Keeping the DoH Policy Current After Browser Updates

Browser vendors update DoH implementation and default behavior frequently. A policy configuration that correctly disables DoH in one major version may require review after the next major version introduces a new Secure DNS prompt or changes how DnsOverHttpsMode interacts with other network policies. Build browser policy review into the standard browser update process for kiosk devices.

Before deploying a major Chrome or Edge version to recognition kiosk devices:

1. Review the release notes for the new version in the Chrome Enterprise Release Notes (published by Google for each major release) or Microsoft’s Edge enterprise documentation.
2. Search for any changes to DoH behavior, Secure DNS defaults, or DNS-related policy semantics.
3. Test the policy application on a single kiosk running the new version before pushing to all displays.
4. Run Steps 1 through 5 of the verification checklist on the test kiosk and confirm DoH is still disabled.

For Firefox on kiosks:

After each Firefox update, verify that about:policies still shows the DNSOverHTTPS entry as active and locked. If the entry disappears after an update, the policies.json file may have been removed or its path reset by the installer.

Monitoring for unexpected DNS resolver changes:

For recognition display deployments managed through a network monitoring platform, configure an alert for when the display’s DNS traffic shifts to an unexpected resolver IP. If DNS queries from the kiosk’s IP address begin appearing at public DoH resolver addresses in firewall logs — indicating DoH traffic to external resolvers — the browser policy has been bypassed or reset. This monitoring is the operational complement to the periodic verification checklist. For schools also tracking network performance baselines for recognition displays, adding DNS resolver IP monitoring to the same dashboard provides early warning of policy drift without requiring a manual verification pass on every kiosk.

Documenting the Policy for Audit and Handoff

A DNS-over-HTTPS policy for managed school kiosks should be documented in a format that a successor IT administrator can understand and verify without relying on institutional memory. The documentation does not need to be elaborate, but it must cover four elements.

Policy decision and rationale. State which policy position is implemented (browser DoH disabled, school resolver used) and why (CIPA compliance, internal name resolution, DNS-based filtering coverage). This prevents a future administrator from re-enabling DoH without understanding the implications.

Enforcement mechanism. Identify the Group Policy Object name or MDM profile name, where it is applied (which OU, which device group), and how to verify it is applied on a specific kiosk. Include the specific policy settings and values.

Resolver configuration. List the DNS resolver IP addresses the kiosk is configured to use, where that configuration comes from (DHCP option, static assignment, GPO), and who is responsible for maintaining those resolvers.

Internal names the kiosk depends on. List each internal hostname the recognition platform or kiosk OS relies on, so a future DNS change does not inadvertently break resolution for those names without anyone connecting it to the kiosk’s connectivity. For schools managing recognition kiosks across multiple buildings — athletic hallways, lobby trophy walls, academic honor displays — this list may differ per location if different buildings use different proxy or NTP hostnames.

For a broader picture of how DoH policy fits into the full kiosk network configuration, the school touchscreen kiosk buyer’s guide and the digital signage services and kiosk displays overview cover the range of network requirements that recognition displays bring to a school’s managed infrastructure.

A documented DoH policy for each recognition kiosk supports staff transitions and audit requirements — the next IT administrator can verify the configuration without needing to reverse-engineer what was deployed

Frequently Asked Questions

Q: What is the difference between DNS-over-HTTPS and DNS-over-TLS?

A: Both protocols encrypt DNS queries, but they differ in how the encryption is delivered. DNS-over-HTTPS (DoH), defined in RFC 8484, sends DNS queries as HTTPS requests on port 443, making them appear identical to ordinary web traffic. DNS-over-TLS (DoT), defined in RFC 7858, sends encrypted DNS queries on a dedicated port (TCP 853), making DoT traffic distinctly identifiable to a network firewall. For managed kiosk environments, the key practical distinction is that DoH is much harder to block at the network level than DoT, because blocking port 443 would also block all HTTPS web traffic. School IT teams are more likely to encounter browser-level DoH (in Chrome, Edge, and Firefox) than OS-level DoT, though Windows 11 supports both protocols.

Q: Does disabling browser DoH make the kiosk’s DNS traffic less secure?

A: Disabling browser-level DoH means the kiosk’s DNS queries travel in plaintext between the kiosk and the school’s DNS resolver. Within a school network that uses wired switches and VLAN segmentation, the practical exposure of plaintext DNS is limited — an attacker would need access to a device on the same network segment to observe the queries. On a properly segmented recognition display VLAN, this risk is low. If the school requires encrypted DNS even on the internal network, Policy Position 2 — using an internal DoH resolver operated by the school’s filtering provider — provides encryption while preserving filtering and internal name resolution.

Q: Will disabling DoH break the recognition platform’s cloud connectivity?

A: No. Recognition display platforms that connect to cloud content endpoints communicate over standard HTTPS on port 443, regardless of how the kiosk’s DNS resolves the endpoint’s domain name. DoH is a DNS transport mechanism — it affects how a domain name is resolved into an IP address, not how the subsequent HTTPS connection to that IP address is established. Disabling DoH on the kiosk does not affect the encryption or security of the connection between the kiosk and the recognition platform’s cloud servers.

Q: How do I know if a browser update has re-enabled DoH on a recognition kiosk?

A: Run Step 1 and Step 4 of the verification checklist: check the browser’s policy page to confirm the DnsOverHttpsMode policy is still applied and still set to off, then check the Secure DNS status in the browser’s security settings. If the policy is no longer listed, the GPO or MDM profile has not applied to the kiosk after the update — run gpupdate /force and recheck. If the policy is listed but the value has changed, the policy definition may need to be reviewed against the new browser version’s policy documentation.

Q: What does the Firefox canary domain use-application-dns.net do?

A: Firefox periodically sends a DNS query for use-application-dns.net to test whether the network’s DNS resolver returns NXDOMAIN for that domain — which Mozilla has defined as a signal that a network operator has a filtering or internal-resolution reason to disable Firefox’s built-in DoH. If the school’s DNS resolver returns NXDOMAIN for use-application-dns.net, Firefox automatically disables its DoH feature even without a browser-level enterprise policy. This provides a lightweight fallback for environments where Firefox is not fully managed through enterprise policies. However, it applies only to Firefox, does not substitute for explicit browser policy on managed kiosk devices, and its behavior can change across Firefox releases.

Q: Should the recognition display’s DNS policy be the same as other school kiosks or managed devices?

A: Generally yes — the recognition display should follow the same DNS policy as other school-managed devices on the same VLAN or device class. If the school standardizes on Policy Position 1 for all managed Windows devices, the recognition display should use the same GPO. The only recognition-display-specific consideration is ensuring that the internal names the recognition platform depends on — proxy, NTP, update servers — are documented and confirmed to resolve through the school’s resolver. If those names are missing from the internal DNS zone, the display will have connectivity problems that other kiosks on the same policy may not exhibit.

Q: Does the recognition platform require DoH to be enabled?

A: No. Recognition display platforms that connect to cloud content endpoints use standard HTTPS connections to public domain names. DoH is a DNS transport protocol — it affects how domain names are resolved into IP addresses before the connection is established, not how the HTTPS connection itself is secured. The recognition platform does not depend on or require DoH to be enabled on the kiosk; its cloud connections operate correctly regardless of whether the kiosk’s DNS uses plaintext UDP, DoH, or DoT.

A recognition display's DoH policy is a low-visibility but high-impact configuration — a browser update that silently re-enables DoH can bypass content filtering and break internal name resolution without any visible change on the display's screen

A recognition display DNS-over-HTTPS policy for managed school kiosks covers four connected decisions: which DoH mode to configure for each browser on the device, how to enforce that mode through Group Policy or MDM so browser updates cannot reset it, how to confirm that internal names the recognition platform depends on still resolve correctly, and how to verify CIPA-required content filtering still applies to the display’s DNS-sourced traffic. For most K-12 deployments, the answer is consistent across all four: disable browser-level DoH via machine-scoped policy, use the school’s managed and filtered DNS resolver for all queries, document the configuration in the kiosk’s maintenance record, and re-run the verification checklist after each major browser update. The policy itself is a short configuration document; the discipline of verifying it after updates is the part that prevents quiet drift from undermining the school’s network security posture over time.