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

ENH: cymru expert: prevent extra lookups, handle invalid asnames #2352

Merged
merged 3 commits into from
May 16, 2023

Conversation

monoidic
Copy link
Contributor

@monoidic monoidic commented Apr 19, 2023

This PR fixes #2132 by ignoring AS names with invalid characters, as suggested by Sebastian.
It also ensures that Cymru DNS queries that return NXDOMAIN do not cause any extraneous queries due to search domains.

(TODO: changelog, add unit test with invalid characters)

@sebix sebix marked this pull request as draft April 19, 2023 21:19
@sebix sebix added bug Indicates an unexpected problem or unintended behavior component: bots labels Apr 19, 2023
@sebix
Copy link
Member

sebix commented Apr 19, 2023

(TODO: changelog, add unit test with invalid characters)

Yes, a unit test for one of these special cases would be very good. For example the AS266522, which you mentioned in the issue

The fix looks good on first glance.

@monoidic
Copy link
Contributor Author

monoidic commented Apr 20, 2023

Right. Well. Having the IP in the test event seemed to mess with things.

@monoidic monoidic marked this pull request as ready for review April 20, 2023 08:21
Comment on lines 20 to 21
IP_QUERY = "%s.origin%s.asn.cymru.com."
ASN_QUERY = "AS%s.asn.cymru.com."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's possible, it would be nice to provide a test for this change as well

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests cover IP and ASN lookups.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It technically doesn't cover the search domain part.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I meant :)

@@ -168,6 +168,8 @@ def __asn_query_parse(text):
if items[4]:
# unicode characters need to be decoded explicitly
# with the help of https://stackoverflow.com/questions/60890590/
result['as_name'] = items[4].encode('latin1').decode('utf8')
as_name = items[4].encode('latin1', errors='ignore').decode('utf8')
if as_name:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this the "Avoid extraneous search domain-based queries on NXDOMAIN result"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the added periods in IP_QUERY and ASN_QUERY, actually.
Example: if you have a search domain of "lan" and resolving homeserver fails with NXDOMAIN, then the search domain will cause homeserver.lan. to be queried.
However, if, for instance, 1.2.3.4.origin4.cymru.com returns NXDOMAIN, then 1.2.3.4.origin4.cymru.com.lan. would be queried.
But, the added period at the end signifies that this is a fully qualified domain name and such queries should not be made.

@monoidic
Copy link
Contributor Author

monoidic commented Apr 24, 2023

The test explicitly sets the search domain to cert.ee., which causes the test to fail if attempts are made to parse the TXT response because the responses for all subdomains of cert.ee. return an SPF record in response to TXT queries.

It is not a perfect solution (it relies on the cert.ee. domain, and the result for the IP in the test being NXDOMAIN, and the parser raising an exception on TXT records with invalid formatting instead of gracefully handling it somehow).

However, I'm wondering, is there any legitimate use case for intelmq.lib.utils.dns.resolve_dns to force the use of search domains in the first place? What about updating the minimum dnspython version to 2.x and removing search=True altogether?

@sebix
Copy link
Member

sebix commented May 3, 2023

However, I'm wondering, is there any legitimate use case for intelmq.lib.utils.dns.resolve_dns to force the use of search domains in the first place? What about updating the minimum dnspython version to 2.x and removing search=True altogether?

yes, I think we can safely require dnspython >= 2.0 now.

I don't have any reason at hand why search is on. If the tests succeed with search disabled, let's go for it :)

@sebix
Copy link
Member

sebix commented May 15, 2023

@monoidic Is this PR ready to merge or do you want to change the DNS-related parts?

@monoidic
Copy link
Contributor Author

I'd been busy with other projects and forgout about this.
The latest commit should have everything necessary to deprecate dnspython <2.0.0 and remove two tests which are now outdated.
If the changes are acceptable, then I will add changelog entries as well.

@sebix sebix requested a review from kamil-certat May 15, 2023 15:39
Copy link
Member

@sebix sebix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the changes are acceptable, then I will add changelog entries as well.

Yes, please document the changed minimum required version of dnspython, this has impact on the supported OSs (dropping out Ubuntu 20.04, which need to be removed from the docs, from intelmq-vagrant and at the next release from the packages).

Comment on lines -934 to +933
if dns.version.MAJOR < 2:
return dns.resolver.query(*args, **kwargs)
return dns.resolver.resolve(*args, **kwargs, search=True)
return dns.resolver.resolve(*args, **kwargs)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With that change the function is obsolete now. But that's something for a major version as it is a change in the interface.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you leave a ticket to remove it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added to #1444

Copy link
Contributor

@kamil-certat kamil-certat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. What I'm not happy about is that we rely on the real answers in tests instead of some mocking solution (and DNS is relatively unstable), but it's a general problem, nothing related to the change :)

Comment on lines -934 to +933
if dns.version.MAJOR < 2:
return dns.resolver.query(*args, **kwargs)
return dns.resolver.resolve(*args, **kwargs, search=True)
return dns.resolver.resolve(*args, **kwargs)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you leave a ticket to remove it?

@sebix sebix merged commit 512200c into certtools:develop May 16, 2023
24 checks passed
@sebix sebix self-assigned this May 16, 2023
wagner-intevation pushed a commit to wagner-intevation/intelmq that referenced this pull request Sep 5, 2023
Support for Debian 10 Buster was dropped in PR#2352
certtools#2352
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates an unexpected problem or unintended behavior component: bots
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cymru whois expert: handle strange ASN symbols better
3 participants