e2e_tests.test_dns package

Submodules

e2e_tests.test_dns.test_dns_search_suffixes module

End-to-end tests for DNS search suffix support.

The WARP daemon fetches its network policy from the Cloudflare API on connection, and receives live updates via edge push notifications. Because dns_search_suffixes is a setting that requires a restart, updating the suffixes on the profile while connected will cause the daemon to automatically reconnect and apply the new OS DNS configuration.

class e2e_tests.test_dns.test_dns_search_suffixes.TestDnsSearchSuffixes

Bases: object

End-to-end tests for the DNS suffix support feature.

Verifies that dns_search_suffixes set on a Zero Trust device profile are correctly written to the OS DNS configuration on connect, and that the original configuration is fully restored on disconnect.

test_existing_system_suffixes_are_preserved_after_merge(single_device_profile: DeviceProfileModel, warp: WarpActions, system: SystemActions, backup_and_restore_searchlist)

Verify that pre-existing OS search domains are preserved when WARP applies API suffixes.

On Windows, a known seed value is written to the SearchList registry key before connecting so the preservation assertion is never vacuous on a clean VM. WARP is expected to write [API suffixes, …pre-existing entries] and the backup_and_restore_searchlist fixture restores the original state after the test.

Steps: 1. (Windows) Seed a known pre-existing SearchList entry 2. Snapshot the OS search domains before connecting 3. Connect WARP, configure suffixes, wait for auto-reconnect 4. Verify both API suffixes and original domains are present

test_suffix_update_applied_on_reconnect(single_device_profile: DeviceProfileModel, warp: WarpActions, system: SystemActions, backup_and_restore_searchlist)

Verify that updated dns_search_suffixes are applied after a live push.

This test mimics the flow of the other tests but verifies the live-push auto-reconnect behavior directly.

Steps: 1. Connect WARP without any search suffixes configured 2. Verify no API suffixes are in the OS DNS search list 3. Push dns_search_suffixes via the device profile 4. Wait for the setting to update and the auto-reconnect to trigger 5. Verify the new suffixes are in the OS DNS search list

test_suffixes_appear_in_os_dns_config_on_connect(single_device_profile: DeviceProfileModel, warp: WarpActions, system: SystemActions, backup_and_restore_searchlist)

Verify that API-configured search suffixes are written to the OS DNS search domain list when WARP connects.

Steps: 1. Connect WARP 2. Configure dns_search_suffixes on the device profile 3. Wait for the live update push and the subsequent auto-reconnect 4. Verify the suffixes appear in the OS DNS search list

test_suffixes_cleaned_up_on_disconnect(single_device_profile: DeviceProfileModel, warp: WarpActions, system: SystemActions, backup_and_restore_searchlist)

Verify that the original OS DNS search domain configuration is restored after WARP disconnects.

Steps: 1. Snapshot the OS search domains before connecting 2. Connect WARP, configure suffixes, wait for auto-reconnect 3. Confirm suffixes are present 4. Disconnect 5. Confirm the original list is restored exactly

test_windows_gpo_searchlist_blocks_warp_write(single_device_profile: DeviceProfileModel, warp: WarpActions, system: SystemActions, backup_and_restore_searchlist)

Verify that WARP does not write to the Tcpip SearchList when a GPO policy is active.

Windows DNS resolution gives precedence to the GPO policy key (HKLM\\Software\\Policies\\Microsoft\\Windows NT\\DNSClient\\SearchList) over the Tcpip Parameters key that WARP normally writes. When GPO is active, WARP should detect it and skip writing to the Tcpip key entirely.

Steps: 1. Write a fake GPO SearchList to the policy key 2. Connect WARP, configure suffixes, wait for auto-reconnect 3. Verify the Tcpip SearchList was NOT written with the API suffixes 4. Cleanup: remove the fake GPO key

test_windows_registry_searchlist_written_and_restored(single_device_profile: DeviceProfileModel, warp: WarpActions, system: SystemActions, backup_and_restore_searchlist)

Verify that WARP writes the global Windows SearchList registry key when dns_search_suffixes are configured, and deletes (or restores) it on disconnect.

Steps: 1. Record the current SearchList value 2. Connect WARP, configure suffixes, wait for auto-reconnect 3. Verify the registry key is written with the API suffixes first 4. Disconnect 5. Verify the registry key is deleted (or restored to its prior value)

e2e_tests.test_dns.test_dnssec module

class e2e_tests.test_dns.test_dnssec.TestDnssec

Bases: object

Test suite for DNSSEC validation through WARP.

pytestmark = [Mark(name='platform_skip', args=(), kwargs={'platform': 'windows', 'codename': None, 'version': None, 'reason': 'dig is not available on Windows'}), Mark(name='warp_consumer', args=(), kwargs={})]
test_dnssec_rrsig_present(warp: WarpActions, system: SystemActions)

Verify that DNSSEC-signed domains return RRSIG records when requested.

test_dnssec_validated_domain(warp: WarpActions, system: SystemActions)

Verify that DNSSEC-signed domains return the AD (Authenticated Data) flag.

e2e_tests.test_dns.test_windows_searchlist_corruption module

End-to-end tests for WARP resilience against corrupted Windows SearchList registry values.

The WARP DNS proxy reads the global SearchList from the Windows registry on connect. Pre-existing corrupted values (null characters, trailing spaces, extra commas) must not prevent WARP from connecting or cause hickory-resolver to panic with “FailedToParseDnsConfig”.

e2e_tests.test_dns.test_windows_searchlist_corruption.test_searchlist_with_multiple_issues(warp: WarpActions, system: SystemActions, backup_and_restore_searchlist)

Verify WARP connects when the Windows registry SearchList has multiple formatting issues.

Combines null characters, trailing spaces, and extra commas in a single value.

e2e_tests.test_dns.test_windows_searchlist_corruption.test_searchlist_with_null_character(warp: WarpActions, system: SystemActions, backup_and_restore_searchlist)

Verify WARP connects when the Windows registry SearchList contains a null character.

The issue occurs when reading DNS configuration from the Windows registry. The SearchList value may contain unexpected characters (null bytes, trailing spaces) that cause hickory-resolver to fail with: “FailedToParseDnsConfig(ResolveError { kind: Proto(ProtoError { kind: Msg(“unrecognized char: \0”) }) })”

e2e_tests.test_dns.test_windows_searchlist_corruption.test_searchlist_with_trailing_spaces(warp: WarpActions, system: SystemActions, backup_and_restore_searchlist)

Verify WARP connects when the Windows registry SearchList contains trailing spaces.

This test addresses customer escalations where trailing spaces in the SearchList cause DNS configuration parsing to fail.