-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error when retrieving binary data in TXT records #100
Comments
Do you know if c-area is capa of parsing those? Do you have a sample record I could query? |
I'm not sure whether c-ares is doing it as it should or not, but I guess it should be supposed to because the RFC indicates that's how it should be done For instance I'm trying to use this byte string as a TXT record (I'm using dnslib to pack the data, which works as expected when I inspect the packet, and aiodns to receive and parse the packet, which shows an empty record):
and (perhaps because the first byte is null) it outputs as an empty string |
The bug is most likely here: https://github.com/saghul/pycares/blob/4e6e36f839255ebef05e0682b98cbee1533805ce/src/pycares/__init__.py#L749-L764 -- the txt reply structures do have a A patch would be most welcome! |
I guess it is this indeed https://github.com/saghul/pycares/blob/4e6e36f839255ebef05e0682b98cbee1533805ce/src/pycares/utils.py#L21 it should not necessarily force a decoding as ascii, it should be a "bytes" response (but this might break existing code as it means that the result of the resp.text is "bytes" rather than "str", and it is to each user to know how to interpret it, although this would be the correct way to do it) |
We are already returning bytes sometimes, and str just when the response is strictly ascii. Can't we keep that behavior? |
So I guess the real "error" is there, trying to cast to a |
The correct way seems to be
|
This PR fixes the bug saghul/pycares#160 |
The RFC1035 indicates that TXT records are "" which are to be interpreted as binary data of length at most 255, prefixed with a length character.
If I'm packing a TXT record containing a null byte, it is not correctly parsed by the library and the parsed output contains an empty buffer
The text was updated successfully, but these errors were encountered: