layer7 match failed, regexp too complex

RouterOS General
1

Hi,

I implemented a L7 filter to drop all DNS AAAA-queries (since I dont use IPv6 and they are about 1/4 of all DNS traffic).
The Regex is:

^.?.?.?.?.?.?.?.?.?.?.?.?([\x01-\?][a-z0-9\-_]+)+\.?\x1c\.?\x01

It seems this is too complex for ROS, the log says in blue:

layer7 match failed, regexp too complex (^.?.?.?.?.?.?.?.?.?.?.?.?([-?][a-z0-9-_]+)+.?.?)

Is there a way to simplifie this for ROS by maintaining the same functionality to catch all AAAA-Queries?

2

I guess a good first question to ask here is what the beginning pattern of

.?.?.?.?.?.?.?.?.?.?.?.?

is actually supposed to match.

To me, this seems redundant, since you are asking the REGEX engine to essentially match up to any 12 non-whitespace characters, but in a really complex way. I would try replacing this with:

^.{,12}?([\x01-\?][a-z0-9\-_]+)+\.?\x1c\.?\x01

Hope that helps! The rest of that REGEX seems to be compatible with POSIX ERE regular expressions, so the new pattern should work.

3

You can try to match only AAAA type DNS query, first 2 bytes (00 1c) of last 4.

^.*\x00\x1c..$
4

L7 strips zero bytes, so you can’t work with them at all. You can take 1c from type and 01 from class and look for them at the end:

/ip firewall layer7-protocol
add name=dns-aaaa regexp="\\x1c\\x01\$"
5

Not \x1C[\x01-\x04\xFF]$ ??? (ande the C must be not on uppercase?)

/ip firewall layer7-protocol
add name=dns-aaaa regexp="\\x1C[\\x01-\\x04\\xFF]\$"
6

Feel free to enlighten me, but DNS query packet ends with two bytes for type followed by two bytes for class. In type there’s 001C, 00 gets dropped, so we’re looking for 1C (lowercase \x1c is fine). Class could in theory be 0x0000-0xFFFF, but does anything we might care about use anything else than 0001?

7

Since some time has passed since I made that rule,
I had noted, at the time, that the possible values with which a valid DNS packet was concluded were from 0x01 to 0x04 and 0xFF.
But I don’t remember why now, I should go back to reading the RFC again. But to be safe, why not add them?

In fact, mine didn’t want to be a correction, but a question…

8

Ah, understand:
3.2.4. CLASS values
IN 1 the Internet
CS 2 the CSNET class (Obsolete - used only for examples insome obsolete RFCs)
CH 3 the CHAOS class
HS 4 Hesiod [Dyer 87]

3.2.5. QCLASS values

  •           254 [rfc2136]

  •           255 any class
9

I admit that I wasn’t sure, but it seems that except IN it’s all long time dead (only bind nameserver supposedly misuses CH to show its version, but I wouldn’t be sure about that either, because lately showing versions tends to be avoided).

10

In most reasonable devices, when the device itself has no IPv6 address, it does not attempt AAAA lookups either.
So it is a good idea to investigate what is happening there.

11

In my case this is happening when I run any wine application on Mac, tries to resolve local hostname with A and AAAA type when my network interface has Automatic configuration for IPv6 (and I don’t have IPv6 DHCP set on my router).
Maybe there are some other cases, I did not investigate this thoroughly because I don’t have a lot of these queries, approx. 3% daily which I see on Pi-hole donut chart.
In OP case 1/4 is a lot, this for sure needs to be investigated.