Easy way to remove stale DNS entries

[Stormont]

We have two clusters that we have been running since 8.3.2P2 (now on 9.7P7) and we noticed that when we run "vserver services dns hosts show" there are a number of entries for servers that no longer exist in DNS and some entries that have the wrong name with the IP.  Is there an easy way to force the ones that no longer have a DNS entry to be deleted or do we have to manually delete all of the entries that are stale/incorrect?

[ttran · Accepted solution]

Hi Stormont,

I know you mentioned that you started using this Cluster on ONTAP 8.3.2P2; was this Cluster migrated from 7-mode or pre-8.3? The reason I ask is there was significant changes to how we handle name-services from 8.2 to 8.3, which could have left the stale entries. Dynamic DNS was also introduced in ONTAP 8.3.1; not sure if that was ever enabled. It would be difficult to clearly identify where the stale DNS entries came from without digging through historical ASUP's to see whom and when they were added.

I definitely recommend using @scottgelb recommendations to remove the stale entries to avoid interruptions to access.

Here is an in-depth technical report covering name-services: TR-4379 Name Services Best Practices Guide 

Regards,

Team NetApp

[scottgelb]

It may be easier to flush the entire hosts cache.  "set adv" mode

vserver services name-service cache hosts forward-lookup delete-all -vserver svmname

vserver services name-service cache hosts reverse-lookup delete-all -vserver svmname

[Stormont]

This is where things really get weird.  When I go into advanced mode and run "vserver services name-service cache hosts forward-lookup show" it lists a number of servers, however the outdated servers that show up when running "vserver services dns host show" aren't in that list.  I am the sole NetApp administrator and I know that I never created entries for the servers via "vserver services dns host create", so I'm really not sure where these entries came from or how to get rid of them (short of manually deleting each one via "vserver services dns hosts -delete").  Maybe an earlier version of OnTap did something differently?

[scottgelb]

If they are stale, then delete the manual entries... double, triple check though 🙂

[scottgelb]

These sound like manual entries in the hosts table... "vserver services dns hosts create" will add entries .. they were manually added so to remove them you do need to delete them to rely on DNS instead....well one more check, dependent on ns-switch.. depending on the output of "vserver services ns-switch show -vserver svmname -database hosts"... if the output has dns before files, or if files is missing, then the manual entry doesn't matter as long as that same host is also in dns.

[Stormont]

The results of that command are below:

Oriole::> vserver services ns-switch show -vserver oriole-svm -database hosts

Vserver: oriole-svm
Name Service Switch Database: hosts
Name Service Source Order: files, dns

One example that really stands out is an entry that shows an address associated with our HAProxy and a hostname of an actual website hosted via that device; neither of them have any NetApp mounted storage.  We never added the address manually, so where did it come from?

Same deal with there being entries for the IP addresses associated with switches in our network that have no network mounted storage, but they show up in the hosts section (and were not added as there has never been a reason to add them).

[scottgelb]

Got it so the hosts entry will be the first used on match since "files" is first... you could set dns first then bypass the entries if you don't want to delete them right away, as long as dns has a record for the manual entry.  It looks like something added those...maybe automation outside of the admin or something?

[Stormont]

No, we definitely don't have any sort of automation setup. If this was a leftover artifact from some previous version, we can clean them up, but I wanted to try and see if there is a way to prevent that from happening or to automate the process to cleanup entries.

________________________________

Information in this e-mail may be confidential. It is intended only for the addressee(s) identified above. If you are not the addressee(s), or an employee or agent of the addressee(s), please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender of the error.