Filter Content in Firewall with DOT (.) in string

Hello

I want to match DNS content with the content filter in advanced firewall rule tab.

But when I use with some dot, like,

example.com

it stops to match the string.
Sometimes it matches, but much less than normal scenario.

If I tried to use regex, like

example\.com

things get even worse.

Do someone know how to use dot in content filtering?

It doesn’t work because the dot symbol is not actually present in the DNS query - the FQDNs are encoded in a rather complicated way, see the RFC for DNS for details. There are multiple topics regarding this here on the forum, e.g, this post gives you a hint.

For non-dns traffic you could try example\.com

When I try to use the example from the thread you linked, its not working as well.
Maybe there is difference between using L7 Filters and Content Filter

Content filter parameter can be only a string, and on dns packet the dot do “not exist”.
Understand this?


Layer7 filter can be a POSIX RegEx like (I do not write that filter!!!..)

^.?.?.?.?[\x01\x02].?.?.?.?.?.?[\x01-?][a-z0-9][\x01-?a-z]*[\x02-\x06][a-z][a-z][a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[a-z]?[\x01-\x10\x1C][\x01-\x04\xFF]

TLS host matcher can be a POSIX RegEx like

(^|\.)youtube\.com$

So what that means? Should I use space instead of dot ?

As @sindy already answer you on post #2 (!)
Inside the dns packet the dot between fields do not exist (like the dot in www.youtube.com)
Exist only if the field is exactly 46 characters long like:

³www .this-string-have-a-lenght-fourtysix-characters ³com

And the space exist only if a field with exactly 32 characters exist, like:

³www (space)string-with-lenght-of-thirty-two ³com

i have used the ³ sign because the character wit hex code 03 is not representable.
HEX 3 = ETX (Ctrl-C) END OF TEXT

No. You have to use a byte whose value is the length of the subsequent part of the domain name, example:

\08somename\03com

I don’t remember the encoding of byte values exactly, I just remember it differs between regexp (used in layer7 rules) and contents. Check the manual.

You have already wrote how are encoded, but on winbox you can not insert special characters like the character “\08”, but can be added on CLI like:

add action=log chain=prerouting content="\03www\06google\03com"

But is it “\x08” or only “\08” ?

(duplicate)

Which manual do you reffer?

Read my example on my previous post #9
http://forum.mikrotik.com/t/filter-content-in-firewall-with-dot-in-string/151545/1

OOWWW I see, when I tried to insert using terminal, the code gets different when viewing in winbox.
Got it.

You understand why now :wink:

but > on winbox you can not insert special characters > like the character “\08”, > but can be added on CLI

On all regex field and on terminal, RouterOS support only \1F hexadecimal characters rapresentation,
with hexadecimal letters uppercase and without the “x” (like wrong \x1F for RouterOS)

But you can use 0x for hexadecimal numbers on scripts, like:

:put (1 + 0x1F)
32

How can I match content with hex DNS flags ?
like 0x8105 which means Refused ?

only contents="\8105" ?

please explain, i do not have understand what you want do.

0x8105 are two bytes, 0x81 and 0x05
the conversion is “\81\05”, but if on the field on the packet is on reverse order is “\05\81”

Trying to achieve the objective to drop responses with DNS Refused, as RFC1035 inform us.

The code is suposed to be 5
https://www.rfc-editor.org/rfc/rfc1035#section-4.1.1 -> see page 27

I see this 0x81 in some anti DDoS systems, like NSFocus. I guess is because (see page 26,27):

8 = RA
Recursion Available - this be is set or cleared in a response, and denotes whether recursive query support is available in the name server.

1 = QR
A one bit field that specifies whether this message is a query (0), or a response (1).

But I don't know if I am correct.

RA is not 8, is th 8th bit set to 1
IS too late to explain better, but the 2 BYTEs are
10000000 10000101 = 80 85

I'm trying to understand how to block this messages:
https://routley.io/posts/hand-writing-dns-messages/

This blog kinda helps.