Mikrotik caching DNS and 0x20 bit encoding

RouterOS General
1

Hi all,

There is draft exists for some time for new DNS protection mechanism called “0x20 bit encoding”. In brief - DNS requester combines uppercase and lowercase letters in DNS query and checks if there is the same combination in DNS answer. If not - DNS answer is possible spoofing attempt.

Mikrotik built-in caching DNS server uses only lowercase letters in reply regardless of case combination in request (as I see in sniffer). It is potential problem - for example I found that Mail.Ru portal uses DNS servers with this mechanism enabled, which caused email delivery problems between mail.ru and our domains for several days.

I think that Mikrotik caching DNS server should keep uppercase-lowercase combination of incoming DNS query in answer.

Best regards,
Cyril

2

Domain name lookups according to RFC4343 are case insensitive, and in DNS replies the capitalization MAY be kept but must be ignored by the client.
https://tools.ietf.org/html/rfc4343
Since this affects reverse DNS and CNAMES only (address resolution responses being in dotted quad format), I would assume that the issue is on the client side: the mail senders don’t use the proper capitalization on the domain in their mail messages, so sending will fail if the other end uses a case sensitive mail infrastructure, like courier.
On the other hand, the system should deal per RFC4343 with RDNS matching in a case insensitive manner, and this is the sole problem of the recipient’s mail system (this being your system if incoming mail from mail.ru is dropped).

Altering the DNS system will not solve this problem. The hello host name and the to: fields will still be wrong and not accepted by the recipient system. Changing the RFCs and all DNS implementations just to fit the requirements of a mail provider choosing to ignore them (this being you or mail.ru) doesn’t seem a proper approach.

3

I know - as I know that 0x20 bit encoding is just draft. But the problem is here, some DNS servers serving large enterprises and Internet companies uses it.


And A.


Not quite. First, mail exchange in my case is broken to any side - I cannot send mail TO domain B (behind Mikrotik) from domain A (which uses 0x20 bit encoding), and I cannot get mail FROM domain B in domain A.
Once again - I have checked with packet sniffer and see that the problem exists only when Mikrotik caching DNS server serves DNS queries from domain A and replies with lowercase domain names.


None of the SMTP exchange substrings affects the problem. Read the draft, please. Domain A DNS servers MODIFY host names from SMTP exchange to combination of lowercase and uppercase symbols before sending query and checks if hostnames in response are the same. Like this (approximately):

\

  • SMTP server gets mail from client to address@domain.com;
  • SMTP server asks DNS server for MX in domain.com;
  • DNS server forms and sends query for MX in DomAIn.coM (yeah, we like progress and new technologies - like 0x20 bit encoding!);
  • DNS server gets response with MX for domain.com;
  • domain.com is not DomAIn.coM! damned phishing scum!!! to SMTP - get off, there is no MX for domain.com.


    Best regards,
    Cyril.
4

Yes, right. I actually forgot about MX checks.
But then again, shouldn’t the mail system be case insensitive on the MX check?
Of course, if the DNS returns the MX as written in the zone, this would be great.

5

It can be case sensitive or case insensitive - doesn’t matter. It is DNS server where name resolution fails - if response does not contains the same case combination in host name as DNS server generated and then sent in query, DNS server drops the response. Client (it could be browser, POP or IMAP client, SIP software or anything else relying on name resolution) will get “Host not found”. Nothing to demonstrate case sensitivity on client’s side.

Best regards,
Cyril

6

Now i got really curious about this :slight_smile:
So what you are saying is that MT’s DNS is actually case sensitive when it should not?

Let’s get an example. Let’s say we have:
Test.com A 1.2.3.4
Mail.Test.com A 1.2.3.4
1.2.3.4 IN PTR Mail.Test.com
Test.com MX 10 Mail.Test.com

1 - a DNS request for Test.com or test.com both should return 1.2.3.4, because the host name is case insensitive
2 - a MX request for Test.com or test.com should return Mail.Test.com or mail.test.com, depending on the DNS server implementation
3 - a reverse DNS would return Mail.Test.com or mail.test.com, depending on the DNS server implementation

But it seems the real world is even more crazy.

Here some tests:

Mikrotik NS:
root@server:~# nslookup -query=mx Mail.Ru 192.168.70.101
Server: 192.168.70.101
Address: 192.168.70.101#53

Non-authoritative answer:
mail.ru mail exchanger = 10 mxs.mail.ru.

root@server:~# nslookup -query=mx mail.ru 192.168.70.101
Server: 192.168.70.101
Address: 192.168.70.101#53

Non-authoritative answer:
mail.ru mail exchanger = 10 mxs.mail.ru.


Google NS:
root@server:~# nslookup -query=mx mail.ru 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
mail.ru mail exchanger = 10 mxs.mail.ru.

root@server:~# nslookup -query=mx Mail.ru 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Mail.ru mail exchanger = 10 mxs.Mail.ru.

root@server:~# nslookup -query=mx Mail.Ru 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
Mail.Ru mail exchanger = 10 mxs.Mail.Ru.

And the nicest one:

root@server:~# nslookup -query=mx MaIl.rU 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
MaIl.rU mail exchanger = 10 mxs.MaIl.rU.


It seems that MT converts requests or responses to lower case, while Google keeps the same case as in the request (clearly not as the ones defined in the zone files, because of the last test). Now the good question is, who is not following RFCs. The one that responded all in lower case, or the one that alters the things written in the zone file to fit the queries and substitutes the zone’s .origin by the query itself?

7

Oh… Look here:

  1. there is RFC for DNS and it neither require case sensitivity nor prohibit this;
  2. there is draft for mechanism to increase security of DNS resolution named 0x20 bit encoding, which determines that DNS server have to mix uppercase and lowercase symbols in random order for hostnames in query to other DNS servers (and do some more thing - but it is not the point of interest now) and then check if response contains hostname with the same order of uppercase and lowercase symbols - if no, response is possible phishing attempt;
  3. there are some DNS servers on market which support 0x20 bit encoding and fully compliant to RFC at the same time;
  4. there are some idiots among IT community (and many of them are hired by large companies) who rely on draft and ignore the problems they face when DNS servers on other side are fully compliant to RFC but do not return responses with same mix of different case symbols, switching to lowercase hostnames in responses.

The real problem are those idiots. They turn on 0x20 bit encoding in strict mode - and drop all responses that do not conform with this draft.

DNS servers You have tested are both fully RFC compliant. Just one of them uses different case symbols combinations in query (which is not prohibited by RFC) - but does not drop responses that is not 0x20 bit-compliant.

In perfect world we can ignore such kind of idiots. In real world we should count their existence - and I suppose the most effective way to do it is to make Mikrotik routers’ caching DNS server 0x20 bit encoding compliant.

Best regards,
Cyril.

8

Tnx. Cyril for the explanation. Now I got it, and have to support your suggestion.
But I think that has also to be implemented for ROS DNS lookup functions, not only for the cache.

+1

9

There is always some risk in inventing a new trick, testing with a few mainstream products if it works, and then enabling the trick in a production platform.
It requires careful monitoring and analysis of the monitoring results, and apparently mail.ru are not doing that.
They should see indications that some domains have stopped working and investigate what is happening and if it is an attack or spoofer or they just encountered an implementation that does not work with their new idea.

So -1 for mail.ru for not doing that!
In the meantime, it would be nice if something was done about it by MikroTik, but this topic was already discussed elsewhere so I think it is on their list of things to do.