What will happen on February 1st?

Not that, of course, this was the first discussion of the issue on Habré . However, until now, the consequences were mainly discussed, while, in our opinion, the root causes are much more interesting.

So, on February 1 is scheduled DNS Flag Day . The effects of this event will occur gradually, but still faster than some companies will be able to adapt to it.

What it is? In simple terms, this is a manifesto of the world's leading developers of DNS servers: CZ.NIC, ISC, NLnet Labs, and PowerDNS.

DNS software manufacturers have long been faced with a problem: the development of the domain name system, the addition of new functions required by clients, the solution of security issues — all these processes are dramatically slowed down due to the cooperative structure of the DNS system and the need to maintain archaic servers that implement outdated versions of protocols (and even this is often done with errors).

Exception

According to the DNS protocol standards catalog , the current specification contains, as of January 21, 2018, 3248 pages. These include all relevant RFCs in the “internet standard” , “proposed standard” (which is essentially the same today), “best current practice” and “informational” statuses. For comparison: the HTTP protocol, which provides content delivery for all websites on the Internet, is summarized on 672 pages.

As the saying goes, if your project's TK is not like something, do not even try to invite me.

The need to implement the processing of all functions and exceptional situations described on 3,000 pages is hard work in and of itself, and in addition a whole number of DNS servers implement this or that functionality incorrectly, which leads to the need to additionally process non-standard behavior. In some of the aforementioned RFCs, despair overwhelming people working with the protocol splashes out even the name .

According to the key DNS developers, the situation with the complexity of the program code is already serious enough to take drastic measures. On February 1, as part of a coordinated action, updated versions of all major DNS servers will be released, in which support for certain incorrect behavior will be discontinued from now on and forever.

And more?

In order to clarify what exactly will cease to be supported, I will give an analogy. Imagine that, until 1999, people were not allowed on a plane with luggage, and in 1999, an official decision of the supervisory authority allowed passengers to take on board a bag (of a certain weight and size). Comfortable enough, right? You can carry a lot of useful things.

Just imagine now that in 2019 there are still airplanes that you can’t carry bags with, and until boarding you have no way of knowing if you can take your baggage with you.

Approximately the situation with the expansion of EDNS , the lack of support which from February 1 will lead to the inaccessibility of a number of websites. Roughly speaking, airplanes that do not know how to take luggage on board (at least minimal), in February, due to the 20th anniversary of the first EDNS standard, will no longer be allowed into a number of airports.

The announcement was made quite well in advance: in March-May 2018, the main organizers of the DNS Flag Day informed the public at a number of popular industry conferences . In addition, the release of updated versions of DNS servers by itself will not lead to problems instantly, since the operators have yet to switch to these versions, and this takes time. But, more significantly, a number of cloud-based DNS service providers also joined DNS Flag Day. Among them are such giants as Google (and their famous DNS server with an IP address of 8.8.8.8), Cloudflare, Facebook and Cisco.

As a result, sites that use DNS servers without EDNS support (that is, “airplanes” that do not know how to “take luggage on board”) will stop working since February 1 for everyone who uses open DNS servers 8.8.8.8, 9.9.9.9, 1.1.1.1 and several others. As DNS servers update with the providers, the list will grow.

The peculiarity of the functioning of the DNS server in the corporate infrastructure is that it usually does not ask for it, it works for itself and it works, therefore, often no one ever updates it. System administrators of the old school even love to be proud of the many years of uptime of such machines. The problem is that when there is a need to upgrade, it turns out that for this you need, for example, also to move from FreeBSD 5 to FreeBSD 10 (real case), for which, among other troubles, you will need to restart, and from the restart the old server may simply not quit.

The most annoying thing is that the solution of the problem in general does not boil down to a simple update of DNS servers. Some organizations use firewalls (both software and hardware-software), which forcibly discard all DNS packets with the EDNS function. Among other things, this was done by the old Juniper SRX models, but the matter is not limited to them. In principle, if we talk about firewalls and DPI-solutions as a whole, then a rather low level of development quality of a number of such solutions has long been known. All these years, the developers of the DNS protocol suffered from the problems they objectively caused, and now they have decided to strike back.

However, updating such solutions may take considerable time, and in some cases, it may be necessary to throw the once-expensive equipment into the trash and purchase new ones, which will cause many difficulties, for example, within the Russian budget cycle (especially if the equipment was discarded abroad, and there is no more opportunity to buy foreign from the organization for one reason or another - financial, political, ideological -).

So for those who have this problem, it's time to start to solve it. Note that the immediate solution requires only those problems that the corresponding verification tool displays with red signs "STOP" or "SLOW". The exclamation point in the yellow triangle is still only a warning and will not cause problems on February 1 (although in the long run this problem should be corrected).

And then what?

First, DNS Flag Day shouldn't provoke any significant cataclysms.

In various discussions, you can hear the criticism of the original post by Alexei Lukatsky on Habré: they say, the author took an excessively alarmistic tone. Nevertheless, it is impossible not to notice that just Alexey is the person who is very well aware of how it is sometimes arranged and what equipment is tied to the network infrastructure of large Russian organizations and government agencies. According to the study, the results of which appear to be at the disposal of the Coordination Center for the .RU and .РФ domains, the problem that was registered at a number of well-known sites before the Lukatsky post today already manifests itself in trace amounts, that is, a Cisco blog entry (and Subsequent notes, for example, on the Roskomvoboda blog, have the desired effect.

However, the success of DNS Flag Day will obviously lead to consequences, the most important of which is that such actions will be held in the future. There are still a lot of places in the DNS system that developers would like to embroider as quickly as possible; In addition, DNS is not the only such protocol in which there is something to disassemble. The example with the BGP attribute 0xFF, which we will discuss in the next article, clearly shows: sometimes vaccination is useful for the Internet.

What, today, leaves system administrators in front of a fairly straightforward dilemma:

1. Either the DNS server administrator should monitor the life of the Internet community, in particular, the news of the professional community of DNS developers, and, in particular, should generally pay attention and time to server updates;
2. Either the management of its own domain zone should be transferred to an outside provider specializing in such work (of which there are, in principle, mass).

However, we will probably return to this topic too.