Can I get a bit of help understanding the relationship between DHCP and DNS?

Posted by stone500@reddit | sysadmin | View on Reddit | 17 comments

Short backstory, I'm a sysadmin for a large retail company. My particular dept handles what we call "core services", which basically boils down to DHCP, DNS, AD, Email, file/print, etc etc etc Basically my issue is that we're trying to do a security audit and we're having issues because a lot of our A records and PTR records aren't matching up. This is mostly an issue with our endpoints that connect exclusively through our VPN, which makes sense considering that they will often reconnect almost daily and likely get new IP addresses. I'm trying to figure out how to best rectify this so DNS addresses are as up to date as possible, including the PTR records. While I understand plenty about how DHCP and DNS works, my background has mostly been in small/medium businesses, so there's some intricacies that allude me. For example, how does the process of updating DNS work if a machine disconnects and reconnects to VPN and gets a different IP? Is this handled by the client, or by DHCP? What is the difference between DHCP updating DNS and the client doing it? I looked at our scavenging settings and they have the default 7-day no-refresh 7-day refresh intervals. If I understand this correctly, this essentially means that a DNS record can't effectively be scavenged until after 14 days. I'm not exactly sure if altering these settings would be beneficial or not. Does scavenging even matter if what I really need to do is have the A and PTR records be up-to-date when a machine gets a new IP? I'm having trouble getting clarity on that point. All the articles I can find talk about the basics of "This is a forward record. This is a reverse record. Blah blah blah", which is fine for smaller networks, but there's more I need to know for a network as large as ours. Any info helps! Thank you!

Reply to Post

17 Comments

[-]

pdp10@reddit

* DHCP receives a request coming from a MAC address, and hands back one IPv4 address for a leased time. The address it hands back can be random from a free pool, or it can be a specific one that the DHCP is configured to hand to that MAC address, called a "reservation". * The DHCP request can contain a short hostname, that the DHCP client knows itself as. * DNS maps names to IP addresses, IP addresses to names, and contains some auxiliary information related mostly to those names or sometimes to those addresses. * A DHCP server can choose to take the short name from the DHCP query, plus the IP address it leases to that client, and create DNS records based on ta DNS domain/subdomain associated with those in its configuration. This is usually called "Dynamic DNS". * Microsoft does Dynamic DNS (DDNS) by default for clients formally joined into a hosted Microsoft Active Directory domain. These MSAD "domains" are not the same thing as DNS domains, though an MSAD domain does always have a DNS domain as one of its components. * Microsoft's DDNS is going to insert forward records mapping a name to an IP address, and also insert reverse records mapping an IP address to a name. These are `A` or `AAAA` (IPv6) records, and `PTR` records respectively. The addresses used to create the `PTR` records are the addresses handed out by DHCP, *etc.* * VPN clients may have addresses allocated through different policy or mechanisms than non-VPN nodes. * Forward and `PTR` records are independent of one another. Hosts can have multiple IP addresses (especially with IPv6!) and so have multiple valid `PTR` records and multiple valid forward records. Now, there are reasons for forward and reverse records to "match" symmetrically to varying degrees, but there's no typical reason today to worry about matching records for DHCP clients using dynamic address pools. Therefore, it's necessary to establish exactly why you're trying to get things to match, and to what exact degree you need them to match (remember, multiple addresses are common and proper!). As a generic recommendation, one good way to get DDNS records to stabilize is to use DHCP Reservations for important hosts like servers and anything that needs to receive connections like printers, smart PDUs, etc.

[-]

stone500@reddit (OP)

> Now, there are reasons for forward and reverse records to "match" symmetrically to varying degrees, but there's no typical reason today to worry about matching records for DHCP clients using dynamic address pools. Therefore, it's necessary to establish exactly why you're trying to get things to match, and to what exact degree you need them to match So for my example, our network security team sometimes has to to audits whenever suspicious network traffic is detected. What Security will see is generally just coming from an IP. To identify what machine that IP belongs to (and the person that owns the machine), they'll do an nslookup for that IP. Often, the result from that lookup is not accurate. While I'm sure there's ways they can get around that, the point is that we're being tasked with making DNS more "healthy and accurate", and these descrepencies are seen as problems.

[-]

TrippTrappTrinn@reddit

Use DHCP logs to identify computers not on fixed IP. As you have found, DNS does not work reliably for this, so rather than trying to fix something which is pretty much not fixsble, use what is actually available. You may need to set up something to retain the DHCP logs, but that is pretty simple.

[-]

OsmiumBalloon@reddit

You (and your security people) should understand that if you eliminate stale PTR records, then looking up an IP address after-the-fact may not find anything at all. Example: Your/their firewalls log something for IP address 10.x.x.x. That client then shuts down / disconnects from the VPN / etc. The `PTR` record is instantly deleted (you found a magic wand or something). A week later, security goes to look up IP 10.x.x.x, and gets no `PTR` record at all. Or, gets the `PTR` record for a completely different client that now holds the IP addresss. If your security team is going to use DNS for network intelligence, they have to do the DNS lookup at the time of logging, not at the time of investigation.

[-]

anonymousITCoward@reddit

for more on DNS [https://www.youtube.com/watch?v=4ZtFk2dtqv0](https://www.youtube.com/watch?v=4ZtFk2dtqv0) Warning, you're in for a culture shock

[-]

OsmiumBalloon@reddit

I've taught classes on DNS, but thanks anyway.

[-]

pdp10@reddit

> they'll do an nslookup for that IP. Often, the result from that lookup is not accurate. Yeah, welcome to 1992. How new are these secengs? An IP address can have a number of currently-accurate `PTR` records from various names sharing an IP address (*cf.* HTTP/1.1 Host headers), or formerly-accurate PTR records inserted by DDNS to a dynamic pool address. Infosec has to deal with those possibilities even if your DNS is perfect. And foreign DNS won't be perfect, but they need to deal with that. Start with these items: * DHCP reservations for all DHCP clients that aren't user endpoints. This should be scripted or through an IPAM for manageability. * Optionally decrease the DDNS scavenge time to equal the DHCP lease time. * Optionally increase the DHCP lease time to equal the DDNS scavenge time. Be cautious of pool exhaustion -- you may need to increase the size of the pool. (This is beginning to be a lot of short-term work so someone's reports are pretty, isn't it?) * Disable IPv6 temporary addressing, and if supported, enable RFC 7217 opaque addressing.

[-]

anonymousITCoward@reddit

Great explanation!

[-]

OsmiumBalloon@reddit

Scoping the discussion to entirely Microsoft Windows with Microsoft network services (DHCP, DNS, etc.) (other platforms/products do things differently): It should be noted that, in the default configuration, the actual DNS Update protocol messages come from the DHCP ***client***, not the DHCP server. There is an option in the DHCP server to have the server do DNS Update (instead? as well? I'm not sure), but it is disabled by default. Because DNS Updates are handled by the DHCP client service, the "DHCP Client" service needs to be running to have DNS names registered automatically, even if the client has a manually configured (static) IP address.

[-]

Gaijin_530@reddit

We experience the same, DNS is always lagging behind here with around 200 endpoints. If you go to RDP to an employee computer by hostname, you often have to ipconfig/flushdns first to make sure you don't have an old entry cached. Even then it's not always correct. I'm not sure if there's any remedy to make DNS update quicker.

[-]

vitaroignolo@reddit

I always assumed this was cached info in SCCM when we had these issues using Remote Viewer Tool. You're saying it may be DNS that can fix it?

[-]

Gaijin_530@reddit

I'm saying it's a possibility. At my place of employment, I inherited an infrastructure that is wired really oddly, and lacks resources, so I always chalked up the delay in DNS/A Records resolving properly to this environment alone. I think the DC here is overwhelmed with requests and times out on the DNS updates at times.

[-]

nullrecord@reddit

I'm not an expert on the topic but [ChatGPT was somewhat helpful](https://chat.openai.com/share/8cf2b17b-3c75-4f43-a317-68bf4b854e62). You can try asking it more specific questions in addition.

[-]

MartinDamged@reddit

Nice 👍🏾

[-]

AspieEgg@reddit

Just a guess, but it sounds to me like on your internal network you are probably using a DHCP server role on Windows, but on the VPN network your VPN appliance is doing the DHCP. By default, the DHCP server on Windows will update DNS, but most other DHCP servers wont do that, or they require a setting to be turned on so they know which DNS server to update. It's also possible your DNS server isn't configured to allow updates from non-authorized DHCP servers. If this is the scenario, you could probably solve the issue by making the Windows server the DHCP server for the VPN as well. You'll probably have to set up an IP DHCP helper on the router since without one the DHCP server would need to be on the same subnet.

[-]

stone500@reddit (OP)

This is probably the scenario. I'm going to talk to our network engineers and figure out what is actually serving DHCP for VPN users, and see if we can switch that to using one of our Windows servers. I imagine this will simplify things quite a bit. Our network is very large and we utilize helpers pretty much everywhere.

[-]

OsmiumBalloon@reddit

DNS returns records in response to queries. While humans want `A` and `PTR` records to match (forward vs reverse DNS), there is nothing in the DNS protocol that ensures this. The only way to "update" a `PTR` record is for something to know that the old one is obsolete, and delete the record. Microsoft's default configuration has clients send DNS Update protocol messages to the domain DNS servers, for all IP addresses assigned to the client. This is done even if the client is not using DHCP¹. The client will not always (usually not? never? I forget) delete `PTR` records when it loses an IP address. So the DNS domain will gradually accumulate stale `PTR` records. The result will be that if you ask DNS "who has IP 10.x.x.x?" (reverse lookup), you may get a `PTR` record back saying "client blah", when client blah has in fact long ago moved on. Scavanging is attempt to address this. If a `PTR` record has not been updated in X hours, it is assumed the client doesn't have that IP address any longer, and can be removed. The issue can also be mitigated by one's technique. Because the `A` records (forward lookup) get updated by the client every time the client registers a DNS Update, they will normally be as up-to-date as things can be. So to check the result of a reverse lookup, immediatey issue a follow-on query for whatever name got returned. To continue the previous example, we asked DNS who had 10.x.x.x, and DNS said it was client "blah". We can then ask DNS, "what is the IP address of blah?". If DNS says the IP is 10.x.x.x, they match, and that's a good sign. If DNS says the IP is 10.y.y.y, then they do not match, and you know you have a stale `PTR` record. ### Footnotes 1: Microsoft's implementation of DNS Update actually makes the functionality part of the "DHCP Client" service, but in terms of the protocols, DNS Update is not part of DHCP. It is just that DNS Update is most useful with dynamic addresses.