The two biggest flags for bittorrent are the scrape and announce commands sent to the trackers. For a long while, the Bittorrent rule on the wiki that everyone used had a typo in it that disabled it’s ability to detect scrapes and announces. This lead to someone (TKITFrank?) making the bittorrent_announce rule to capture them.
The problem comes from the bittorrent_announce rule being rather vague, and able to pick up false positives. The corrected part of the rule that grabs announces also looks for the info_hash parameter, which is a dead giveaway for bittorrent:
get /announce\?info_hash=
Compare this with the filter rule in bittorrent_announce:
add name=BITTORRENT_ANNOUNCE regexp=^get.+announce.
This rule basically looks for anything with the word “get” and “announce”. On Yahoo’s homepage, there is an object called “Announcebar” at top. When you load the page, at some point a request is generated for “get /announcebar/announcebar_1.0.22.css”, which will trip the bittorrent_announce rule, but won’t be troubled by the proper rule due to the lack of the info_hash parameter.
If you want to look more into the problem, I detailed the issue with the bittorrent filter here: http://forum.mikrotik.com/t/radius-server-not-working-in-2-8-11/127/1
First, remember that DNS can use TCP in addition to UDP. Any response over 512 bytes requires TCP to be used. With DNS Sec, DNS over TCP is becoming more common.
Rather than just drop the DNS traffic, you can just as easy redirect it to the internal DNS server:
/ip firewall nat
add action=redirect chain=dstnat comment="Capture DNS" disabled=no dst-port=53 protocol=udp to-ports=53
add action=redirect chain=dstnat comment="Capture DNS" disabled=no dst-port=53 protocol=tcp to-ports=53