Skip to content
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

Classless PTR delegation leads to EBADRESP #427

Closed
leftshift opened this issue Oct 8, 2021 · 3 comments
Closed

Classless PTR delegation leads to EBADRESP #427

leftshift opened this issue Oct 8, 2021 · 3 comments

Comments

@leftshift
Copy link

When resolving the PTR record for IPs for which Classless IN-ADDR.ARPA delegation is used as specified in RFC2317, the lookup fails with EBADRESP.

This is because the / in the CNAME record doesn't pass the is_hostnamech check.

As an example, the result for looking up the PTR of 93.122.82.36:

$ dig -t PTR 36.82.122.93.in-addr.arpa
[...]
;; ANSWER SECTION:
36.82.122.93.in-addr.arpa. 28800 IN	CNAME	36.0/25.82.122.93.in-addr.arpa.
36.0/25.82.122.93.in-addr.arpa.	600 IN	PTR	mtx01a.wirtgen-group.com.
[...]

This is a regression introduced in version 1.17.2 as it is now impossible to resolve PTR records where this delegation is in use with the suggested / character, and this was working before.

I understand the desire of protecting users of this library from XSS and similar issues and can understand that allowing the / character in results may not be correctly handled by users of the library in some specific cases, but I feel quite a legitimate use case that is specified in an RFC is broken in a fairly unexpected manner.

bradh352 added a commit that referenced this issue Oct 8, 2021
As of c-ares 1.17.2, a CNAME an in-addr.arpa delegation broke due
to not allowing '/'.  This needs to be allowed to not break valid
functionality.

Fixes Bug: #427
Reported By: Adrian (@leftshift)
Fix By: Brad House (@bradh352)
@bradh352
Copy link
Member

bradh352 commented Oct 8, 2021

I agree. Fixed.

@bradh352 bradh352 closed this as completed Oct 8, 2021
@gvanem
Copy link
Contributor

gvanem commented Oct 9, 2021

I may be an imbecile, but what was the problem before this patch.
A adig -s 1.1.1.1 -t PTR 36.82.122.93.in-addr.arpa here:

Answers:
        36.82.122.93.in-addr.arpa.      28800   CNAME   36.0/25.82.122.93.in-addr.arpa.
        36.0/25.82.122.93.in-addr.arpa. 600     PTR     mtx01a.wirtgen-group.com.

same as dig above (no EBADRESP and adig -s 1.1.1.1 -t PTR -x 36.82.122.93 gives the same).
You mean dig is correct and adig is not?

@bradh352
Copy link
Member

bradh352 commented Oct 9, 2021

adig() uses very low-level calls and does manual parsing, it only impacted users of higher level functions like ares_parse_ptr_reply()

sergepetrenko pushed a commit to tarantool/c-ares that referenced this issue Jul 29, 2022
As of c-ares 1.17.2, a CNAME an in-addr.arpa delegation broke due
to not allowing '/'.  This needs to be allowed to not break valid
functionality.

Fixes Bug: c-ares#427
Reported By: Adrian (@leftshift)
Fix By: Brad House (@bradh352)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants