Thanks Rodolfo,

Yes, I know about dig. But the problem I'm having appears to be failure of dns server to respond, or a communications problem with dns server(s)

The problem I'm having is intermittent. I have a number of cron jobs that fail occasionally, failing to resolve a host name.

The benefit of the option debug statement in resolv.conf is that the trace information will be written to stdout. This will allow me to see the nature of these intermittent failures.

I strongly suspect a problem with the microsoft windows (win2k3 server) name services in this environment (yes I know - In jamie from Mythbusters voice they all say "There's your problem!"). I just need to prove that to be the case, or at least isolate what's going on.

cheers,
b
Hi Ben,

You can debug most (all?) of the DNS client resolution issues with dig.

You can test all the DNS client features, from a simple query to a
full transfer zone.

Regards
Rodolfo Martínez
Dirección de Proyectos
Aleux México | http://www.aleux.com



On Tue, Jan 26, 2010 at 5:04 PM, Ben Burke <ben.bu...@internode.on.net> wrote:
Hello,

This is my first post to slug - hopefully I've understood protocol from
reading the list for a month or so.

In the past, I've diagnosed dns client resolution issues using "options
debug" in resolv.conf or setting the RES_OPTIONS environment variable as
follows...

export RES_OPTIONS="debug"

r...@aixbox:/ <mailto:r...@toranim1:/> > ping smh.com.au <http://smh.com.au>
;; res_setoptions("debug", "env")..
;;      debug
;;      calling process id = 614598
;; res_nquerydomain(smh.com.au <http://smh.com.au>, <Nil>, 1, 1)
;; res_query(smh.com.au <http://smh.com.au>, 1, 1)
;; res_nmkquery(QUERY, smh.com.au <http://smh.com.au>, IN, A)
;; res_send()
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 467
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;;      smh.com.au <http://smh.com.au>, type = A, class = IN
;; Querying server (# 1) address = 10.201.4.8
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 467
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;;      smh.com.au <http://smh.com.au>, type = A, class = IN
smh.com.au <http://smh.com.au>.             1m12s IN A      203.26.51.71
PING smh.com.au <http://smh.com.au> (203.26.51.71): 56 data bytes
--- smh.com.au <http://smh.com.au> ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss


This has provided a means of tracing dns resolution issues, which has proved
to be valuable for me on many occasions - the environments have been AIX,
Solaris and Tru64


I  use and manage two linux distros - Ubuntu 9.04 and sUSE 11.1. Both these
distros document the options debug in the man page for resolv.conf

However, neither Ubuntu or sUSE yield any dns client trace where I'd expect
them too.


b...@sam:~$ uname -a
Linux sam 2.6.28-17-generic #58-Ubuntu SMP Tue Dec 1 18:57:07 UTC 2009 i686
GNU/Linux

b...@sam:~$ export RES_OPTIONS="debug"
b...@sam:~$ ping www.smh.com.au
PING a1040.b.akamai.net (150.101.195.89) 56(84) bytes of data.
64 bytes from 150.101.195.89: icmp_seq=1 ttl=61 time=30.9 ms



Many moons ago, when I first read about options debug, I recall that
gethostbyname could be built with or without various RES_OPTIONS.

So, my questions are:

1) Is this the expected behaviour on various Linux distros or am I missing
something?
2) Can anyone advise how to enable the debug capabilities in gethostbyname?



Thanks in advance,

Ben Burke
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html



--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to