if you setup doh for dns , and add dns ip s like 8.8.8.8 , 1.1.1.1
mikrotik just use doh.
what problem?
i want to get host ip for domain, example: test1.com
but cloudflare doh can’t lookup domain ip.
now, RouterOS must go to check other dns servers (like 8.8.8.8, user add)
but don’t do this!
For Fix:
you can’t do anything!
Note:
if user want to use DOH => add use only doh checkbox to doh configuration.
RouterOS 6.47 Latest updated
RB911G-5HPnD
Mikrotik Sextant g
DoH is a one horse only with Mikrotik. So DoH or normal DNS.
My advise is to use DoH in the webbrowser or in countries or with ISP providers that repressive. This in non-repressive countries/ISP you are only feeding the big firms with our private data.
I know. but i need this for my doing work! and dns server!
this is not only problem . when Router can’t resolve ip from server 1 dont get to try with server 2.
just only when server 1 isnt work go to server 2,.
this is problem too.
Mikrotik never tried to resolve DNS from multiple servers. If first one fail, mikrotik considers it as a valid response.
If you want to resolve specific domains through different server, you can use FWD entry. E.G.:
/ip dns static add forward-to=10.0.0.1 regexp=".*\.example\.local" type=FWD
This will forward all your *.example.local queries to your local domain server with IP 10.0.0.1
That is a theory but unfortunately this does not work with DOH right now. Mikrotik staff is aware (reported in [SUP-20565], resolved in v6.48beta12*) and hopefully they will soon release fix in stable channel.
For now, you have to do it with dst-nat (same way as we did it in the past):
this will work with DOH because it completely skips mikrotik’s DNS system (DST-NAT occurs before routing decision and the packet goes to “forward” instead of “input”).
ouch, sorry, I didn’t actually test it. Instead I relied on changelog which was quite clear
*) dns - do not use DoH for local queries when a server is specified;
So, you are right - still does not work…
I am more and more thinking that this FWD is nice but actually not practical because with DST-NAT solution, I can even specify source (e.g. guest network won’t be able to resolve internal domain names from corporate domain) so it gives me more precise control over it
Don’t even suggest that there’s anything good about L7 hack, the whole thing is completely wrong. Better than nothing, but that’s it. Yes, being able to use it selectively is good and you currently can’t to it otherwise, so once again it may be the best in some cases. But it doesn’t make it great, because it still has all limitations as before (no tcp, no ipv6, no cache, did I forget something?).
Easiest way how to solve different FWDs for different clients would be ability to have independent resolver instances listening on different addresses. Other way would be to introduce some conditions for static records. But it doesn’t seem likely that MikroTik is going to do any of that.
Gosh, I couldn’t agree more. In no way I meant to say that L7 NAT hack is ideal. I actually hate it because it does not apply to RouterOS itself (Prerouting is not in Output chain)
But as you acknowledged, it is better than nothing, if you can’t have dedicated DNS appliance. I guess we are really pushing “routers” to do more than it should…
vecernik87, sorry my english
in my case, mikrotik is 10.0.0.2 and dnsdomain is 10.0.0.1
i try your solution, but my client dns give this:
;; reply from unexpected source: 10.0.0.1#53, expected 10.0.0.2#53
;; reply from unexpected source: 10.0.0.1#53, expected 10.0.0.2#53
;; reply from unexpected source: 10.0.0.1#53, expected 10.0.0.2#53
;; connection timed out; no servers could be reached
Better than nothing, but that’s it. Yes, being able to use it selectively is good and you currently can’t to it otherwise, so once again it may be the best in some cases. But it doesn’t make it great, because it still has all limitations as before (no tcp, no ipv6, no cache, did I forget something?).