Developingby choice

Network Services — DNS & Web Proxy

Nikita Tarikin operates the MikroTik RouterOS network services — the Domain Name System (DNS) resolver and the HTTP web-proxy subsystem — both known to teaching depth across every leaf of the official curriculum, with DNS run at full depth as daily production ground and the web proxy, known just as deeply, deliberately retired. That split is a deployment decision, not a knowledge gap: encryption-by-default made the intercepting HTTP proxy obsolete, so what runs hard tracks how central each service is to a modern stack.

Every service is known to the same depth; what is run daily tracks what a current stack actually leans on — DNS at full depth, the web proxy set down by choice. The map below marks which is which.

5.0
Knowledge K̄: 3.7
Deployment Ē: 6
leaves mapped: 4
know ≠ run splits

Verified by MTCNA 100%MTCTCE 86%

The map

Every services leaf in the official MikroTik curriculum, placed by what is known against what is run in production. The knowledge axis tells one story here — every mark sits at the far right, because each service is studied to the same teaching depth. The deployment axis tells the other: DNS holds the mastery corner, run as deeply as it is known, while the web-proxy leaves fall a tier below it — held at the ceiling, run lower by choice.

Read left-to-right as knowledge, bottom-to-top as deployment. Every mark presses against the right-hand knowledge ceiling — there is no service here read shallowly. The pair in the top-right mastery corner is DNS, deployed to the very depth it is known and run daily. The drop-lines beneath them, with the figure that counts them, are the web-proxy leaves: held at the same ceiling, run a tier lower — the subsystem set down on purpose as the web moved to end-to-end encryption.

The topography

The full leaf-level ledger, grouped by topic — DNS and the web proxy. Each row carries its own two verdicts — what is known and what is deployed — and the field note that earned them, quoted verbatim from the assessment.

Leaf	Knowledge	Deployment	Field note
DNS		K̄ 5.0 · Ē 5.0 · 2 leaves
Basic DNS Config	5Teach	5Teach	allow-remote-requests + port-53-reachable-from-WAN = OPEN RESOLVER (DNS-amplification DDoS) -> firewall 53 to LAN; static DNS entries support regexp name matching returning a fixed IP. Security lens
Static DNS Entries	5Teach	5Teach	Knows regexp= for pattern matching AND match-subdomain=yes for the lower-CPU subdomain case (EXCEEDED framing). The wildcard-A-record pick was a misclick — RouterOS static DNS has no glob, only regexp. Teach (confirms v1).
Web Proxy		K̄ 5.0 · Ē 3.0 · 4 leaves · 4 splits
Basic Proxy Configstudied ahead	5Teach	3Confident	Transparent proxy can't filter HTTPS without a forged cert (MITM) breaking TLS trust. Knows it cold; deliberately RETIRED as obsolete (HTTPS-everywhere, privacy/security risk; caching was an expensive-HTTP-bandwidth-era win). HTTP-era experience.
Proxy Rule Listsstudied ahead	5Teach	3Confident	Proxy access-list = top-down, first-match (like firewall filter); default action = allow if nothing matches. Obsolete-by-choice.
Access / Direct-Access / Cache Listsstudied ahead	5Teach	3Confident	access-list allows/denies requests; direct-access-list decides which requests bypass a parent proxy and go direct. Knows cold; obsolete-by-choice.
Regex in Proxy Rulesstudied ahead	5Teach	3Confident	path=:".tracker." action=deny — regexp substring match in the access-list. Volunteered the obsolescence case: '2000s–2010s methodology, HTTPS-by-default makes http proxies privacy-violating + extinct; prefer src-nat/dst-nat bouncing' — informed-obsolescence trust signal.

The edges

The daylight here is not a knowledge gap — every services leaf is graded at the ceiling. It is a deployment decision. The web-proxy leaves are held cold and run a tier lower because the intercepting HTTP proxy has been deliberately retired: once the web moved to end-to-end encryption, a transparent proxy could no longer filter or cache a request without forging a certificate and breaking the trust chain, and what was once a bandwidth win became a privacy and security liability. DNS, by contrast, sits in the path of every connection and is run at full depth every day. What is deployed hard tracks what a current stack leans on — and where a once-standard service has been set down on purpose, the ledger records it in the original assessment language.

Knowledge ahead of deployment

Known deeper than it currently runs — named, not rounded over.

Basic Proxy Configknow 5 Teach→run 3 Confident
Transparent proxy can't filter HTTPS without a forged cert (MITM) breaking TLS trust. Knows it cold; deliberately RETIRED as obsolete (HTTPS-everywhere, privacy/security risk; caching was an expensive-HTTP-bandwidth-era win). HTTP-era experience.
Proxy Rule Listsknow 5 Teach→run 3 Confident
Proxy access-list = top-down, first-match (like firewall filter); default action = allow if nothing matches. Obsolete-by-choice.
Access / Direct-Access / Cache Listsknow 5 Teach→run 3 Confident
access-list allows/denies requests; direct-access-list decides which requests bypass a parent proxy and go direct. Knows cold; obsolete-by-choice.
Regex in Proxy Rulesknow 5 Teach→run 3 Confident
path=:".*tracker.*" action=deny — regexp substring match in the access-list. Volunteered the obsolescence case: '2000s–2010s methodology, HTTPS-by-default makes http proxies privacy-violating + extinct; prefer src-nat/dst-nat bouncing' — informed-obsolescence trust signal.

The warrant

Third-party verification of the services depth above — in support of the deployment record, never in place of it.

MTCNAVerified — 100%, Network Associate
MTCTCEVerified — 86%, Traffic Control Engineer

Services ride on the device and addressing layers beneath them. Where they connect:

The questions

Do you run DNS on RouterOS in production?

Yes — DNS is daily, deployed ground here, graded at teaching depth on both leaves with no daylight, and verified by MTCNA (MikroTik Certified Network Associate). The mechanics I run, publicly: a RouterOS router with the DNS feature enabled can serve as a resolver for any DNS client, and /ip dns set allow-remote-requests=yes is what turns the router into a cache for the rest of the LAN — it then answers TCP and UDP queries on port 53. The trap I always close is the one MikroTik names in its own documentation: leave that port reachable from the WAN and you have published an open resolver — the reflector half of a DNS-amplification attack — so a filter pinning port 53 to known internal hosts goes in at the same time the resolver does. For local names I lean on /ip dns static, where the list is ordered top-to-bottom, regular expressions are checked before plain records, and match-subdomain=yes covers a domain and its children without the per-query cost of a regular expression.

Can you run encrypted DNS — DNS over HTTPS — on RouterOS?

Yes; DoH (DNS over HTTPS) is part of the deployed DNS posture here, not a studied-ahead edge. The mechanism, publicly: RouterOS has supported DoH since version 6.47, set with /ip dns set use-doh-server=https://… verify-doh-cert=yes, which wraps queries in HTTPS to close the man-in-the-middle gap that plain port-53 DNS leaves open. Two details decide whether it actually works: verify-doh-cert=yes needs the provider’s CA certificate imported into the router’s certificate store, and the router needs at least one ordinary DNS server — or a static entry for the DoH hostname itself — to bootstrap-resolve that hostname before the encrypted channel exists. RouterOS supports a single DoH server, and while it is active it overrides the plain servers list; it is also not compatible with FWD-type static entries, which is the constraint I design around when a deployment needs conditional forwarding and encryption at once.

Do you deploy the RouterOS web proxy?

No — and that is a decision, not a gap. I hold the web-proxy subsystem at teaching depth — transparent and regular modes, the access-list, the cache and direct-access lists — but I deliberately retired it. The reason is structural, and public: the RouterOS transparent proxy handles HTTP only, redirected to the proxy by a destination-NAT rule on port 80; HTTPS cannot be transparently intercepted at all, because the TLS handshake encrypts the hostname and headers before the proxy ever sees them. The only way around that is to forge a certificate and man-in-the-middle your own users, which breaks the trust chain the entire web now depends on. Once traffic went encryption-by-default, the proxy’s caching win evaporated and what remained was a privacy and security liability. For the jobs an HTTP proxy used to do, the modern RouterOS answer is source- and destination-NAT steering plus DNS-level control — which is exactly where my deployment lives now.

If you know the web proxy cold, why does the map show it run lower than DNS?

Because deployment on this domain tracks how central each service is to a current stack, not how well it is understood — and both services are understood at the ceiling. DNS sits in the path of every connection, so it is run at full depth daily. The web proxy was central in the bandwidth-scarce era, when caching repeated HTTP objects genuinely saved a link; encryption-by-default ended that, so it is run a tier lower by choice. The access-list mechanics I still hold cold, publicly: a proxy access-list is processed top-to-bottom like a firewall rule chain, the first matching rule decides, and a request can be matched on source, destination, port, URL substring or request method. The part that bites people is the default — if a request matches no rule at all, the proxy allows it, which is the opposite of how a security boundary should fail. Knowing that precisely is part of why I steer this work to NAT and DNS controls instead.

Bring the DNS problem.

If it is a RouterOS DNS resolver — static entries, regexp matching, encrypted DoH, or shutting an open resolver — that is ground I run every day. If the job calls for an intercepting HTTP proxy, I will tell you why I retired it and point you at the modern equivalent before the work starts, not after.

Start the conversation