DNS

The resolver your machine asks decides where every name lookup goes. If it changes to one you did not choose, everything downstream rests on someone else's answers, and most of the stack above has no reason to notice.

What GURDN observes

The resolvers configured for each interface, read through the Windows APIs that own that configuration, and whether they differ from what GURDN last recorded for this network. GURDN reads configuration. It does not watch queries, log lookups or inspect responses.

What a change means

On its own, usually nothing. Captive portals, VPN clients and corporate networks all change resolvers legitimately. GURDN records the change and judges it with the rest of the picture: whether the network is one it has seen before, whether an adapter appeared at the same moment, whether the default route moved, and whether the firewall profile changed with it.

What GURDN can change

With your authorisation, GURDN can set the resolvers for an interface to a configuration you choose, and can return them to DHCP. Both are distinguishable in the record: returning resolvers to DHCP is not the same as clearing them, and the product keeps the two apart.

The change goes through the privileged service, using the Windows API for resolver configuration. GURDN does not shell out to netsh or any other command.

Verification, and the case that matters most

After applying, GURDN reads the resolver configuration back and compares it with what was requested. If they disagree, the change is a failure and the recorded undo runs.

Why no resolver is recommended

GURDN does not suggest a provider. Each one is operated by someone, and none of them lets GURDN verify that an answer is authentic. Recommending one would be asking you to transfer trust on GURDN's word, which is exactly the kind of claim the product avoids elsewhere.

See the response engine for how a change is applied, and recovery for what happens when it cannot be verified.