DNS Problems

One area of grief is DNS, badly implemented name servers, and security features in DNS. For example, consider a router with a large number of primary and secondary IP addresses. Suppose that a client such as NNM requests the name for 1.1.1.1 (using the standard resolver). As a security precaution, the resolver insists that the resulting name should map back to the same IP address. But some DNS name servers truncate long lists of IP addresses (because they don’t revert to TCP for replies longer than 512 bytes), then the original lookup request returns no name. This will confound NNM because it can’t map the IP address to a name, and thus can’t use the proper community string to communicate with it.

Another example of DNS grief is simply a change in the name and IP mappings. If a device’s IP address is changed, and if DNS properly reflects it, the community string isn’t going to be correct if NNM is still configured with the old IP address, and NNM will therefore fail to communicate with the device SNMP agent.

Obviously, if the DNS is configured and implemented properly, and if you can use names instead of IP addresses to associate custom SNMP community strings, and if you keep NNM’s SNMP configurations up to date, you can avoid these problems. In a large, distributed, dynamic corporate network that’s a lot of ifs.