{"id":9526,"date":"2019-11-07T18:27:58","date_gmt":"2019-11-07T17:27:58","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=9526"},"modified":"2019-11-07T18:40:23","modified_gmt":"2019-11-07T17:40:23","slug":"dns-over-https-one-problem-solved-but-a-bunch-of-new-ones-created","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/11\/07\/dns-over-https-one-problem-solved-but-a-bunch-of-new-ones-created\/","title":{"rendered":"DNS over HTTPS: One problem solved, but a bunch of new ones created…"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

In the course of attending the lecture \u201cSecure Systems\u201d I became aware of a blog post by Geoff Huston<\/a><\/strong> on how the Domain Name System (DNS) handles \u201cno such domain name\u201d (NXDOMAIN) responses and which possible attack vectors could result from this. His analysis showed how little effort is necessary to perform a Denial of Service (DoS) attack against random authoritative name servers. After a presentation on this subject I decided to delve a little bit deeper into this topic and I came across the fuss about the new DNS over HTTPS (DoH) protocol earlier this year. The juicy findings during my research inspired me to write an own blog post about it. As with any technology, there are two sides to every coin. It always depends on which perspective you take and what hidden agenda you may pursue. For that reason, this blog post is not intended as a critique of the DoH protocol itself, which can be a valued addition to the internet and appears to have helpful uses. Therefore, my focus was on how DoH might currently be implemented having regard to the overall context. Herein, I will not go into technical details of the DoH protocol and thus refer to the corresponding RFC 8484<\/a><\/strong> containing all these information. <\/p>\n\n\n\n\n\n\n\n

<\/div>\n\n\n\n

Worrying centralization on the Internet<\/h2>\n\n\n\n

Since its development in 1984, the DNS has become undoubtedly the most highly distributed global database on the internet. Every day, millions and millions of people are independently adding and changing records in this database in a loosely coupled system or using them to find their desired resources. Today, the World Wide Web is highly distributed as well, with countless systems connected and innumerable actors continuously publishing their content or accessing web resources by use of the underlying HTTP protocol and its encrypted version based upon Transport Layer Security (TLS). Both the DNS and HTTP protocols demonstrate vividly the basic architectural principles of the internet, such as loose coupling between different systems and layers, loose coordination between various entities that use a certain protocol and widely decentralized distribution of the protocol and associated systems.<\/p>\n\n\n\n

But over the last ten\nyears, there has been a noticeable tendency on the internet, where the majority\nof traffic was shifting more and more towards a few digital behemoths. In this\ncontext, the US network equipment provider Sandvine recently noted in its annually\npublished \u201cGlobal Internet Phenomena Report\u201d that roughly 43% of the worldwide internet\ntraffic is solely generated by applications and services of the six major tech\ncompanies Google, Netflix, Facebook, Microsoft, Apple and Amazon. Overall,\nGoogle leads with a total share of 12% as the top consumer of bandwidth on the\ninternet and dominates in the percentage of connections as well. Close behind\nis Netflix with 11% as the single largest consumer of traffic downstream.<\/p>\n\n\n\n

This previously described trend towards an intense centralization onto a small number of very large platforms led to intensive efforts to \u201cre-decentralize the web\u201d. Advocates of the effort to resist and turn back this increasing centralization of the internet include many leading figures such as Sir Tim Berners-Lee, better known as the \u201cinventor of the World Wide Web\u201d, or Vinton Cerf who is one of the \u201cfathers of the internet\u201d, as well as Brewster Kahle who became known as the founder of the US web traffic analysis company Alexa Internet.<\/p>\n\n\n\n

While internet traffic to particular destinations is more and more concentrated, at the same time the individual physical destinations in these large platforms, more precisely the Points of Presence (PoPs) which form the so-called \u201cEdge\u201d, are highly distributed in order to provide optimal performance no matter where their users are located. But while these PoPs may be physically distributed, the administration, operation and control of every single server remain centralized. If you are wondering at this point how traffic distribution at the Edge works with DNS and other load balancing techniques, I would like to recommend you my other blog post<\/a><\/strong> on this subject. <\/p>\n\n\n\n

<\/div>\n\n\n\n

Where there’s light, there’s shadow<\/h2>\n\n\n\n

Not for the first\ntime today, is DNS quiet a fertile field of opportunity for both surveillance\nand access control. Because the protocol was developed at a time, when most of\nthe actors within the network knew each other personally, encryption was not a\ntop priority and in this totally unencrypted mode DNS operates by default until\ntoday. This means that queries and responses are available to everyone who has\naccess to the physical layer. In this case, the protocol has no authentication,\nso that a network operator such as your Internet Service Provider (ISP) can\nintercept DNS queries to any IP address and provide a response on their behalf,\nwithout knowledge of the querier. In addition, every single transaction on the\ninternet begins with a name resolution query using DNS. Thereby, DNS is an\naccurate and also chronological indicator of everything what we do on the\ninternet. The fact that this is a totally unprotected and open protocol turns\nit into a huge minefield. It is hardly surprising that many service providers as\nwell as states with a repressive political regime associated with extensive\ncensorship use DNS for all kinds of purposes relating to both surveillance and\naccess control.<\/p>\n\n\n\n

First of all, it is useful in this context to look more particularly at the interaction between the user\u2019s client and its possibly self-chosen recursive resolver, which often has been allocated instead by the ISP. This is an important piece of the puzzle, because at this point it is the only time as part of name resolution using DNS where the user\u2019s IP address is contained in the query. Once the query is passed within the DNS infrastructure, it is no longer possible in this way to identify the user directly. At this point please note that a basic understanding of the principle of recursive name resolution is important in the paragraphs below. If you may have stumbled a bit, it would be advisable to take a quick look at the blog post of Cisco Systems<\/a><\/strong> on this subject before you continue reading.<\/p>\n\n\n\n

Nevertheless in order\nto detect the user\u2019s IP address as a service provider, a mechanism called EDNS\nClient Subnet (ECS) was standardized, which uses the EDNS0 extension. This\nattachment includes information about the IP subnet of the user\u2019s client inside\nthe DNS query sent by a recursive resolver. At this point it should be noted\nthat the usage is always a balance between privacy and performance, as the\nlatter is associated with user information leakage.<\/p>\n\n\n\n

The rise of Content\nDistribution Networks (CDN), which typically operate multiple PoPs, has led to\na technique where the assumed geolocation of the recursive resolver was a sufficiently\ngood indication to locate the user\u2019s client. However, the parallel growth of\nthe use of open DNS resolvers like e.g. Google (8.8.8.8), Quad9 (9.9.9.9) or\nCloudFlare (1.1.1.1) ruined this assumption. This trend has caused issues on\nthe CDN side including misdirected users and an extremely inefficient delivery\nof their content. The perceived \u201cwhite knight\u201d here was the abovementioned ECS mechanism,\nwhereby the user\u2019s IP address within the attachment survives recursive resolver\nhand-offs and can be used as a distinguishing label for local cached DNS\nqueries.<\/p>\n\n\n\n

\"\"
Accurately estimating the location of a user\u2019s client with the ECS mechanism.<\/figcaption><\/figure>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nAs\nalready mentioned at the beginning, DNS could be seen as a kind of an invariant\ndistributed database. No matter who submits a name resolution query, the\nsubsequent response will be always the same. Thus, ECS may be an indication\nthat some actors pursue a hidden agenda and intend DNS to be inconstant in a\nway, such that the response may depend on the identity of the querier.\nSemantically a line is being crossed here, but more importantly, an obvious red\nline concerning privacy is being crossed too. Previously, authoritative name\nservers were not able to detect the user\u2019s IP address and as well as its\nidentity. By default, DNS queries do not disclose the original querier, but\nwith ECS a name server has the ability to recognize the user\u2019s client. This is\na recipe for interception and eavesdropping on the server side, which allows a\ndeeper look at the user\u2019s interests by analyzing the domain names served.\n\n\n\n<\/p>\n\n\n\n

<\/div>\n\n\n\n

Securing the transfer is only half the story<\/h2>\n\n\n\n

First of all, the TLS\nprotocol ensures both that the communication between the user\u2019s client and a\nserver is encrypted and the server is operated under the authority of the named\nentity that the client wanted to connect to. In almost the same way as TLS is\nused to protect HTTP connections and ensures that the end point is an\nauthorized agent of the named service. But this protocol can also be used in\nthe context of DNS to protect the transfer between the user\u2019s client and its\nrecursive resolver. Since the standardization of DNS over TLS (DoT) an\nincreasing number of recursive resolvers are available that support DNS in its\nencrypted version. There are implementations for all common DNS servers like\ne.g. Unbound or PowerDNS and also BIND which can be configured accordingly. So\nif you are ready to move off the beaten track and set up your own DNS\nresolution environment on your home network, you can bypass the recursive\nresolver provided by your ISP and use DoT which will hide your name resolution\nqueries from prying eyes of your ISP and others.<\/p>\n\n\n\n

For the sake of\ncompleteness, it has to be considered that this is a highly qualified form of\nprivacy. It is far from being a solution for the butcher, the baker and the\ncandlestick-maker. Adding DoT support to your network usually requires the\ninstallation of your dedicated DNS server, because many home routers such as those\nof the German manufacturer for consumer electronics AVM, which has a market\nshare of more than 50% in Germany, do not support DoT until today. Moreover,\nthe number of users willing to make such efforts in this respect is likely to\nbe relatively small. A similar picture can be seen in Apple\u2019s iOS, which has no\npossibility for the user to activate DoT within the operating system. Thus, the\ninstallation of some third-party app is necessary here as well. Only in Android\nsince version 9 there is a DNS privacy option, which is relatively hidden and the\nprobability that a user stumbles over it while swiping or tapping around on his\ndevice is very unlikely.<\/p>\n\n\n\n

But the proper\nconfiguration of your client and an open DNS resolver, which supports client\nconnections using DoT, is only half the story. The core issue in this context\nis: Who am I going to talk to? This is a crucial decision! While you are\npreventing others from looking over your shoulder at your DNS queries, you are\nstill allowing your chosen recursive resolver a deep insight into your browsing\nactivities. As mentioned before, there are several open DNS resolvers being\nprovided by Google, Quad9 or CloudFlare.<\/p>\n\n\n\n

Sharing your secrets with Google may sound a bit like supping with the devil and you do well to use a long spoon. That Google has an unbridled appetite for all kind of data is an open secret. Their advertisement platform is continuously generating extensive user profiles and they are masters of \u201csurveillance capitalism<\/a><\/strong>\u201d. In their defense, it has to be said that they clearly stated not to \u201c…correlate or combine information…\u201d from their public DNS service with \u201c…any personal information that you have provided Google for other services…\u201d However, this raises the question of how such unilateral commitments are enforced within the company? Google is not really known for permitting a compliance inspection by an independent third-party. While the previously quoted statement has a noble intent, how can a user be sure that they fully adhere to it?<\/p>\n\n\n\n

Let us have a look at\nthe situation from the user\u2019s perspective. Once you leave the reservation and\nchoose one of the abovementioned open DNS resolvers, you will also be leaving\nthe safe haven of your local national regulatory framework. However, there are\ntwo sides to every coin. On the one hand you possibly circumvent what you\nexperience as a bothering content control or a kind of censorship, but on the\nother hand you also circumvent any rights and protections you may have through\nthe same national regulations. The core issue here is: If you leave any\nnational jurisdiction, then who is left to keep a sharp eye that service\nproviders adhere to their statements?<\/p>\n\n\n\n

This is not only\nabout trust in the service provider at the other end of the line. Even\naccessing such a privacy-oriented service may pose an issue. In the course of\nthe standardization of DoT it has been specified that this service is using TCP\nport 853 instead of port 443 which is used to protect HTTP connections with TLS.\nIn this context, it was not taken into account that any network operator is\nable to prevent users from making use of DoT by simply blocking all traffic to\nTCP port 853.<\/p>\n\n\n\n

All in all, it can be\nnoted here that DoT is specialized service which remains reserved for merely a\nfew people. In addition, this service can easily be blocked and it may prevent\nsurveillance on the physical layer, but in the end you share your whole\nbrowsing activities with the recursive resolver of your choice. There is no\ndoubt that DoT is reliably protecting privacy during transfer, but after all\nyou are stuck between a rock and a hard place and you can only choose to whom\nyou expose yourself.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Is DoH merely old wine in new bottles?<\/h2>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nWhat\ncaused all the fuss at the 104th meeting of the Internet Engineering Task Force\n(IETF) in Prague at the end of March was a debate on a variant of this DoT\napproach named DNS over HTTPS (DoH). With respect to the transfer of DNS\nqueries on the physical layer there is almost nothing wherein DoT and DoH\ndiffer from each other. To put it in a nutshell, they both transfer name\nresolution queries between a user\u2019s client and its recursive resolver while\nthese have been encrypted with TLS. Regarding to the transport layer the only\ndifference between these two approaches is that the DoH protocol uses TCP port\n443 and thereby the same port as the HTTP protocol in its encrypted version. At\nfirst glance, it may look like a cosmetic change but there are fundamental\ndifferences that exceed this simplistic protocol tweak and will become more\nobvious in the section, where Pandora\u2019s Box is opened.\n\n\n\n<\/p>\n\n\n\n

<\/div>\n\n\n\n

Another one bites the dust<\/h3>\n\n\n\n

A network operator such as your ISP usually pursues the goal to provide excellent network performance especially in respect to name resolution while protecting the security as well as privacy of their users. Furthermore, most of them offer filtering services based upon DNS, which are required for e.g. malware and security protection in enterprise networks or parental controls on your home network. Therefore, many operators are also interested in adding support for DoH and DoT respectively. As already mentioned at the beginning, concerning the discussed centralization on the internet, it does appear that a network operator will no longer be a part of the value chain for delivery of network services such as DNS resolution and related services.<\/p>\n\n\n\n

Moreover, a name resolution using DoH which an ISP might provide to its users is probably not a recursive resolver that can be accessed by everyone on the internet and in fact a sequel of the current model, whereby the servers are protected by an Access Control List (ACL) to reduce possible abuse. This is in contrast to the open DNS resolvers, which are openly accessible from any network. In addition to that an ISP also typically has a direct and trusted relationship with its users which are normally bound by legal agreements including terms of service and a privacy policy. Depending on the country there are national regulations, such as the General Data Protection Regulation (GDPR) in Europe that may also control privacy, data collection and handling of data. All of those things would apply to any network operator providing name resolution using DoH as they do to conventional DNS resolution. <\/p>\n\n\n\n

<\/div>\n\n\n\n

Strengthening centralization through DoH<\/h3>\n\n\n\n

As indicated above,\nthe major problem with DoH is that it does not use the recursive resolver in\nyour operating system for name resolution, regardless of whether it is\nself-chosen or not. Instead of that it uses a recursive resolver, which the\ndeveloper of an application has approved. The companies Google and Mozilla, together\nwith a market share of more than two-thirds in the web browser\u2019s market, have\npresented first examples. In releases thus far, Mozilla\u2019s Firefox has defaulted\nto the open DNS resolver CloudFlare and Google\u2019s Chrome browser is using their\nown public DNS service. Who would have thought that? This further concentration\nof name resolution queries by DoH onto a few digital behemoths, that have a\ncommercial intent, reinforces evermore the centralization of operation and\ncontrol on the internet.<\/p>\n\n\n\n

Now, if you continue\nthese thoughts it will be just a matter of time before DoH is enabled by\ndefault. This means that there are merely a few big players, rather than a wide\nvariety of recursive resolvers supporting DoH, which is in complete\ncontradiction to the highly distributed nature of DNS today. While the web\nbrowser developers has so far turned DoH off by default and users have a chance\nto leave it so, the obvious long-term goal of these companies will be to enable\nDoH permanently at some point in the future. Thus, the current opt-in model\nseems to be the breeze before the storm.<\/p>\n\n\n\n

<\/div>\n\n\n\n

The train might be unstoppable<\/h3>\n\n\n\n

The development of\nDoH so far reminds me inevitably of the American near-catastrophic movie\n\u201cUnstoppable\u201d from 2010 where Denzel Washington and Chris Pine are trying to stop\na runaway freight train. Without telling too much, like almost any good\nHollywood movie, there is a happy ending. However, in the context of DoH I still\nhave some doubts…<\/p>\n\n\n\n

Introducing a new\nprotocol, such as Internet Protocol Version 6 (IPv6) in the past, requires a\nproper technical coordination within the community, extensive and transparent\nmeasurement as well as comprehensive technical discussions over several years and\nsuccessive adoption. In this example, acceptance of IPv6 grew organically over\ntime, which is partly due to the diversified and large number of parties that\nneeded to independently take steps adopting those protocols. In contrast, there\nare significantly fewer major operating systems or web browsers than network\noperators and such.<\/p>\n\n\n\n

The final outcome of\nthis further centralization is that if only two web browser developers with\nsuch a high market share have implemented DoH, then the acceptance of DoH could\nincrease quiet fast and outrun or even replace conventional name resolution\nusing DNS. It would be unprecedented if a new protocol could be introduced so\nquickly and replace an established, well-engineered and highly distributed\nprotocol like DNS at the end of the day. This dangerous potential of DoH alone\ndemands for a lot of testing, discussion and broad approval of all parties on\nthe internet worldwide. To illustrate this potential once again, if companies\nsuch as Google and Mozilla were implementing DoH in their web browsers or\noperating system, then adoption could occur abruptly and they would become the\nfrequently used recursive resolvers with majority of name resolution queries on\nthe internet.<\/p>\n\n\n\n

In principle, it is\nof course positive, if new security related protocols are quickly accepted and\ndriven by the actions of a few key players. Nevertheless, it is important to\nalso concede that this may be simultaneously in contradiction with other goals\nfor the design and operation of the internet, which requires thoughtful\nconsideration of all the pros and cons as well as an extended discussion with\nall actors involved.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Unveiling Pandora\u2019s Box<\/h3>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThe\nintroduction of DoH entails a variety of potentially significant risks to the\noverall security, stability and performance of the internet particularly with\nregard to the repeatedly named concentration of name resolution queries. Now,\nlet us open Pandora\u2019s box and see what is inside. Shall we?\n\n\n\n<\/p>\n\n\n\n

<\/div>\n\n\n\n

Operational shift of the internet infrastructure<\/h4>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nShifting\nfrom a large number of highly distributed recursive resolvers towards a few\ncentralized ones will probably have notable impacts on the administration,\noperation and control of the internet. The full impact in detail of such a\ndistinct and abrupt change requires an extensive study by a range of parties\nacross the internet.\n\n\n\n<\/p>\n\n\n\n

<\/div>\n\n\n\n

Decreased stability and reliability<\/h4>\n\n\n\n

An intense\ncentralization may raise the vulnerability of a system, because it will become\na single point of failure and thus each individual failure can have serious\nimpacts. This indicates that if the authoritative DNS infrastructure becomes\nmore concentrated as a potential result of DoH, then it will have negative\nimpacts on stability and reliability of the DNS as well. While not caused by\nDoH, there are several examples of extensive internet outages when very large\nplatforms that provide DNS resolution experience technical faults or a\ncyber-attack, such as Dyn, which is now a subsidiary company of Oracle. In 2016\nthey became suddenly the victim of a Distributed Denial of Service (DDoS)\nattack, which also had massive impacts on e.g. Twitter, Spotify or SoundCloud,\nmaking uses of their network services. This attack demonstrates vividly how\nweaknesses in the DNS infrastructure and concentration of name resolution\nqueries may affect the stability and reliability of the internet.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Increased vulnerability to cyber-attacks<\/h4>\n\n\n\n

Further concentration\nof name resolution queries by DoH could lead to a significant reduction in the\nnumber of recursive resolvers. As mentioned before, this results in a single\npoint of failure on which attackers can focus, possibly altering the Return on Investment\n(ROI) required for a large-scale attack to succeed. Such threats may entail a\nhuge impact of DDoS attacks as shown by the example of Dyn or a standard DoS\nattack against a small number of systems.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Loss of security threat visibility<\/h4>\n\n\n\n

Some users will experience a degraded ability or total loss of filtering services based upon DNS, a mechanism called \u201cDNS sinkhole<\/a><\/strong>\u201d, which is one of the primary and most efficient ways to protect a network against all kinds of malware and cyber-attacks. This is due to the fact, that a network, which is connected to the internet, can perform some degree of local policy control that remains local and does not spread beyond its administrative boundaries. That includes extensive monitoring and protection of a network\u2019s security and all devices connected to it. In the course of time, one of the common and widespread practices is the usage of the DNS for monitoring, rectification or prevention of malware infections and other security issues. This approach is used in many cases, ranging from ISPs to enterprise networks. Sometimes a dedicated DNS server is operated inside the network, while otherwise it will be obtained externally as a cloud-based service.<\/p>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nTo\nillustrate the impacts again, in many networks the Fully Qualified Domain Names\n(FQDN) of name resolution queries will be steadily checked for matches with\nlists of well-known malware command and control servers. In some cases when a\nmatch occurs, the network operator, or sometimes the owner of a device, will be\nnotified of a malware risk. In other cases, the internal DNS servers are\nconfigured to rewrite the response for a query of a malware related FQDN, which\nprovides a new IP address that points to a server alerting the user of a\npotential infection and providing an NXDOMAIN response to terminate the DNS\nquery. This approach will fail, because name resolution using DoH is bypassing those\nservers that provide this functionality. In the end, this can lead to a lot of\nblind spots in an extremely critical field of security threat visibility.\n\n\n\n<\/p>\n\n\n\n

<\/div>\n\n\n\n

Loss of content controls or rather parental controls<\/h4>\n\n\n\n

Similar to the\nabovementioned usage of DNS on enterprise networks for monitoring purposes and the\nprevention of security issues, it is also often employed at home to provide filtering\nservices such as parental controls. Thanks to this mechanism, a parent can\nconfigure the corresponding service to prevent their children from accessing\ninappropriate or disallowed content on the internet. Now, let us imagine you\nhave two children of elementary school age between 6 and 9 years old, so it is\nadvisable to configure policies that block them from accessing any web resources\non topics such as social media, gambling, drug abuse, pornography, etc. These\nservices are often cloud-based and very popular, because they usually work\nindependently of any device types or operating systems.<\/p>\n\n\n\n

Also in this case the\napproach typically works by use of DNS response matching and rewriting, after\nwhich the user is redirected to a server alerting him of a malware risk or\nreceives an NXDOMAIN response. But this approach will fail as well, if name\nresolution queries are bypassed, because of DoH. A possible proposal here is that\na recursive resolver supporting DoH offers such services, but this is not a\ndecision the user is being permitted to make. In addition the user can be\ntotally satisfied with its current solution and does not want to take the time\nto set up a new solution or intends to use another service provider for this\nfunctionality. It seems there are no open DNS resolvers using DoH and offering\na mature service for content control or rather parental control at the same\ntime. Indeed, there are related solutions, but they appear very sparse and poor\nin customization as well as functionality and do not meet the standards that\nhas established over the last two decades.<\/p>\n\n\n\n

Moreover, it is very\nlikely that a user intends to configure a dedicated DNS server, which provides functionalities\nsuch as parental controls, as many solutions do today. But this intention may\nbecome more complicated and different with DoH, because web browsers or other\napplications are overriding individual configurations of the user in the\noperating system.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Issues with Split-Horizon DNS<\/h4>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nThrough\nthe mechanism Split-Horizon DNS, separate servers are used to provide different\nname resolution, depending on whether it is for an internal or an external\nnetwork. It is necessary for security and privacy management and is often used\nin enterprise networks. Specifically, this means that there are domain names, which\nonly should be resolved internally or point to special internal servers for\ninternal users and are publicly accessible for users outside of the network.\n\n\n\n<\/p>\n\n\n\n

\"\"
Separated name resolution for an internal or external user’s client through Split-Horizon DNS.<\/figcaption><\/figure>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nA\npractical example would be that an enterprise provides a groupware service on\npremise, which is reachable via a private IP address of the CIDR block\n192.168.0.0\/16 and is accessible via the web browser at https:\/\/groupware.example.com.\nThe FQDN is maintained solely on internal recursive resolvers and thus cannot\nbe accessed using the authoritative DNS infrastructure on the internet. In the\ncontext of DoH this domain name will no longer be resolvable, because the\ninternal DNS servers that can provide a valid response are no longer provided\nin the resolution path for a user on that network. The internal recursive\nresolver will be skipped and the name resolution query is directed instead to\nan open DNS resolver. At this point, of course you can criticize the use of\nSplit-Horizon DNS as well as Network Address Translation (NAT), but regardless\nof whether this is good practice or not, it is frequently used and should be\ntaken into consideration when developing a new protocol.\n\n\n\n<\/p>\n\n\n\n

<\/div>\n\n\n\n

Leaking of internal data<\/h4>\n\n\n\n

As shown by the\nexample above, when name resolution is separated through Split-Horizon DNS, querying\nan open DNS resolver using DoH will lead to a NXDOMAIN response. However,\nbecause the internal name resolution query was sent to the authoritative DNS\ninfrastructure, the availability of that internal domain name has leaked\noutside of the network. At the same time, if a reverse DNS query of a domain\nname is performed that will leak private IP addresses as well. Even so, such a\nleak of IP addresses happens regardless of whether Split-Horizon DNS is used or\nnot.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Possibility of reduced DNS server implementations<\/h4>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nAnother\nside effect of further concentration of name resolution queries due to DoH might\nbe less DNS server implementations or at least a smaller number of them are responsible\nto handle the overall traffic, which can be seen as worrying. Simultaneously,\nthis could also lead to a shift of traffic away from service providers\ndeveloping proprietary solutions instead of using open source equivalent. Thus,\nit is likely that the impact of exploits in such DNS server implementations,\nwhich are used by a few digital behemoths, can have a huge impact on the\ninternet worldwide.\n\n\n\n<\/p>\n\n\n\n

<\/div>\n\n\n\n

Possibility of increased commercial usage of user data<\/h4>\n\n\n\n

As already mentioned\nat the beginning, the highly distributed nature of DNS today is decisive for\nthe fact that there are merely a few data sets of user DNS queries with a\nglobal reference. Possible exceptions here are the open DNS resolvers, which\nreceive billions of billions of queries each single day. But through the\nconcentration of name resolution queries by DoH, very large data sets may\narise, which carry the risk that service providers fall into temptation to use\nthem commercially. In particular, this might apply if an open DNS resolver\noffers its service for \u201cfree\u201d. But we probably all know the popular adage: \u201cThere\nis no such thing as a free lunch\u201d. Originally, the \u201cfree lunch\u201d refers to the\ntradition of western saloons providing a pretended free lunch to patrons who\nhad purchased at least one drink. Many foods on offer were high in salt, so\nthose who ate them ended up buying a lot of beer. This demonstrates vividly the\nidea that you never get anything for nothing.<\/p>\n\n\n\n

Even if the\nabovementioned data sets are \u201canonymized\u201d in a way, it is very likely that some\nservice providers will have enough other data sets that a combination of them\nsimply allows de-anonymization. Furthermore, a user may feel uncomfortable with\nsending their name resolution queries to an open DNS resolver using DoH,\nbecause they have no trusted relationship with him, which can be also problematic\nin the context of national regulations such as the GDPR.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Possibility of negative impacts on CDN localization<\/h4>\n\n\n\n

There is a risk for some CDNs through DoH that optimizing the delivery of their content is no longer possible in the way as it is today. As already mentioned at the beginning, a CDN realizes geolocation by accurately estimating the location of a user\u2019s client, which normally uses the ECS mechanism. This information is used afterwards to dynamically generate DNS responses based upon the geographical location of a user. The primary goal of every CDN is to always direct the user to the nearest PoP in its region which caches the desired content.<\/p>\n\n\n\n

Noticeable impacts of a misdirected user\u2019s client might be slower access to web resources and more traffic traversing the backbone as well as suboptimal peering points in contrast to PoPs with direct interconnection between networks. At this time, it is very difficult to estimate the actual impacts on end user performance, because with Google and CloudFlare only two of the major open DNS resolvers even support DoH. <\/p>\n\n\n\n

<\/div>\n\n\n\n

Abuse of DoH for malware command and control<\/h4>\n\n\n\n

As will be illustrated in more detail later by an example and with respect to the loss of security threat visibility, it is relatively obvious that DoH can now being used virtually as an undetectable command and control channel for malware. This is due to the fact that from the outside it looks like the HTTP protocol in its encrypted version and uses the same TCP port 443 as well. You could make assumptions in the opening TLS handshake, because the name of the server that a client wanted to connect to will be sent in clear text. But work on the extension to TLS named \u201cServer Name Identification (SNI)<\/a><\/strong>\u201d is in progress, and so it is likely that even this small loophole might be shut down at some point in the future. Now, if you add some padding like in TLS version 1.3, then even traffic analysis would not inevitably reveal what happens inside the connection.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Interruption of lawful DNS blockings<\/h4>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nIn\nan increasing number of countries, a network operator is forced by national\nregulations to realize a blocking of domain names. Some democratic countries\nhave already implemented a corresponding national regulatory framework, but DoH\nmay render this useless. This is a fact that should chasten national regulators,\nwhich is why they have to demand that recursive resolvers supporting DoH comply\nwith all possible national regulations. Thereby, this is not about the basic\nissue whether a blocking of domain names is either reasonable, effective or\ncould be easily circumvented. If companies operate in a particular country, it\nis usually expected to comply with the applicable laws and so network operators,\nproviding name resolution using DoH, will have to define how to satisfy them.\nAt this point it should be noted that this is not to be confused with some\nsorts of blockings, which are used by political regimes associated with\nextensive censorship for all kinds of purposes relating to both surveillance\nand access control.\n\n\n\n<\/p>\n\n\n\n

<\/div>\n\n\n\n

Possible impacts on server-side performance and scaling<\/h4>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nAs\nalready mentioned at the beginning, many new protocols such as IPv6 are\nintroduced organically, which means the adoption or growth of the protocol runs\nrelatively gradual. Therefore, all parties have a longer period of time to\nlearn more about scaling and achievable refinements in performance. In\naddition, they are able to carefully examine and realize improvements in\ncomparison with an abrupt migration, where the significant shift to a new\nprotocol or system occurs in a very short time. With regard to the repeatedly\nnamed concentration of name resolution queries by DoH, a rapid change is very\nlikely in this context. However, this raises the risk of instability and\nreduces the opportunity of actors involved in development and implementation to\nlearn or make technical changes successively with relatively minimal impact on\nsystems and users due to a high spreading in the case of an abrupt migration.\n\n\n\n<\/p>\n\n\n\n

<\/div>\n\n\n\n

Increased exploiting against DNS engineers and administrators<\/h4>\n\n\n\n

Due to the described trend towards an intense centralization onto a small number of very large platforms, it is just a matter of time that attackers will realize the fact that merely a few people responsible for DNS engineering, as well as administration and operation, will control a key component of the internet. As a consequence thereof it is likely that a sneaky attacker would target exploits such as \u201cspear-fishing<\/a><\/strong>\u201d combined with social engineering techniques against this small number of actors in order to gain access to systems of the DNS infrastructure. During his active time in the 1980s and 1990s, the former hacker Kevin Mitnick certainly would have rubbed his hands at this sight.<\/p>\n\n\n\n

<\/div>\n\n\n\n

DNS exfiltration on a new level<\/h2>\n\n\n\n

By pushing the\nclient-side DNS queries into an encrypted HTTP connection, the internet itself\nhas lost control of one end of the line and each application, including the\nvariety of malware as indicated above, can use DoH and the DNS respectively as\na command and control channel in a way that is virtually undetectable by the\nuser\u2019s client or a network operator. Much of today\u2019s preventive measures\nagainst malware such as a DNS firewall, which prevents systems and users from\nconnecting to known malicious web resources or protects against data\nexfiltration, are rendered useless by DoH. Thereby, it is not relevant whether\na web browser has enabled DoH by default, because applications can send name\nresolution queries using DoH in a way that bypasses today\u2019s counter-measures\nfor DNS.<\/p>\n\n\n\n

During my research for\nwriting this blog post I stumbled over another post, which deals with an\napproach for DNS exfiltration over DoH. Techniques for exfiltration over an\nalternate protocol such as using the DNS as a hidden communication channel are\nby no means a new concept. Using DNS as such a hidden channel has many benefits\nif you consider the monitoring possibilities of a target. Through usage of a\nprotocol that other technologies such as email or web browsing rely on, you might\nnot typically expect DNS to be used for anything other than the resolution of\ndomain names, as the name implies. Unfortunately, it is possible using an\nentirely legitimate protocol to communicate beyond network boundaries. But this\ntechnique still does not come without cost to an attacker, because a hidden\ncommunication via DNS is extremely slow in comparison with other options an\nattacker may have. Especially with regard to malware that uses the HTTP\nprotocol in its encrypted version for the communication.<\/p>\n\n\n\n

Many network\noperators have adjusted their monitoring to defend against this relatively old\nidea, which is employed by malware and attackers alike. The usage of Split-Horizon\nDNS, monitoring the size and rate of name resolution queries as well as the\nhostname labels inside a DNS query offers possibilities to detect and prevent\ntunneling an undesired connection. If you look at it from an attacker\u2019s\nperspective, this raises the complexity when trying to stay under the radar and\nhaving a reliable communication channel back into the network at the same time.\nBy optimizing the behavior of this connection it is possible to bypass\ndetection, but this comes along with a speed tradeoff. Simply forbidding DNS\nqueries to the outside of a network would obviously prevent the attack, but it\nis at the expense of usability. Luckily for defenders, monitoring of DNS is\nrelatively simplistic since you only have to focus at the protocol level and apart\nfrom a few caching  forwarders that are\nallowed to send name resolution queries to the authoritative DNS\ninfrastructure.<\/p>\n\n\n\n

Now, with DoH the deck will be reshuffled again. In principle, it is possible to achieve a DNS communication that is RFC compliant using an encrypted HTTP connection. It is virtually like a JSON-API to perform DNS queries. First, a simple HTTP GET request is made, followed by a response in JSON format, all via an open DNS resolver like Google. Right here, a sneaky attacker would frolic in delight. Using a legitimate and more often than not trusted domain names such as google.com to obfuscate your traffic to a VM instance on Google Cloud Platform (GCP) is not uncommon. This mechanism called \u201cDomain Fronting<\/a><\/strong>\u201d has established in some degree, where it has been used to circumvent blocking of domain names due to censorship as well as in some kinds of malware. If you disregard the possible intentions associated with Domain Fronting, by abusing DoH the same level of evasion can be achieved, albeit at the cost of a much slower rate but using a trusted domain name.<\/p>\n\n\n\n

In the following, the\nboundary conditions and the possible attack scenario will be explained in\ndetail with the purpose of not only demonstrating the potential of DoH as an\nexfiltration channel, but also to raise defender\u2019s awareness so that monitoring\nand detection mechanisms can be developed. First of all, let us imagine you are\nthe responsible operator of a network that has relatively good monitoring. You\nare also able to detect the usage of DNS as an exfiltration channel or rather\ndo not allow name resolution queries to be sent to an open DNS resolver on the\ninternet. Furthermore, you have a highly sophisticated firewall operating on\nthe application layer, which enables web content classification and strictly\nblocks on that basis. The domain name google.com is on the whitelist and\ntherefore https:\/\/dns.google.com may probably not be blocked.<\/p>\n\n\n\n

Suddenly, a malware\ninfection happens that uses DNS tunneling and some malicious code on a user\u2019s client\nwill be executed that periodically requests for commands to run. The responses\nof those commands are encoded as a series of DNS A record queries sent to an\nattacker controlled domain name and reconstructed on the server-side.<\/p>\n\n\n\n

\"\"
Example traffic flow for name resolution queries using DNS.<\/figcaption><\/figure>\n\n\n\n

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nNow,\nthe exact same idea will be transferred to simply use a recursive resolver\nsupporting DoH for the same DNS queries. The queries themselves did not change,\njust the kind of transfer slightly differs that is used for sending a query and\nparsing the subsequently response.\n\n\n\n<\/p>\n\n\n\n

\"\"
Modified traffic flow with Domain Fronting to use DoH as an exfiltration channel.<\/figcaption><\/figure>\n\n\n\n

Unfortunately, you\ncan no longer rely on the fact that DNS is a specific protocol, which could\nsimply be monitored and filtered on a network, since we now have the additional\ncomplexity of an encrypted HTTP connection to an often trusted domain name such\nas google.com, smuggling the DNS queries undetected beyond network boundaries.\nOnce a query was sent to an open DNS resolver using DoH like e.g. Google, they\nin turn use traditional DNS to perform name resolution and provide a response\nto the user\u2019s client. <\/p>\n\n\n\n

<\/div>\n\n\n\n

The future is still uncertain<\/h2>\n\n\n\n

Since the first announcement of global IPv4 address exhaustion on January 31st<\/sup>, 2011 when the Internet Assigned Numbers Authority (IANA) has allocated their last two unreserved \/8 CIDR blocks to the Regional Internet Registry (RIR) for Asia-Pacific region, there has been established a massive use of IP address sharing practices. More than 20 billion devices are crammed into less than 4.3 billion IPv4 addresses. If we ever reach the other end of this dragging transition to IPv6 there is some hope that it is possible to restore IP address integrity, which is still relatively unlikely. But at the moment, the addresses are semantically messed up. At best in all this confusion of intensive address sharing, IP addresses are only non-persistent session tokens. But it seems that a single consistent namespace is what holds the internet together as a global coherent network.<\/p>\n\n\n\n

But will this continue to be the case if the functionality of name resolution, which is indeed the crucial point of the namespace, will be shifted under the surface of the water? Or will the namespace preserve its consistency when there is no possibility to have a comprehensive overview? As already mentioned at the beginning, with respect to geolocation there are intensive efforts to use the DNS to route users to the nearest PoP by tailoring the response to suit the querier. However, with DoH there are various possibilities to go significantly further in customizing views of the namespace based upon the user\u2019s identity and location as well as the application that they are running. Finally, this raises the question what happens to a consistent namespace, if the name resolution depends on who is making the query? Shame upon him who thinks evil upon it… <\/p>\n\n\n\n

<\/div>\n\n\n\n

References and further reading<\/h2>\n\n\n\n
  1. Centralized DNS over HTTPS (DoH) Implementation Issues and Risks <\/strong>by Jason Livingood et al.<\/em>
    https:\/\/www.ietf.org\/id\/draft-livingood-doh-implementation-risks-issues-04.txt<\/a><\/li>
  2. DNS Privacy at IETF 104<\/strong> by Geoff Huston<\/em>
    https:\/\/www.potaroo.net\/ispcol\/2019-04\/angst.html<\/a><\/li>
  3. More DOH<\/strong> by Geoff Huston<\/em>
    https:\/\/www.potaroo.net\/ispcol\/2019-04\/moredoh.html<\/a><\/li>
  4. Waiting for goDoH<\/strong> by Leon Jacobs<\/em>
    https:\/\/sensepost.com\/blog\/2018\/waiting-for-godoh\/<\/a><\/li>
  5. Global Internet Phenomena Spotlight<\/strong> by Cam Cullen<\/em>
    https:\/\/www.sandvine.com\/blog\/netflix-vs.-google-vs.-amazon-vs.-facebook-vs.-microsoft-vs.-apple-traffic-share-of-internet-brands-global-internet-phenomena-spotlight<\/a><\/li>
  6. Decentralized Web Summit: Towards Reliable, Private, and Fun<\/strong> by Brewster Kahle<\/em>
    https:\/\/blog.archive.org\/2016\/06\/16\/decentralized-web-summit-with-tim-berners-lee-vint-cerf-and-polyfill\/<\/a><\/li><\/ol>\n\n\n\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    In the course of attending the lecture \u201cSecure Systems\u201d I became aware of a blog post by Geoff Huston on how the Domain Name System (DNS) handles \u201cno such domain name\u201d (NXDOMAIN) responses and which possible attack vectors could result from this. His analysis showed how little effort is necessary to perform a Denial of […]<\/p>\n","protected":false},"author":475,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1,26],"tags":[312,307,178,316,306,309,311,317,259,308,260,314,313,258,164,315,310],"ppma_author":[785],"class_list":["post-9526","post","type-post","status-publish","format-standard","hentry","category-allgemein","category-secure-systems","tag-content-control","tag-content-distribution-network","tag-data-protection","tag-dns-exfiltration","tag-dns-over-https","tag-dns-over-tls","tag-dns-sinkhole","tag-domain-fronting","tag-domain-name-system","tag-edns-client-subnet","tag-geolocation","tag-nxdomain-response","tag-parental-control","tag-point-of-presence","tag-privacy","tag-split-horizon-dns","tag-surveillance-capitalism"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":28714,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/26\/taking-control-of-dns-over-https\/","url_meta":{"origin":9526,"position":0},"title":"Taking Control of DNS over HTTPS","author":"rh080","date":"26. February 2026","format":false,"excerpt":"For decades, enterprise security relied on a simple truth: if you control Port 53, you can see where your users are going. Every DNS query left the network in plaintext, straightforward to log, filter, and block. DNS over HTTPS (DoH), standardized in RFC 8484 [2], broke that model by wrapping\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/dns-traditional.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/dns-traditional.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/dns-traditional.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/dns-traditional.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/dns-traditional.png?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2026\/02\/dns-traditional.png?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":6535,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/03\/19\/how-internet-giants-deliver-their-data-to-the-world\/","url_meta":{"origin":9526,"position":1},"title":"How internet giants deliver their data to the world","author":"Ren\u00e9 Schl\u00e4fke","date":"19. March 2019","format":false,"excerpt":"In the course of attending the lecture \u201cUltra Large Scale Systems\u201d I was intrigued by the subject of traffic load balancing in ultra-large-scale systems. Out of this large topic I decided to look at traffic distribution at the frontend in detail and held a presentation about it as part of\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/03\/Figure5.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/03\/Figure5.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/03\/Figure5.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/03\/Figure5.png?resize=700%2C400&ssl=1 2x"},"classes":[]},{"id":3503,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/03\/30\/ci-cd-with-gitlab-ci-for-a-web-application-part-2\/","url_meta":{"origin":9526,"position":2},"title":"CI\/CD with GitLab CI for a web application – Part 2","author":"Nina Schaaf","date":"30. March 2018","format":false,"excerpt":"GitLab Our first approach was to use the existing GitLab instance of HdM for our project. For them, a shared runner was already defined on which we could run our jobs, so we were able to focus on the CI process itself. This plan worked out at first. We simply\u2026","rel":"","context":"In "DevOps"","block_context":{"text":"DevOps","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/devops\/"},"img":{"alt_text":"Shaky Pipeline GitLab","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/pipeline-gitlab-1024x156.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/pipeline-gitlab-1024x156.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/03\/pipeline-gitlab-1024x156.png?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":3933,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2018\/08\/15\/anonymity\/","url_meta":{"origin":9526,"position":3},"title":"Preserving Anonymity","author":"David Bochan","date":"15. August 2018","format":false,"excerpt":"Since the amount and value of data are constantly increasing more and more data of each individual is collected and processed. Moreover Facebook's recent data leak with Cambridge Analytica shows that collected data cannot be absolutely securely treated and stored. In 2014 and 2015, the Facebook platform allowed an app\u2026","rel":"","context":"In "Secure Systems"","block_context":{"text":"Secure Systems","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/secure-systems\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/08\/identification_methods-1024x495.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/08\/identification_methods-1024x495.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2018\/08\/identification_methods-1024x495.png?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":5179,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2019\/02\/24\/migrating-to-kubernetes-part-4-create-environments-via-gitlab\/","url_meta":{"origin":9526,"position":4},"title":"Migrating to Kubernetes Part 4 – Create Environments via Gitlab","author":"Can Kattwinkel","date":"24. February 2019","format":false,"excerpt":"Written by: Pirmin Gersbacher, Can Kattwinkel, Mario Sallat Connect Gitlab with Kubernetes With the Review Apps Gitlab offers an excellent improvement of the Developer Experience. More or less Gitlab enables the management of environments. For each environment, there is a CI task to each set-up and tear down. It is\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2019\/02\/pexels-photo-379964.jpeg?resize=1050%2C600&ssl=1 3x"},"classes":[]},{"id":20290,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/08\/02\/zero-trust-security-the-further-development-of-perimeter-security\/","url_meta":{"origin":9526,"position":5},"title":"Zero Trust Security – The further development of perimeter security?","author":"Max Merz","date":"2. August 2021","format":false,"excerpt":"Most companies use perimeter security to secure their cooperate applications, services and data from attackers and unauthorised users. This approach includes a cooperate network, where clients, that are part of the network are able to access the applications. This includes attackers that got access to these networks.Additionally more applications are\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/Windows_365.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/Windows_365.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/Windows_365.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/08\/Windows_365.png?resize=700%2C400&ssl=1 2x"},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":785,"user_id":475,"is_guest":0,"slug":"rs118","display_name":"Ren\u00e9 Schl\u00e4fke","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/6f7fece56cab81e7c64ed1e1adde0e5074b42933b48dd60fda248cd6a4850be7?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/9526","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/475"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=9526"}],"version-history":[{"count":37,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/9526\/revisions"}],"predecessor-version":[{"id":9570,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/9526\/revisions\/9570"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=9526"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=9526"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=9526"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=9526"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}