Because, I have to add same rule to filter table and mangle table
like this
For filter table
;;; Block Fake DNS Record 49.50.69.28
chain=input action=drop layer7-protocol=49.50.69.28 protocol=udp src-address-list=My DNS in-interface=Telecom src-port=53
packet-size=60-180

This above rule can be filter for ros itself.

For mangle
;; Block Fake DNS Record 49.50.69.28
chain=prerouting action=change-ttl new-ttl=set:0 passthrough=yes layer7-protocol=49.50.69.28 protocol=udp
src-address-list=My DNS in-interface=Telecom src-port=53 packet-size=60-180

Even if TTL set to 0 because no drop action in mangle table so ros is able to receive the fake dns record, I have to set similar rule in filter table to filter the same fake dns record.

If raw table can be support L7 function that will one filter rule can get same result.

You could try the "content" field in RAW. I am now using it since a few hours after reading your posting and it works well to detect a IP in a http stream.

I tried in raw content,but it didnot worked.

see below

16 ;;; test 180.168.41.175
chain=prerouting action=drop in-interface=Telecom src-port=53 content=\xB4\xA8\)\xAF log=no log-prefix="" protocol=udp
src-address=202.96.209.5

17 ;;; test 180.168.41.175
chain=prerouting action=drop in-interface=Telecom src-port=53 content=180.168.41.175 log=no log-prefix="" protocol=udp
src-address=202.96.209.5



[root@MikroTik] > put [resolve www.telecomisapig.com server=202.96.209.5]
180.168.41.175

Aren't you using dns cache? Maybe you should flush it before...

Aren't you using dns cache? Maybe you should flush it before...

Already flushed

On RAW and content I had some strange behaviour that have to look into. I had to invert (!) the content field to have the content field to been seen by Mikrotik if Fasttracking is enabled. If you disable for testing Fasttracking in the Rules tab and test again does it then works?

It didnot worked. My environment did not have fast track rules. I think Fast track will not come into effect in RAW table, Because RAW table handles the packet highest priority than filter nat mangle table.

It didnot worked. My environment did not have fast track rules. I think Fast track will not come into effect in RAW table, Because RAW table handles the packet highest priority than filter nat mangle table.

I learned the hard way that RAW will get the packet first, but what if the the package you want to catch is further up in the stream. Fasttrack will take over because the connection is established. I have changed the fasttrack so that it only will help traffic that I generate internal. From external is exempted from Fasttrack and will have to go through the rules.

OK
I added fast track in filter table and mangle table added it automaticlly,
test content 180.168.41.175 and HEX(\xB4\xA8\)\xAF) in RAW table still not worked.

OK
I added fast track in filter table and mangle table added it automaticlly,
test content 180.168.41.175 and HEX(\xB4\xA8\)\xAF) in RAW table still not worked.

Hahaha fasttrack is making it more difficult to detect content so not activating makes testing easier. Then you can switch it on and tune your settings and have advantage of the acceleration offered by fasttrack.

You are looking for IP 180.168.41.175 and regex is only applicable in L7. I have not read about any limitations (lentght/number of packages) of the content field like there is for L7.

Did you have a look with package sniffer or WireShark if the IP is writen in that way because some time you see them being reversed (175.41.168.180).

I just don't know enough about this part and lets hope someone with more knowledge will pay attention to your question.

test content 180.168.41.175 and HEX(\xB4\xA8\)\xAF) in RAW table still not worked.

and it works in 'filter', right?

about L7: as far as I remember, L7 rules require Connection Tracking, so they are not possible in RAW table

master wrote:
Hahaha fasttrack is making it more difficult to detect content so not activating makes testing easier. Then you can switch it on and tune your settings and have advantage of the acceleration offered by fasttrack.

You are looking for IP 180.168.41.175 and regex is only applicable in L7. I have not read about any limitations (lentght/number of packages) of the content field like there is for L7.

Did you have a look with package sniffer or WireShark if the IP is writen in that way because some time you see them being reversed (175.41.168.180).

I just don't know enough about this part and lets hope someone with more knowledge will pay attention to your question.

I disabled fast track rules when I finished tested

This IP was pushed by the DNS server when it has non dns record.I used Wireshark and never saw the reversed address of 180.168.41.175 before.

Thank you for your zealous help and hope someone can help me also.

Chupaka Wrote:

and it works in 'filter', right?

about L7: as far as I remember, L7 rules require Connection Tracking, so they are not possible in RAW table

It worked in Filter table when ROS as DNS server.

I forgot whether L7 needs connection tracking. I tested the rule in Linux, it worked. See below.

iptables -t raw -A PREROUTING -p udp --src 202.96.209.5 --sport 53 -m string --algo bm --hex-string "|B4A829AF|" --from 60 --to 180 -j DROP

ROS as DNS server their rules worked in Filter table, when built a slave DNS server via ROS to get the DNS record, they did not work except ROS had similar rules in Mangle table,

I want one new rule that can take effect to replace the old rules in both Filter and Mangle table. So I propose the developer team to solve the problem.

if DNS is the router itself you use input/output chains. if DNS is on dedicated machine, you use 'forward' chain. can't it be the reason?

Yes If I only have one DNS server whatever ROS itself or dedicated DNS server, you are right.

For my environment, I have to build 2 rules for ROS and dedicated DNS server.

I just want that the data packet enters into the Filter/Nat table before, ROS can first deal with the data, Because I can use one rule for both DNS servers.

One rule means less system overhead and shorter operation time, right？

One rule means less system overhead and shorter operation time, right？

wrong if one rule is in 'output' chain and one is in 'forward', each packet goes to only one of them, not both. so each packet is being processed by only one rule. no overhead

I understand what you mean.
add one rule in filter table output chain add another one in filter table forward chain, right?
No additional overhead bcoz each packet goes through different chain.
But this condition just for a spot of IPs only.
If I want to block hundred IPs they are too many rules in output and forward chain.

If I want to block hundred IPs they are too many rules in output and forward chain.

can't you just block traffic from/to those IPs? why do you need timeouts in DNS?

DNS cache pollution by GFW, If I use public DNS server like 8.8.8.8 that will lose CDN effective, So I have to block all fake IPs from local ISP DNS servers.

you mean, Great Firewall of China?..

anyway, if you want to block many addresses, probably you'd better install some DNS Relay and block on it, not in firewall

Yes Great Fire Wall in China.
Now I am using ChinaDNS+Dnsmasq+Openwrt, that makes me has a clean environment, but my Openwrt load is high. ROS load is very light, so I want to change filter rules into ROS.

Try this: You have to enter value of content using CLI, it won't work using WinBox. It it's correct, the value will have blue color, and it will show as garbage when viewed in WinBox. Bytes 00 04 at the beginning is address length from packet, having it there should help with false positives.

It worked
Winbox deos not support HEX?

It seems that Winbox is only supporting a string of characters/numbers.

Great that your problem is solved now and here in the Netherlands, which seems to be free country however the laws are going to be do that can't trust you own computer any more and have the take same action like in China to have reliable results.

Oh Netherland has established the system similar to GFW also? that is unfortunate news.
It looks like governments the world are tightening the freedom of information flow.

It looks like nobody at MikroTik thought about entering other than 7-bit ascii printable characters in this field using WinBox. It's there, but good luck trying to type that: <OT>About GFW, in Europe we don't do that. We think we're better than you (not really, that's just sarcasm), and we would never allow anything like GFW in our countries, because it's censorship, it's against freedom and it's completely wrong. Although we might do something like that if it's for good cause. I don't know what exactly they have in Netherland, but in Czech Republic we'll soon have mandatory blocking of illegal online gambling. Because you know, gambling is bad, creates addictions, ruins lives and so on. But just when it's illegal, the allowed legal gambling which pays taxes can't do that, of course. So we're all eternally gratefull to our enlightened government for trying to save us. It will surely work great with easily available VPNs, proxies and encryption all around. But again, it's important to stress out that things like this are nothing like GFW. GFW is bad, our blocking is good. Yeah, right...</OT>

Yes, however the comment has to make because in winbox the Content field is not readable.

Yes, your government is right gambling will destroy whole family and life. GFW blocking not just online gambling also including pornographic and all negative views on politics.
In China the government spends more than 86.2 billion US dollars for maintenance of stability per year.