DNS scavenging
Heaton, Joseph@Wildlife
We have a DNS scavenging issue for our VPN users. Our current scavenging times are all set to 1 day (all 3). We are still experiencing issues where a user will move from in the office to working at home on VPN, and when you look them up, you get the wrong IP; or, worse, a different user/computer now has the IP, so you get really wrong info.
To further aid in easing these issues, the idea is being floated to change our scavenging times to either 4 hours each, or 1 hour each. My brain is telling me that might not be the best idea, but other than added traffic to the DCs, I can’t verbalize why I think it’s not a great idea.
Also, how does DHCP lease times affect this process? I’m assuming that for the DNS record to be updated correctly, that the VPN device would need to be able to update correct? And the VPN device is a Cisco ASA, which also handles the DHCP for the VPN connections. I’m not sure that that device has the ability to update DNS records, which is why they want to be more aggressive with the scavenging.
Any of this make sense, or am I rambling?
Thanks,
Joe Heaton
Managed Services and Operational Support Unit
Information Technology Operations Branch
Data and Technology Division
CA Department of Fish and Wildlife
1700 9th Street, 3rd Floor
Sacramento, CA 95811
Desk: 916-919-5816
Michael B. Smith
This used to be a great article on Microsoft’s networking blog, but that died and the article went to heaven. Someone saved it.
http://docplayer.net/178436770-Don-t-be-afraid-of-dns-scavenging-just-be-patient.html
Look at it with Brave or something else with ad blockers. Otherwise it’s annoying.
--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ntsysadmin/SJ0PR09MB6686BB5CA18184EAAD872EA1AA929%40SJ0PR09MB6686.namprd09.prod.outlook.com.
Josh Doty
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/b22aede541f24123a8b6e81e758a9905%40smithcons.com.
Perisa, Nik
we are having a similar problem with vpn and office workers. We setup a DHCP service account which if the address is assigned by DHCP, its owned by the DHCP service account. But when they work via vpn and the address isnt issued by the DHCP server, it wont
update DNS. We've been toying around with the idea of scripting it so that both the computer and the DHCP service account have permissions to update the record but i dont know if that is the best option.
Sent: Wednesday, 10 March 2021 4:41:20 AM
| EXTERNAL SENDER:
Do not click any links or open any attachments unless you trust the sender and know the content is safe. EXPÉDITEUR EXTERNE: Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous ayez l'assurance que le contenu provient d'une source sûre. |
Heaton, Joseph@Wildlife
Thanks, Michael, I’ve read that article, and understand how scavenging works. My biggest concern in my rambling is, how much more replication traffic are we going to get changing the times to 1 hour each, so that stale records would get deleted every ~3 hours. Also, the risk of deleting a record that’s not actually stale, just logged off, or something. Do I need to adjust my DHCP lease times to shorter, to accommodate the fact that DNS records that were handed out may be deleted prematurely?
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com>
On Behalf Of Michael B. Smith
Sent: Tuesday, March 9, 2021 12:08 PM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] RE: DNS scavenging
WARNING: This email originated from outside of CDFW and should be treated with extra caution.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/b22aede541f24123a8b6e81e758a9905%40smithcons.com.
Michael B. Smith
Refresh + no-refresh should be less than or equal to DHCP lease time.
In other words, if you are going to delete every three hours then your DHCP lease time should probably also be three hours and certainly no more than 4.5 hours.
IMO. This is starting to get into “fuzzy” territory. 😊
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/SJ0PR09MB6686323E3A6A65711A5621F8AA919%40SJ0PR09MB6686.namprd09.prod.outlook.com.
Heaton, Joseph@Wildlife
That’s kind of what I was thinking, as well. Thanks!
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com>
On Behalf Of Michael B. Smith
Sent: Wednesday, March 10, 2021 8:07 AM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] RE: DNS scavenging
WARNING: This email originated from outside of CDFW and should be treated with extra caution.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/ec44b62b17ab45f4987d5000d2b4b07b%40smithcons.com.
don.l....@gmail.com
>> when you look them up, you get the wrong IP
Sorry, but, why?
When the device gets a different IP, the DNS record for the device (the A/AAAA record) gets updated with the new/correct IP address, right?
If a device is active, scavenging shouldn’t ever be an issue?
When a device leaves the network and doesn’t come back, and if it doesn’t signal to cleanup it’s record via DHCPrelease, then that’s when scavenging becomes necessary.
And if it’s a managed device, you’ll eventually cleanup those device records, which if you’re using AD-integrated DNS, will delete the DNS records too, right?
I’m obviously missing something here...
we have a big DNS accuracy (stale records) issue in our org but it’s kind of intentional (we use BIND DDNS not AD for DNS so we don’t have any scavenging mechanism)
Don
From: Heaton, Joseph@Wildlife
Sent: Wednesday, 10 March 2021 4:41 AM
To: ntsys...@googlegroups.com
Subject: [ntsysadmin] DNS scavenging
--
Jonathan Raper
Sent: Friday, March 12, 2021 10:53:49 PM
To: ntsys...@googlegroups.com <ntsys...@googlegroups.com>
Subject: RE: [ntsysadmin] DNS scavenging
Kurt Buff, GSEC/GCIH/PCIP
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/2F983D02-5089-416A-B0C9-EFB7FB7723D8%40hxcore.ol.
Heaton, Joseph@Wildlife
Our VPN is through a Cisco ASA, which I assume doesn’t have the rights to update DNS. So, if a user logs in at work, then takes the laptop home, and logs into the VPN, they get a different IP, but that doesn’t get reflected in DNS. So things that rely on DNS to contact endpoints (everything?) gets confused. For us, the big thing is SCCM among others.
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com>
On Behalf Of don.l....@gmail.com
Sent: Friday, March 12, 2021 7:54 PM
To: ntsys...@googlegroups.com
Subject: RE: [ntsysadmin] DNS scavenging
WARNING: This email originated from outside of CDFW and should be treated with extra caution.
>> when you look them up, you get the wrong IP
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/2F983D02-5089-416A-B0C9-EFB7FB7723D8%40hxcore.ol.
Jonathan Raper
To: ntsys...@googlegroups.com <ntsys...@googlegroups.com>
Jim Behning
I have one ASA, maybe a few where the VPN does assign an IP in the subnet that ASA and 30 workstations are on. A few other ASAs that do a totally different IP scheme.
Jim Behning
404-643-8863
From: Jonathan Raper
Sent: Wednesday, March 17, 2021 7:34 PM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] DNS scavenging
You could possibly create the VPN DHCP pool for the VPN subnet on your DC and configure a helper entry on the ASA that points DHCP requests to the DC. At that point DHCP and DNS would be dealt with, no?
Jonboy
Get Outlook for iOS
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CS1PR8401MB07753803D8C8BBA2EB476D14A96A9%40CS1PR8401MB0775.NAMPRD84.PROD.OUTLOOK.COM.
Kurt Buff, GSEC/GCIH/PCIP
solve the problem.
Forward (A/AAAA) and reverse (PTR) DNS entries have lifetimes of weeks
(by default two weeks plus some amount of time).
The situation described is for when a machine moves between subnets
within a short period of time.
Assume the organizations domain is example.com, and the at-work subnet
is 10.1.1.0/24, and the VPN subnet is 10.2.1.0/24.
Machine is at work for one day and gets address 10.1.1.22, which
registers the forward address in the example.com zone and the reverse
address in the reverse zone (normally) 1.1.10.in-addr.arpa.
Then worker brings machine home that night, logs into VPN and gets
address address 10.2.1.22, which registers in the address in the
forward example.com zone and the reverse zone 1.2.10.in-addr.arpa.
The registration of DNS entries by DHCP (or by the machine directly)
*does not* change the current A/AAAA or PTR records. It sets up new
records. It must be this way, otherwise machines with more than one
NIC or address wouldn't work.
As a result, the machine now has 4 DNS entries - two in the
example.com zone and one in each of the relevant reverse zones.
All of these entries will normally last for the sum of the no-refresh
interval plus the refresh interval, plus some amount of time (gt 0) of
the scavenging period.
Assuming that the default 7 days for the refresh/no-refresh intervals,
and 7 days for the scavenging period, it could be as much as three
weeks before any of the records disappear from any of the zones.
What happens at that point is that the A records are essentially
"round-robined", and you don't know which you're going to get when
doing name resolution.
I don't know of a good way to work around this.
Kurt
Jonathan Raper
Sent: Wednesday, March 17, 2021 9:34:47 PM
To: ntsys...@googlegroups.com <ntsys...@googlegroups.com>
Subject: Re: [ntsysadmin] DNS scavenging
Micheal Espinola
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce7ym_b_A7S32Yo7mRtoJrc4pmptLKPRj4NVJGkW3aYpRQ%40mail.gmail.com.
Kurt Buff, GSEC/GCIH/PCIP
Search for host name (all hostnames?) in VPN reverse zone, and if
found, see if there are non-matching records in both the forward and
reverse zones, ping all of them (by hostname or IP address, or both?)
and see which answers.
Those that don't answer get deleted. How to decide if an IP address
answers and it's another machine? Make sure the DHCP lease matches the
scavenging period, I suppose, but you'll have to make sure that the
VPN DHCP scope is large enough to cover the reverse zone, and/or that
the lease period matches the maximum scavenging period
(refresh+no-refresh+scavenging).
How often to do this, and at what times of day?
Doable, but not trivial, I suppose.
Probably some other questions to ask/answer as well, but that's all I
can think of at this hour, and after a couple of glasses of wine.
Kurt
don.l....@gmail.com
>> The registration of DNS entries by DHCP (or by the machine directly)
*does not* change the current A/AAAA or PTR records. It sets up new
records. It must be this way, otherwise machines with more than one
NIC or address wouldn't work.
Sorry, wut?
An A record is an A record is an A record..
How could this be otherwise?
WINPC001.in.contoso.com = 10.1.1.47
When WINPC001 changes its address, (via any means/NIC) the above A record is updated (by DHCP or DDNS from the device or whatever)
Last writer wins.
Multiple NICS, pffft, last writer wins.
If you really wanted to, I guess you could set connection-specific-suffixes differently for your corp-wired vs corp-wifi, and even for your corp-vpn range too, if you wished, so that you could then have “multiple A records for the multiple NICs in your portable devices”.
(but I’m not sure why that would be especially useful, since, when I want to connect to a device, I typically want that last-written-one as that’s most likely to be current.
No?
Don
(still learning after all these years, who knew? :)
From: Kurt Buff, GSEC/GCIH/PCIP
Sent: Thursday, 18 March 2021 12:35 PM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] DNS scavenging
While that would be a good thing to do, if possible, that would not
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce7ym_b_A7S32Yo7mRtoJrc4pmptLKPRj4NVJGkW3aYpRQ%40mail.gmail.com.
Jim Behning
I do not recall seeing a proper description of this network. Does this network have 10 computers or 3,200? Does it have 13 laptops that come to the office and go home or out in the field to VPN back in? May not be relevant to the discussion.
Jim Behning
404-643-8863
From: don.l....@gmail.com
Sent: Thursday, March 18, 2021 5:04 AM
To: ntsys...@googlegroups.com
Subject: RE: [ntsysadmin] DNS scavenging
>> The registration of DNS entries by DHCP (or by the machine directly)
*does not* change the current A/AAAA or PTR records. It sets up new
records. It must be this way, otherwise machines with more than one
NIC or address wouldn't work.
Sorry, wut?
An A record is an A record is an A record..
How could this be otherwise?
WINPC001.incontoso.com = 10.1.1.47
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+unsubscribe@googlegroupscom.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce7ym_b_A7S32Yo7mRtoJrc4pmptLKPRj4NVJGkW3aYpRQ%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/5B5B437C-BDCB-495A-9F09-AB8FC2A0337A%40hxcore.ol.
Melvin Backus
What happens when said user takes the machine home and works offline without connecting to the VPN then comes back into the office expecting the unexpired dhcp lease to still be valid?
Are you expecting to remove the DHCP lease as well as the DNS entries?
Are these machines getting shutdown prior to leaving the office or put to sleep? Windows *should* release the IP if the former, but won't for the later. We run into problems with this causing DNS issues for users because they may have internally resolved IPs for resources which suddenly are no longer valid when they connect from the VPN, etc. Explaining the reasons is sometimes problematic at best, and convincing users that a shutdown is a proper choice is a futile effort. :)
--
There are 10 kinds of people in the world...
those who understand binary and those who don't.
¯\_(ツ)_/¯
-----Original Message-----
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Kurt Buff, GSEC/GCIH/PCIP
Sent: Wednesday, March 17, 2021 11:25 PM
To: ntsys...@googlegroups.com
Subject: Re: [ntsysadmin] DNS scavenging
Kurt Buff, GSEC/GCIH/PCIP
>>> The registration of DNS entries by DHCP (or by the machine directly)
>> *does not* change the current A/AAAA or PTR records. It sets up new
>> records. It must be this way, otherwise machines with more than one
>> NIC or address wouldn't work.
>
> Sorry, wut?
> An A record is an A record is an A record..
different IP addresses. It's still used as a form of load balancing.
> How could this be otherwise?
> WINPC001.in.contoso.com = 10.1.1.47
>
> When WINPC001 changes its address, (via any means/NIC) the above A record is updated (by DHCP or DDNS from the device or whatever)
> Last writer wins.
> Multiple NICS, pffft, last writer wins.
> If you really wanted to, I guess you could set connection-specific-suffixes differently for your corp-wired vs corp-wifi, and even for your corp-vpn range too, if you wished, so that you could then have “multiple A records for the multiple NICs in your portable devices”.
> (but I’m not sure why that would be especially useful, since, when I want to connect to a device, I typically want that last-written-one as that’s most likely to be current.
>
> No?
doesn't go away, sometimes for a very long time, and I have to
manually delete it.
> Don
> (still learning after all these years, who knew? :)
on a different subnet, wirelessly. Let me know what you find. It's
been my experience that this will register two A records.
Kurt
Kurt Buff, GSEC/GCIH/PCIP
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
it1.example.com A 1200 Answer 10.5.40.29
it1.example.com A 1200 Answer 10.5.20.157
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/1ADD796D2529E94DB4552E7C1F12A21A017C795E79%40ATLEXCH04.byers.local.
Kurt Buff, GSEC/GCIH/PCIP
Heaton, Joseph@Wildlife
Our "solution" for the moment, is to reduce our no-refresh/refresh times and scavenging time to 1 hour each, to try and minimize the time there are multiple records. My original question was asking if this was a wise thought, or would it just add layers of complexity/confusion to the whole process.
-----Original Message-----
From: ntsys...@googlegroups.com <ntsys...@googlegroups.com> On Behalf Of Kurt Buff, GSEC/GCIH/PCIP
Sent: Wednesday, March 17, 2021 6:35 PM
To: ntsys...@googlegroups.com
>
>
> --
> You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "ntsysadmin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ntsysadmin+...@googlegroups.com.
Kurt Buff
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/SJ0PR09MB6686F011FF77DE05573D9733AA689%40SJ0PR09MB6686.namprd09.prod.outlook.com.
don.l....@gmail.com
Ok, wow.
Thanks Kurt, somehow I had not imagined that our corp implementation was unusual (we only allow single A records for our ‘workstation’ zone).
I just reacquainted myself with RFC1035 and of course what you guys have said fits perfectly, and our corp setup is weird.
(how could I forget our weirdness? It’s startling what you get used to...)
Just goes to show what assumptions can do ☹
Thanks to all – I appreciate this community so much! 😊
Don
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce6TPJcCQDBRrkDa4QhfqF6jv%2BKTai5JhUKp7DS8NKMd8A%40mail.gmail.com.
Kurt Buff
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/466CDDC2-6BC1-489E-B392-0B8E73BCFB03%40hxcore.ol.
Heaton, Joseph@Wildlife
I hadn’t read that specific article, but have read lots of other, very similar ones. Our plan is to make all 3 settings, 1 hour, including the scavenging schedule. Having it all that short raises a red flag in my head, but I still can’t put a finger on it. Other than increased network traffic, and ensuring servers won’t fall victim, I can’t think of what could be causing that thought in the back of my head.
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/CADy1Ce4oUcK5xtqoG5Q6naQ%3DSDCU6HxPX3L0nvZWCKgOvbdCAg%40mail.gmail.com.
Kurt Buff
To view this discussion on the web visit https://groups.google.com/d/msgid/ntsysadmin/SJ0PR09MB6686AB6C23104F0CC04995DFAA7D9%40SJ0PR09MB6686.namprd09.prod.outlook.com.