First, the client needs a network identity.
A DHCPv4 server can lease an IP address and supply a subnet mask, gateway, and DNS server addresses. Administrators do not need to configure every workstation manually.
The classic initial exchange is DORA: Discover, Offer, Request, Acknowledge. A DHCP relay forwards requests between subnets when the server is not on the same broadcast domain.
A new client asks whether a DHCPv4 server is available, often via broadcast.
A server offers an IPv4 address, lease length, and other configuration options.
The client requests the preferred offer, indicating which server it selected.
The selected server confirms the lease. Other responses, such as NAK, are possible.
DHCPv4 commonly uses UDP 67 (server) and 68 (client). Option 003 can supply default router(s), and option 006 supplies DNS server(s). Lease renewals do not always repeat the initial broadcast exchange.
Then the client needs to resolve names.
DNS translates names such as intranet.corp.example into usable records. An A record contains IPv4, AAAA contains IPv6, and CNAME is an alias to another DNS name.
The client typically queries a recursive resolver. It can answer from its cache or look up the answer upstream. Authoritative DNS servers hold information for the zones they serve.
A record's TTL controls how long an answer may normally be cached. A wrong record, incorrect DNS server, stale cache and unreachable resolver are different problems requiring different evidence.
Diagnose the symptom, not your first suspicion.
Accounting can reach an internal server by IPv4 address, but the hostname fails. The cause could be a record, cache, resolver, or network configuration error. Compare the actual client settings against the documented baseline.
C:\> ipconfig /all DHCP Server . . . : 192.168.10.254 <-- unexpected DNS Servers . . . : 192.168.10.254 <-- unexpected C:\> ping 192.168.10.1 Reply from 192.168.10.1: bytes=32 ... C:\> nslookup intranet.corp.example Server: 192.168.10.254 *** Non-existent domain C:\> nslookup intranet.corp.example 192.168.10.10 Server: dns01.corp.example Address: 192.168.10.20
In this example, approved DHCP is 192.168.10.5 and approved DNS is 192.168.10.10. The default gateway responds and the approved resolver has the intranet record. But DHCP server 192.168.10.254 supplied an unexpected DNS resolver. That is evidence of a potentially unauthorized DHCP responder, not proof of exactly where it resides.
ipconfig /flushdns clears the Windows DNS cache, but does not correct a DHCP-assigned DNS server. ipconfig /release or /renew can disconnect a remote support session. Collect evidence before making changes.
Four symptoms worth recognizing.
Check the physical link, VLAN, DHCP server/scope, and relay path. A 169.254.x.x address can indicate APIPA.
Compare DNS settings and query the same name through a known-good resolver.
Check the DHCP Server field, lease options, and approved scope configuration.
Check the exact record, zone, split DNS, and negative caching.
Check your understanding.
Should you change the intranet A record if the client received the wrong DNS server by DHCP?
No. Investigate the DHCP source and option 006. The approved resolver may already have the correct record.
How can DHCP serve clients on another VLAN?
A relay on a routed interface can forward client requests to an off-subnet DHCP server.
Why query the same hostname against two different DNS servers?
Comparing responses helps isolate a problem with one resolver versus a missing or incorrect record more broadly.