SystemError when record contains special characters.

[steven2308]

Hi, I have a very similar problem to this solved issue:

import asyncio
import aiodns

loop = asyncio.get_event_loop()
resolver = aiodns.DNSResolver(loop=loop)
result = loop.run_until_complete(resolver.query('xn--cardeosapeluqueros-r0b.com', 'MX'))
print(result)

I get this error and the program hangs.

Exception ignored in: functools.partial(<function DNSResolver._callback at 0x7fe1067b2ea0>, <Future pending cb=[_run_until_complete_cb() at /usr/local/lib/python3.6/asyncio/base_events.py:176]>)
Traceback (most recent call last):
  File "/home/steven/Envs/vPandapipe/lib/python3.6/site-packages/aiodns/__init__.py", line 56, in _callback
    if fut.cancelled():
SystemError: <built-in method cancelled of _asyncio.Future object at 0x7fe106ee7828> returned a result with an error set

Looking further I found that this problem happens when the result of the query has special characters,
Doing a ns lookup I found this for MX:

Non-authoritative answer:
 xn--cardeosapeluqueros-r0b.com mail exchanger = 10 carde\241osapeluqueros.com.

Querying SOA for ayesas.com. Its record also contains a special character:

Non-authoritative answer:
ayesas.com
	origin = ns2.3c1b.com
	mail addr = adm\253n.domain.com
	serial = 2015010244
	refresh = 3600
	retry = 600
	expire = 1209600
	minimum = 3600

I'm using aiodns 1.1.1 and pycares 2.3.0.

Thank you!

[saghul]

Hi there! Yep, I see the issue. Looks like a fix is need in pycares. This makes me wonder where else we could find such chars, so a big change, returning bytes everywhere sounds about the right thing to do...

FTR:

dig mx xn--cardeosapeluqueros-r0b.com

; <<>> DiG 9.9.7-P3 <<>> mx xn--cardeosapeluqueros-r0b.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2315
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;xn--cardeosapeluqueros-r0b.com.	IN	MX

;; ANSWER SECTION:
xn--cardeosapeluqueros-r0b.com.	900 IN	MX	10 carde\241osapeluqueros.com.

;; Query time: 93 msec
;; SERVER: 10.53.53.53#53(10.53.53.53)
;; WHEN: Wed Jan 31 16:13:49 CET 2018
;; MSG SIZE  rcvd: 95

dig soa ayesas.com

; <<>> DiG 9.9.7-P3 <<>> soa ayesas.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56952
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ayesas.com.			IN	SOA

;; ANSWER SECTION:
ayesas.com.		3600	IN	SOA	ns2.3c1b.com. adm\253n.domain.com. 2015010244 3600 600 1209600 3600

;; Query time: 127 msec
;; SERVER: 10.53.53.53#53(10.53.53.53)
;; WHEN: Wed Jan 31 16:14:29 CET 2018
;; MSG SIZE  rcvd: 97

Are you up for writing a patch?

[steven2308]

Sadly I'm not familiar with CPython and not even with C. I don't think I'm suitable for such change.

[saghul]

That's ok, but that means you'll need to wait until I find the time to solve this all across the library.

[steven2308]

I understand, we have found some hacky workaround while it happens. Thanks for your time!

[saghul]

Almost a year later... I'm preparing a new pycares release here: saghul/pycares#83 and then I'll update this library to use it and this bug will be fixed.

I took the liberty of using your domain examples as tests :-)

[saghul]

This is not fixed in the ongoing V2 PR: #54 which depends on the new pycares 3.