Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Skepticism and critical thinking is not panacea, but can help to understand the world better

DNS Tips


dig - DNS lookup utility Online DNS Tools Perl-based DNS Tools DNS Audit Scripts DNS Zone Generators


VIM Tips AWK one liners Shell Tips and Tricks Perl Tips   Humor Etc

Although dig is more convenient, you can get a version of a nameserver using nslookup:

> set q=txt

> set class=chaos

> version.bind



VERSION.BIND text = "8.2.2-P7" System Administration Guide Naming and Directory Services (DNS, NIS, and LDAP) Changes Do Not Take Effect or Are Erratic

Symptom You add or delete machines or servers but your changes are not recognized or do not take effect. Or in some instances the changes are recognized and at other times they are not yet in effect.

Probable cause  The most likely cause is that you forgot to increment the SOA serial number on the master server after you made your change. Since there is no new SOA number, your slave servers do not update their data to match that of the master so they are working with the old, unchanged data files.

Another possible cause is that the SOA serial number in one or more of the master data files was set to a value lower than the corresponding serial number on your slave servers. This could happen, for example, if you deleted a file on the master and then recreated it from scratch using an input file of some sort.

A third possible cause is that you forgot to send a HUP signal to the master server after making changes to the primary's data files.

Diagnosis and solution First, check the SOA serial numbers in the data file that you changed and the corresponding file on the slave server.

[syslog-ng] Resolving Hostnames for Syslog Source IPs

Valdis.Kletnieks at Valdis.Kletnieks at
Wed Jun 1 22:52:47 CEST 2005
On Wed, 01 Jun 2005 09:33:58 PDT, Jarrod Manzer said:
> I had this same problem. I resolved it by logging by IP and then doing 
> reverse DNS lookups with a script and creating symbolic links to those 
> IP based directories. The end result was people who like to use IP or 
> DNS were happy. Gotta make sure your reverse is set up properly though.
> But I never did find out why syslog-ng couldn't resolve the same names 
> that the host command on the same box could.

The most common cause for things like this is semi-borked DNS that *appears*
to work, but in fact is subtly misconfigured.

A few things to check:

1) Take the IP address, and look up the PTR, which should give you a hostname
(this is where most 'host' commands stop). Then actually check that hostname
in the DNS, and make sure the IP is listed in an A record (some resolvers do
this additional sanity checking).

2) You may have a "lame delegation". Look at the SOA and NS entries for your
DNS zones, both PTR and A, and double-check that all machines listed in NS are
in fact serving up correct data for the zones (a quick double-check is if all
the DNS servers show the correct zone serial number in the SOA). It often happens
that if there are multiple NS records, a daemon will "lock in" on asking one NS
first, and if it returns an authoritative NXDOMAIN because it's a lame delegation,
the daemon won't ask other NS.  However, when you use the 'host' command, it may
check some *other* NS entry first and magically appear to work.

3) Double-check /etc/resolv.conf to make sure it points 'nameserver' entries
at DNS servers that pass the sanity checks in (1) and (2)....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url :

More information about the syslog-ng mailing list


The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright 1996-2018 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Created May 16, 1996; Last modified: March 12, 2019