Re: [SLUG] debugging dns resolution issues with RES_OPTIONS=debug
Ben Burke wrote: 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) I admittedly haven't delved deep into the dig man page, but a suggestion would be to add a suitable dig incantation to your cron job just before requiring DNS services, just to see what is happening in detail at the time. At least you'd have a log written to stdout that you can examine for anomalies when something awry happens with that server. cheers rickw -- _ Rick Welykochy || Praxis Services Hofstadter's Law. It always takes longer than you expect, even when you take into account Hofstadter's law. -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] debugging dns resolution issues with RES_OPTIONS=debug
Rick, Thanks - yes, that will help, though I don't think I'll get close enough to the problem to decide if it's ip communications or a windows dns server issue. (I could do other connectivity tests to the dns servers, same result) I came across these options when working with a really nasty performance problem, involving AIX dns clients, resolving names on win2k3 servers. At the time, I was being pushed to populate hosts files on dozens of unix hosts, rather than get to the bottom of what was going on. Eventually, we found that the AIX version in use would attempt ipv6 style dns client behaviour several times, before failing back to ipv4 behaviour. At the time, IBM gave us no support what so ever - just blamed microsoft. As usual, the way to solve a vendor war is, get to the root of the problem. I'm pretty clueless on where gethostbyname lives in the os. My guess would be, a shared library that many programs link against, rather than part of the kernel.. This was the kind of info I was looking for. Thanks for everybody's input so far. b Ben Burke wrote: 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) I admittedly haven't delved deep into the dig man page, but a suggestion would be to add a suitable dig incantation to your cron job just before requiring DNS services, just to see what is happening in detail at the time. At least you'd have a log written to stdout that you can examine for anomalies when something awry happens with that server. cheers rickw -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] debugging dns resolution issues with RES_OPTIONS=debug
2010/1/27 Ben Burke ben.bu...@internode.on.net: Rick, Thanks - yes, that will help, though I don't think I'll get close enough to the problem to decide if it's ip communications or a windows dns server issue. (I could do other connectivity tests to the dns servers, same result) I came across these options when working with a really nasty performance problem, involving AIX dns clients, resolving names on win2k3 servers. At the time, I was being pushed to populate hosts files on dozens of unix hosts, rather than get to the bottom of what was going on. Eventually, we found that the AIX version in use would attempt ipv6 style dns client behaviour several times, before failing back to ipv4 behaviour. At the time, IBM gave us no support what so ever - just blamed microsoft. As usual, the way to solve a vendor war is, get to the root of the problem. I'm pretty clueless on where gethostbyname lives in the os. My guess would be, a shared library that many programs link against, rather than part of the kernel.. This was the kind of info I was looking for. Hi Rick gethostbyname is part of GNU libc implementation. Therefore, you'd have to check out its resolver library to do anything serious with `options debug` on your /etc/resolv.conf (its disabled by default for some reason). Other implementations such as AIX which you use has it enabled by default. AFAIK, most BSDs have them enabled too. HTH [...] -- Regards Ishwor Gurung Key id:0xa98db35e Key fingerprint:FBEF 0D69 6DE1 C72B A5A8 35FE 5A9B F3BB 4E5E 17B5 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] debugging dns resolution issues with RES_OPTIONS=debug
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
Re: [SLUG] debugging dns resolution issues with RES_OPTIONS=debug
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
