[Twisted-Python] t.n.c.lookupAddress returns DNSNameError for hostnames w/ no A record
Hi all, I saw in previous posts that DNSNameError signifies an 'NXDOMAIN' status and DNSServerError signifies 'SERVFAIL'. However, I am getting a DNSNameError from twisted.names.client.lookupAddress() when I query a hostname that has no A records, but *does have* other records (NS, SOA, etc). An example: ; <<>> DiG 9.8.3-P1 <<>> megaupload.com ANY ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19402 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;megaupload.com. IN ANY ;; ANSWER SECTION: megaupload.com. 21600 IN SOA ns5.cirfu.net. ipr.ic.fbi.gov. 2013022001 3600 900 604800 900 megaupload.com. 21600 IN NS ns5.cirfu.net. megaupload.com. 21600 IN NS ns6.cirfu.net. dig is telling me 'status: NOERROR'. Is there an easy way to determine the status of a DNS query from a twisted.names.dns.Message ? I checked the source and it wasn't readily apparent (to me). In my code I'm checking the value of failure.value.__class__.__name__ to determine if an answer is NX or SERVFAIL. Seems like there should be a better way... Here's the code if anybody wants to take a look: http://paste.ubuntu.com/5669612/ Thanks to the Twisted devs and maintainers for all your hard work! byrsa
On 06:48 am, byrsa@sinkhole.me wrote:
Hi byrsa, The behavior you're describing does sound wrong. However, I wasn't able to reproduce it locally. Running your example, I get [] for megaupload.com, not an error. Perhaps there is a tricky DNS server involved somewhere that is changing the response unexpectedly? I suggest using something like tcpdump or wireshark to take a look at the actual traffic and perhaps produce a more deterministic demonstration of the problem. Regarding how you should detect certain errors, though, Failure just wraps normal exceptions, so you can use `isinstance` to check for them instead of checking by name. Failure also provides some APIs that wrap up isinstance to provide some more commonly useful behavior - see Failure.check and Failure.trap. And regarding determining error from a Message, you can use the rCode attribute to get the raw server response code as an integer. The values and their meanings are defined in the DNS RFC and there are symbolic constants in twisted.names.dns - eg OK, ENAME, ESERVER, etc. Hope this helps, Jean-Paul
On Tue, Apr 2, 2013 at 5:03 AM, <exarkun@twistedmatrix.com> wrote:
You are correct! I was running the code on a Linux machine and the 'dig' command on my Macbook. The answers were different. At least I know the code is working!
'isinstance' was my initial thought, as well. I'll have to re-visit that. Thanks for the pointer.
That doesn't sound too bad.
Hope this helps, Jean-Paul
Your feedback has been immensely helpful, thanks a lot, Jean-Paul! byrsa
On 06:48 am, byrsa@sinkhole.me wrote:
Hi byrsa, The behavior you're describing does sound wrong. However, I wasn't able to reproduce it locally. Running your example, I get [] for megaupload.com, not an error. Perhaps there is a tricky DNS server involved somewhere that is changing the response unexpectedly? I suggest using something like tcpdump or wireshark to take a look at the actual traffic and perhaps produce a more deterministic demonstration of the problem. Regarding how you should detect certain errors, though, Failure just wraps normal exceptions, so you can use `isinstance` to check for them instead of checking by name. Failure also provides some APIs that wrap up isinstance to provide some more commonly useful behavior - see Failure.check and Failure.trap. And regarding determining error from a Message, you can use the rCode attribute to get the raw server response code as an integer. The values and their meanings are defined in the DNS RFC and there are symbolic constants in twisted.names.dns - eg OK, ENAME, ESERVER, etc. Hope this helps, Jean-Paul
On Tue, Apr 2, 2013 at 5:03 AM, <exarkun@twistedmatrix.com> wrote:
You are correct! I was running the code on a Linux machine and the 'dig' command on my Macbook. The answers were different. At least I know the code is working!
'isinstance' was my initial thought, as well. I'll have to re-visit that. Thanks for the pointer.
That doesn't sound too bad.
Hope this helps, Jean-Paul
Your feedback has been immensely helpful, thanks a lot, Jean-Paul! byrsa
participants (2)
-
byr sa -
exarkun＠twistedmatrix.com