And terrible Russian firewall will burst

After the ValdikSS article about blocking sites on rotten domains, the ILK was not bothered by the thought of what would happen if the registry starts resolving to a very large number of IPv4 addresses. It seems to me a dubious undertaking of full-fledged "teachings" because they may accidentally turn into a deliberate violation of the runet's connectivity . Therefore, I limited myself to finding answers to two questions:

• Do providers automatically add IPv4 addresses from DNS to routing tables?
• Do large DNS responses that contain thousands of records correctly handle such RIB-supplemented systems?

I heated and registered several free domains from the list , raised the DNS server and set the traffic to be written in pcap ...

The domains for registration were selected as follows: two domains present in the upload with https-links, two domains with http links and two "bare" domains with no links. This is done to test the hypothesis of equality of all domains before the filter. The IPv4 addresses pointed to by these domains were chosen from the existing ones in the registry in order not to increase the load on the filters. The addresses that are not in the registry are currently allocated to my virtual machines, so there are no DoS attacks in this experiment.

You can go through the open lists of Looking Glass of different providers and see which of the major Russian providers have routes with a mask / 32 to their addresses from the registry, because these providers have the risk of being hit by a routing table overflow attack. There are not so few of such providers: Equant aka GIN aka Orange Business Services , Beeline , Rostelecom , Transtelecom , Obit and, what is a little funny, the Federal University Computer Network of Russia (joke about academic freedom and independence of universities) .

Let's check that the IP address that we plan to add "under the block" is not present in the routing tables on the same LG: 1 , 2 , 3 , 4 , 5 , 6 . If someone reproduces this experiment extremely purely, then it is also worth checking all the IPv4 and IP addresses that you plan to add to the table. I assume that the situation with them is similar.

On June 14 at 15:00 Moscow time, I added the addresses of some of my servers to the DNS zone files and began to observe what is happening in the pcap files while the resolvers updated the records.

Diversity

A total of 16 hours in the logs were requests for resolvers from one and a half thousand autonomous systems. In them, there is a fairly large variety of behaviors in terms of resolvable domains.

From the network with a abuse-contact on netup.ru , only those domains that are listed with the URL are resolved, while the domain with 2048 entries receives requests about 5 times more. AS FGUP Telecommunications with the same contact regularly goes to the DNS for all "small" domains every 8 minutes, but for some reason does not send a single request to the "large" domains, exactly like Izhevsk RadioLink . Tele2 resolves https and dumb, but doesn’t resolve http, presumably all http is wrapped in proxy. Zheleznogorsk Signal and Ekaterinburg Miralogic on the contrary - only http. SPNet from Sergiyev Posad - URLs do not resolve at all, only "bare" domains. Moscow citytelecom - on the contrary, only https and, as FGUP Telecommunications, does not even try to cut the "big" domains, which suggests the existence of an alternative way of distributing blacklists with pre-resolved addresses.

| HTTPS | HTTP | Domain-only asn | tiny | 2k/udp | 2k/tcp | tiny | 2k/udp | 2k/tcp | tiny | 2k/udp | 2k/tcp ------+------+--------+--------+------+--------+--------+------+--------+------- 50317 | 903 | 1416 | 1030 | 285 | 1295 | 1012 | 0 | 0 | 0 57835 | 207 | 0 | 0 | 200 | 0 | 0 | 200 | 0 | 0 38959 | 29 | 0 | 0 | 56 | 0 | 0 | 39 | 0 | 0 39475 | 155 | 217 | 217 | 0 | 0 | 0 | 151 | 209 | 209 42514 | 0 | 0 | 0 | 120 | 136 | 13 | 0 | 0 | 0 12668 | 0 | 0 | 0 | 95 | 103 | 18 | 0 | 0 | 0 43826 | 0 | 0 | 0 | 0 | 0 | 0 | 13 | 33 | 12 56705 | 415 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 

The full statistics of the number of requests in the first 16 hours can be seen in the gist , I note that not all ASNs belong to Russian providers.

EDNS & TFO

In pcap, almost no requests were found with the EDNS Client Subnet option, such requests are less than 1%. This is not very surprising, because google (almost the only “provider” of such requests) only discloses client addresses to those DNS servers that explicitly announce support for this option , but my DNS server did not. The indicated small percentage of requests is, I suppose, those attempts to automatically detect support for the EDNS Client Subnet: every fourth request from Google AS came with this option.

In addition to Google, Client Subnet received 4 requests from Brazil from a resolver using a hack with bit 0x20 :

  ts | src | query | client4 ---------------------------+---------------+----------------------+-------------- 2017-06-14 04:47:41.231796 | 187.1.128.119 | udp A zenitbET66.CoM | 200.248.248.0 2017-06-14 04:47:41.748585 | 187.1.128.119 | tcp A ZenItbET66.cOm | 200.248.248.0 2017-06-14 04:47:42.274296 | 187.1.128.119 | udp A zEnItbET66.coM | 200.248.248.0 2017-06-14 04:47:42.798544 | 187.1.128.119 | tcp A zeNitBET66.com | 200.248.248.0 

Hack with bit 0x20 is relatively popular - with it comes about 5% of requests from 2.5% resolvers (if you count the unique resolvers by ASN).

Another interesting EDNS option is the EDNS UDP payload size , which announces the maximum DNS packet size that the client is ready to accept. In addition to a quarter of requests that do not announce support for EDNS and 55% of requests that set this option to 4096 bytes, there are several other interesting values.

2% of requests say that UDP packets of an increased size do not need anything and use the minimum allowable value of 512. An example of such a resolver is irc.kristel.ru from Minusinsk , which changes this option after the first "big" answer, which had to be received by TCP. A similar behavior is observed on some other resolvers, including resetting the size back to 512 bytes after a while.

  ts | proto | qtype | qname | udpsz ---------------------------+-------+-------+--------------------+------ 2017-06-14 12:41:59.678401 | udp | A | zenitbet66.com | 512 2017-06-14 12:41:59.898596 | tcp | A | zenitbet66.com | 512 2017-06-14 12:42:32.14485 | udp | A | m.zenitbet66.com | 4096 2017-06-14 12:44:40.532815 | udp | A | www.kisa54.com | 4096 2017-06-14 12:56:54.083849 | udp | A | diplom-lipetsk.com | 4096 2017-06-14 12:56:54.311013 | tcp | A | diplom-lipetsk.com | 4096 2017-06-14 13:06:38.524876 | udp | A | www.cool-sino.com | 4096 

Also, a couple of scanners got into the logs, which could search for DNS amplification, since set the client size to 65527 bytes, which is the maximum value. Interestingly, the "big" responses powerdns sends without any response to resource records, putting the flag truncated in the header, which causes the resolver to go to TCP. So powerdns avoids DNS amplification when working with large UDP responses.

I was a little surprised that not a single DNS request over TCP came through using TCP Fast Open . Of course, the lack of this feature can be explained by the fact that if you worry about speed, then first of all you should not give large DNS responses that force the resolver to switch to TCP.

DNS and routing

For 10 hours on the above looking glass did not appear / 32 routes to any of the IPv4 addresses "added" to DNS, but after 20 hours at least on LG TTK and the university network these routes appeared. If you take measurements using RIPE Atlas, then you can find a number of transit providers who probably perform rezolving and enter routes to the filter, receiving 2049 A records in response:

• DataLine - in traceroute, filter01.dtln.ru starts to glow,
• Rostelecom - Rostelecom hops 188.254.78.25 and 95.167.93.150 are added to the traceroute at the exit from AS8997 on routed IP routes that are not observed on dozens of other traces to neighboring hosts from the same / 24 network, i.e. hardly a balancing artifact
• ReTN is a similar story with a three-hop route lengthening to "dedicated" hosts, and the filter on the ReTN network on the Habré has already been written by @amarao .

The list is incomplete, because was compiled by the method of intent peering. The presence of large providers in the list indicates that the question of the potential vulnerability of critical infrastructure to this attack is not closed. Also remain open questions:

• How does the effect of the DNS resource records in the response affect the special effects? You can set it, for example, using the sortlist or directly generate a manual response in the LUA code
• How quickly is an IPv4 address that gets "resolved" added to routes?
• Is IPv6 address resolving performed?
• What other interesting conclusions can be drawn from such data?

If someone wants to look at the data on his own, then in RIPE Atlas these are measurements: 8844224 , 8844225 , 8844226 , 8844227 , 8844228 , 8844229 , 8844230 , 8844231 , 8844232 , 8844233 , 8844234 , 8844235 . Requests for the first 16 hours of the experiment are available as a postgres dump: 9.6 . I can ship gigabytes of pcap by separate request.