Conference DEFCON 21. DNS can be dangerous for your health. Part 1
- Transfer
- Tutorial
My name is Rob Stakl, I’m a security consultant from Phoenix, Arizona, and I’m mostly a pentester. I have been participating in DefCon conferences since 1996, I am fond of high-rise photography, and this weekend was the eleventh anniversary of our wedding. I want to thank my amazing and understanding wife Linda, who did not expect that my participation in DefCon means that every year I will have to hold our wedding anniversary in Vegas, which I am very sorry for.
I am going to talk to you about a few things related to the research I have been working on for the past few years. They are united by a common theme - if you don’t monitor your DNS traffic and don’t understand what is happening there when everything is in order, then you probably don’t pay attention when bad things start happening to it. I “rape” the DNS for several years and this has always been one of my favorite attack vectors. You can spend a fortune hardening the perimeter of the network, but if I can get control of one of your devices, trust me, your game is over.
The lack of vulnerability scanners in the market that allow us to detect the wrong configurations always gives me the opportunity to "stick my foot in the door." Today we will discuss various topics in which I will talk about my adventures with the DNS and my tricks on people related to DNS.
These topics are about misunderstanding DNS behavior by end users of the network, I’ll talk a little about people who have not registered their domains, and about the domain hacking itself.
At the Black Hat and DefCon conferences in 2011, Artyom Deineberg spoke about what he called beat-squatting, or "turning the bits." Those who are not familiar with this study, but are interested in this problem in the DNS of popular domains, can download the materials of his presentation from the links on this slide.
Project Page /video presentation / slides
When I read the announcement of his speech, published before the report on Black Hat, I immediately became interested in how this can be used for my own purposes. Without going into details, I will explain what bit-squatting is, why it happens and what it affects. I will show you some examples of the risk that an accidental flipping of a bit in memory presents when 1 turns to 0 and vice versa. The following slides show how this looks like an example of a string in memory that displays a domain name.
In the middle of such a line, the unit turns to zero. Artyom investigated the phenomenon in which the error of a single bit in the correct part of the memory at the right time forced the client to request a completely legitimate, but incorrect domain name.
There was a lot of talk about the probability of the occurrence and the reasons for such an error, but I began to study all the ways that allow using this error for malicious purposes. So bit-squatting DNS allows you to distort domain names, then register these "wrong" domains and send user requests to them.
The next slide shows that, as a result of Google Squatting's bit-squatting, when a high energy proton in memory “hits” 1, meaning the letter g, turns it into 0, meaning the letter f, and as a result, the user is redirected to goofle.com .
So, your browser will completely legally redirect you to another site and will gladly pick up the answer for you from there. At the same time, the DNS SEC can in no way help you, and in fact there are very few opportunities to prevent this error in a completely invisible way, except for using ECC memory, which automatically recognizes and corrects bit errors.
However, this kind of memory is not very common, and even if you used ECC, there are many more places where bit squatting can happen and where ECC memory is never used, for example, in a network card or in the DRAM cache of a hard disk.
Dineberg described in detail the causes of the problem, but in general it can be said that memory errors happen, sometimes they damage the memory and sometimes it has an effect on the DNS. Basically, "turning over" a bit is due to physical memory damage, overheating, electrical problems, exposure to radiation, and even cosmic radiation.
The presentation is interrupted by the appearance on the stage of the DefCon organizers, who congratulate the speaker and his wife Linda, who is present at the conference for the first time, on the eleventh anniversary of the wedding. Robert thanks them for their congratulations and continues to speak.
Cosmic radiation is an extremely rare factor affecting bit-squatting, but overheating is a very common cause of memory errors. I noticed that smartphones are especially vulnerable due to the conditions of extreme exploitation to which they are exposed. Overheating of the smartphone battery is quite common. Most other devices have cooling, but even they manage to create harsh operating conditions.
Not so long ago, Google published information about the work of its data centers. One of the interesting things that I found out about was the message that, in order to save electricity, they exploit their data centers in conditions that most of us would consider unwise. If typical data centers operate at a maximum temperature of 60-70 degrees Fahrenheit (15-20 ° C), then Google experts recommend companies to operate data centers at a temperature of at least 80 degrees (27 ° C), and one Belgian data center Google exploited its servers at a temperature of 95 degrees (35 ° C).
The inscription on the cartoon: "I heard that it saves us money."
Intel and Microsoft claim that their servers behave well at high temperatures, and Dell guarantees the launch of their servers at 115 degrees Fahrenheit (46 ° C). I think this is a bad idea, as temperature is the main factor in ensuring stable memory performance, and Google data centers operate at “fire” temperatures.
I began to study what advantages this might give, and which domains are most vulnerable to bit-squatting, that is, I tried to find the most frequently requested names to increase the likelihood that I would encounter such errors. I started collecting the DNS logs of large companies to find the most common domain names and found out that the most requested name was gstatic.com. This is one of the domains that Google serves to provide such static information as CSS, images, JavaScript, and XML files.
I wrote a script to determine the possible "coups" of a bit in this domain name gstatic.com, and received a list of all variations of this name in the amount of 34 pieces. Five of them were used for legal purposes, the other 29 were available, so I bought them all.
I immediately hit the target. Someone was looking for images on Google and the content of the request was returned to them in some way corrupted, because his browser asked me to serve one of the pictures in the request. I see their IP address, the malformed name they requested, the resource they were trying to recover with this image, the page related to this content, and the client that was used as a browser to send this request.
On the page you can see an interesting artifact in the form of a request for a specific name Trisha Jones.
Further, the number of requests grew, more distorted names appeared, more requests for images and more references to the original request, as a result of which I collected more than 50,000 unique requests, and this, as it turned out, was a common phenomenon.
The slide shows the request for the “photo-shocked” image of actress Selena Gomez, which causes laughter in the hall.
So sometimes bit-squatting happens just at the right time to match one of your requests, and if this doesn't happen too often, you need not worry. But sometimes it happens at the very moment when it is saved to the hard disk, which is more interesting. There are chances that bit-squatting will occur under normal conditions of memory use, but it is very similar that mostly this happens in data centers with a temperature of 95 degrees.
Now my logs are full of noise, I get garbled requests every day in such quantity that I cannot view them manually.
Therefore, I am writing scripts in an attempt to find the same request patterns, and the largest one that I had was a lot of requests for the same image to the same distorted domain name, and they all came from mobile phones. I received these requests every few seconds, as all these phones tried to use the Google search page and asked me to give them a tiny picture of the original page logo.
I found one web server from the entire Google cloud, which served content and constantly distorted the domain name, pointing to one of my servers, where a logo with such a name happened to be completely random, and customers took it away.
The slide shows how the logo of the Google search page on the screen of a mobile device is replaced by the Occupy logo (Captured), which causes an approving laugh in the hall.
For two years, I have received hundreds of thousands of requests for this logo on this server with a corrupted DNS name, instead of the one that planned to use Google. Then one day they stopped, as Google refused to change the content for mobile sites, and this order was canceled.
So, I continued to study query patterns and tried to figure out other patterns. One of them appeared regularly and was obviously a natural way of “flipping a bit” in memory, and not as a result of a saved bit-squat error.
I received the requests shown on the next slide, with a frequency of one per hour. They didn’t look familiar, they all used Google’s Feedfetcher client, they all came from devices on the same network, and all requests were related to XML files. So I rummaged around a bit and found that Feedfetcher is the mechanism that Google uses to capture updated content for iGoogle, and the IP addresses of the request source were located in Belgium.
These requests are related to Google’s own servers, which are used to get updated content for various widgets that personalize the iGoogle home page, your personal Internet portal.
Each widget is an XML file that defines the content, and Google asked me to provide this content to their presentation servers (applause and laughter in the hall).
So I thought that if Google accidentally wanted content from me that it could provide to its users, it would receive it. I took the XML files that Google asked me about and split them up. As you can see, there are two sections here: a header describing the module, and a C data block, packaged in HTML CSS and JavaScript, which make up the widget.
So I just changed the link to the background image, changed the address of gstatic.com to grtatic.com, and left everything else unchanged, put the XML files in the line from where Feedfetcher takes them, and waited a bit.
Almost immediately after this, Feedfetcher requested XML files from me, after which I immediately began receiving requests from a set of Google’s IP addresses for this background image.
Therefore, I deleted the XML files that I modified and waited for requests to stop, but for 35 days in a row, 61 devices continued to ask me about this image every day. And what else is interesting, each of these devices was a Virgin Media client in the UK.
So this Google XML file served 61 people, and over the past year, 500 unique IP addresses from Feedfetcher asked me to provide these modules 15,000 times. So I could provide my users with something more malicious than a simple replacement for a background image.
Here are some more tricks you can do with Google. If you don’t know, Postini is an e-mail, web security and anti-spam email protection service that Google recently acquired.
This service allows you to change your DNS to specify your MX record in their domain and make your domain by changing the 4 MX characters in front of psmtp.com. The most interesting thing here is that the domain is so short that you can easily register all possible versions of the name with “inverted” bits. Another interesting point is that a lot of companies specify their MX records for a single domain and no one has thought that it was a bad idea.
So I registered only three possible bit squatting for this domain, and psmtp.com was so busy that the next 4 slides show requests that I received in just one month.
So if you use Postini mail, your request will come to my server at some point. I don't think anyone could say that Google is not serious about Internet security. But if someone wondered what problems may cause overheating, causing memory errors, he would be able to raise the question of considering the possibility of compensation for such things. So don't let your domain names be so short because it negatively affects your business, such as Postini, especially if your domain is popular.
I strongly recommend that people apply an internal domain name management policy to correct name misstatements, and clearly understand how such things can affect you. If you have gstatic.com and a data center operating at a temperature of 95 degrees, you probably want to make sure that any bit-squatting error will not allow the client to get to the malicious external network.
By the way, among all the domains that I investigated, the only company that registered all possible distortions of its own name was Yahoo.
In the next part of the talk, I'm going to demonstrate the behavior of the DNS, which many people do not fully understand, as it turns out.
Frankly, Microsoft did a very poor job of documenting, especially since the behavior of the DNS often changes. This leads to a misunderstanding of what is happening by end users, especially since such behavior is often contradictory.
Therefore, I will begin by saying that everyone should understand how devices should behave when requesting DNS and what to expect from them. Then I will explain how unpredictable the behavior becomes when using DNS suffix search paths, how insufficient documentation affects all of this, and end with a brief overview of the lessons that can be learned from all of this. But first, I’ll demonstrate how dangerous the end user’s misunderstanding of what is happening with DNS can be.
So, after you typed in the address bar of the browser www.google.com, your computer sends a request to a local DNS server, and the job of finding the thing you need, returning the request and answering is now assigned to it. The local server accesses the root server with a request to access the .com server, and the root server sends it to the .com server. That one checks if the local server is authorized for requests to google.com and sends it to the ns.google.com server. Finally, the local server receives a response with the IP address of the resource you need and sends it to you.
This is the normal DNS behavior that everyone expects from it. Everyone thinks that it’s enough just to send a request from the device to your local DNS server to do all the hard work, and then get an answer to your request. But not everyone imagines that this process consists of many important steps.
For example, your device is trying to find an answer on www.google.com , but this whole process, which took us as many as 8 slides, will only happen if you type in the browser’s query string exactly this address - www.google .com . This is the fully qualified domain name that is associated with root DNS. Many people believe that the full domain name ends with a period, which is incorrect. The presence of a dot at the end of the full name is still assumed, and because of this, trouble occurs. Let's try to print 4 variations of the name:
www.google.com
google.com
www
www.google.com .
each of which behaves differently with respect to DNS behavior. All this is customizable, but usually no one does it.
Let's take a look at what actually happens in these situations. There are several factors that influence decision making on the client’s side before he decides to send a DNS query. Two of them are the paths to search for the suffix and DNS devolution.
Both have many customizable parameters that affect their behavior, and behave differently in different versions of Windows and in different service packs.
This is how most people will use the search path suffix. If your company is called foo and you own the domain foo.com, and the name of the active directory is ad.foo.com, you can use the suffix of the search paths ad.foo.com or foo.com and push it into the client part of the system build or group policy.
If one of your clients tries to resolve the short name www, then Windows XP will behave by default. First, it will send a DNS query on the path www.ad.foo.com , then on the path www.foo.com and at the end a NetBIOS query will follow - just www.
If your device requests the www.phx resource , the default behavior of XP will be the first www.phx request , because it has two labels, then a www.phx.ad.foo.com request will follow , then www.phx.foo.com . Since the entire name is less than 15 bytes, an attempt will also be made to access NetBIOS, and the request will look like www.phx .
Starting with the Windows versions released after XP sp.3, all requests are reduced to the DNS look - www.phx and NetBIOS - www.phx , after which everything stops, there are no other ways.
Since most people design solutions based on expected behavior, after the usual order of things breaks down, they start the game with the registry and group security policy settings to fix compatibility issues. Thus, it turns out that Microsoft broke the DNS resolution.
Before XP, and before Microsoft changed behavior in XP, in the absence of DNS lookups, the Windows operating system used DNS resolution to look up and respond. Without a search path, if a client requests www, Windows adds only one domain that knows, it joins a specific domain that takes from DHCP or from the Active Directory directory service. If the first request was www.phx.ad.foo.com , then ascending through the domain, the request is consistently changed to www.ad.foo.com , www.foo.com , and finally, www.com and this stops everything.
18:30 min.
Conference DEFCON 21. DNS can be dangerous for your health. Part 2
Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until December for free if you pay for a period of six months, you can order here .
Dell R730xd 2 times cheaper? Only we have 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?
I am going to talk to you about a few things related to the research I have been working on for the past few years. They are united by a common theme - if you don’t monitor your DNS traffic and don’t understand what is happening there when everything is in order, then you probably don’t pay attention when bad things start happening to it. I “rape” the DNS for several years and this has always been one of my favorite attack vectors. You can spend a fortune hardening the perimeter of the network, but if I can get control of one of your devices, trust me, your game is over.
The lack of vulnerability scanners in the market that allow us to detect the wrong configurations always gives me the opportunity to "stick my foot in the door." Today we will discuss various topics in which I will talk about my adventures with the DNS and my tricks on people related to DNS.
These topics are about misunderstanding DNS behavior by end users of the network, I’ll talk a little about people who have not registered their domains, and about the domain hacking itself.
At the Black Hat and DefCon conferences in 2011, Artyom Deineberg spoke about what he called beat-squatting, or "turning the bits." Those who are not familiar with this study, but are interested in this problem in the DNS of popular domains, can download the materials of his presentation from the links on this slide.
Project Page /video presentation / slides
When I read the announcement of his speech, published before the report on Black Hat, I immediately became interested in how this can be used for my own purposes. Without going into details, I will explain what bit-squatting is, why it happens and what it affects. I will show you some examples of the risk that an accidental flipping of a bit in memory presents when 1 turns to 0 and vice versa. The following slides show how this looks like an example of a string in memory that displays a domain name.
In the middle of such a line, the unit turns to zero. Artyom investigated the phenomenon in which the error of a single bit in the correct part of the memory at the right time forced the client to request a completely legitimate, but incorrect domain name.
There was a lot of talk about the probability of the occurrence and the reasons for such an error, but I began to study all the ways that allow using this error for malicious purposes. So bit-squatting DNS allows you to distort domain names, then register these "wrong" domains and send user requests to them.
The next slide shows that, as a result of Google Squatting's bit-squatting, when a high energy proton in memory “hits” 1, meaning the letter g, turns it into 0, meaning the letter f, and as a result, the user is redirected to goofle.com .
So, your browser will completely legally redirect you to another site and will gladly pick up the answer for you from there. At the same time, the DNS SEC can in no way help you, and in fact there are very few opportunities to prevent this error in a completely invisible way, except for using ECC memory, which automatically recognizes and corrects bit errors.
However, this kind of memory is not very common, and even if you used ECC, there are many more places where bit squatting can happen and where ECC memory is never used, for example, in a network card or in the DRAM cache of a hard disk.
Dineberg described in detail the causes of the problem, but in general it can be said that memory errors happen, sometimes they damage the memory and sometimes it has an effect on the DNS. Basically, "turning over" a bit is due to physical memory damage, overheating, electrical problems, exposure to radiation, and even cosmic radiation.
The presentation is interrupted by the appearance on the stage of the DefCon organizers, who congratulate the speaker and his wife Linda, who is present at the conference for the first time, on the eleventh anniversary of the wedding. Robert thanks them for their congratulations and continues to speak.
Cosmic radiation is an extremely rare factor affecting bit-squatting, but overheating is a very common cause of memory errors. I noticed that smartphones are especially vulnerable due to the conditions of extreme exploitation to which they are exposed. Overheating of the smartphone battery is quite common. Most other devices have cooling, but even they manage to create harsh operating conditions.
Not so long ago, Google published information about the work of its data centers. One of the interesting things that I found out about was the message that, in order to save electricity, they exploit their data centers in conditions that most of us would consider unwise. If typical data centers operate at a maximum temperature of 60-70 degrees Fahrenheit (15-20 ° C), then Google experts recommend companies to operate data centers at a temperature of at least 80 degrees (27 ° C), and one Belgian data center Google exploited its servers at a temperature of 95 degrees (35 ° C).
The inscription on the cartoon: "I heard that it saves us money."
Intel and Microsoft claim that their servers behave well at high temperatures, and Dell guarantees the launch of their servers at 115 degrees Fahrenheit (46 ° C). I think this is a bad idea, as temperature is the main factor in ensuring stable memory performance, and Google data centers operate at “fire” temperatures.
I began to study what advantages this might give, and which domains are most vulnerable to bit-squatting, that is, I tried to find the most frequently requested names to increase the likelihood that I would encounter such errors. I started collecting the DNS logs of large companies to find the most common domain names and found out that the most requested name was gstatic.com. This is one of the domains that Google serves to provide such static information as CSS, images, JavaScript, and XML files.
I wrote a script to determine the possible "coups" of a bit in this domain name gstatic.com, and received a list of all variations of this name in the amount of 34 pieces. Five of them were used for legal purposes, the other 29 were available, so I bought them all.
I immediately hit the target. Someone was looking for images on Google and the content of the request was returned to them in some way corrupted, because his browser asked me to serve one of the pictures in the request. I see their IP address, the malformed name they requested, the resource they were trying to recover with this image, the page related to this content, and the client that was used as a browser to send this request.
On the page you can see an interesting artifact in the form of a request for a specific name Trisha Jones.
Further, the number of requests grew, more distorted names appeared, more requests for images and more references to the original request, as a result of which I collected more than 50,000 unique requests, and this, as it turned out, was a common phenomenon.
The slide shows the request for the “photo-shocked” image of actress Selena Gomez, which causes laughter in the hall.
So sometimes bit-squatting happens just at the right time to match one of your requests, and if this doesn't happen too often, you need not worry. But sometimes it happens at the very moment when it is saved to the hard disk, which is more interesting. There are chances that bit-squatting will occur under normal conditions of memory use, but it is very similar that mostly this happens in data centers with a temperature of 95 degrees.
Now my logs are full of noise, I get garbled requests every day in such quantity that I cannot view them manually.
Therefore, I am writing scripts in an attempt to find the same request patterns, and the largest one that I had was a lot of requests for the same image to the same distorted domain name, and they all came from mobile phones. I received these requests every few seconds, as all these phones tried to use the Google search page and asked me to give them a tiny picture of the original page logo.
I found one web server from the entire Google cloud, which served content and constantly distorted the domain name, pointing to one of my servers, where a logo with such a name happened to be completely random, and customers took it away.
The slide shows how the logo of the Google search page on the screen of a mobile device is replaced by the Occupy logo (Captured), which causes an approving laugh in the hall.
For two years, I have received hundreds of thousands of requests for this logo on this server with a corrupted DNS name, instead of the one that planned to use Google. Then one day they stopped, as Google refused to change the content for mobile sites, and this order was canceled.
So, I continued to study query patterns and tried to figure out other patterns. One of them appeared regularly and was obviously a natural way of “flipping a bit” in memory, and not as a result of a saved bit-squat error.
I received the requests shown on the next slide, with a frequency of one per hour. They didn’t look familiar, they all used Google’s Feedfetcher client, they all came from devices on the same network, and all requests were related to XML files. So I rummaged around a bit and found that Feedfetcher is the mechanism that Google uses to capture updated content for iGoogle, and the IP addresses of the request source were located in Belgium.
These requests are related to Google’s own servers, which are used to get updated content for various widgets that personalize the iGoogle home page, your personal Internet portal.
Each widget is an XML file that defines the content, and Google asked me to provide this content to their presentation servers (applause and laughter in the hall).
So I thought that if Google accidentally wanted content from me that it could provide to its users, it would receive it. I took the XML files that Google asked me about and split them up. As you can see, there are two sections here: a header describing the module, and a C data block, packaged in HTML CSS and JavaScript, which make up the widget.
So I just changed the link to the background image, changed the address of gstatic.com to grtatic.com, and left everything else unchanged, put the XML files in the line from where Feedfetcher takes them, and waited a bit.
Almost immediately after this, Feedfetcher requested XML files from me, after which I immediately began receiving requests from a set of Google’s IP addresses for this background image.
Therefore, I deleted the XML files that I modified and waited for requests to stop, but for 35 days in a row, 61 devices continued to ask me about this image every day. And what else is interesting, each of these devices was a Virgin Media client in the UK.
So this Google XML file served 61 people, and over the past year, 500 unique IP addresses from Feedfetcher asked me to provide these modules 15,000 times. So I could provide my users with something more malicious than a simple replacement for a background image.
Here are some more tricks you can do with Google. If you don’t know, Postini is an e-mail, web security and anti-spam email protection service that Google recently acquired.
This service allows you to change your DNS to specify your MX record in their domain and make your domain by changing the 4 MX characters in front of psmtp.com. The most interesting thing here is that the domain is so short that you can easily register all possible versions of the name with “inverted” bits. Another interesting point is that a lot of companies specify their MX records for a single domain and no one has thought that it was a bad idea.
So I registered only three possible bit squatting for this domain, and psmtp.com was so busy that the next 4 slides show requests that I received in just one month.
So if you use Postini mail, your request will come to my server at some point. I don't think anyone could say that Google is not serious about Internet security. But if someone wondered what problems may cause overheating, causing memory errors, he would be able to raise the question of considering the possibility of compensation for such things. So don't let your domain names be so short because it negatively affects your business, such as Postini, especially if your domain is popular.
I strongly recommend that people apply an internal domain name management policy to correct name misstatements, and clearly understand how such things can affect you. If you have gstatic.com and a data center operating at a temperature of 95 degrees, you probably want to make sure that any bit-squatting error will not allow the client to get to the malicious external network.
By the way, among all the domains that I investigated, the only company that registered all possible distortions of its own name was Yahoo.
In the next part of the talk, I'm going to demonstrate the behavior of the DNS, which many people do not fully understand, as it turns out.
Frankly, Microsoft did a very poor job of documenting, especially since the behavior of the DNS often changes. This leads to a misunderstanding of what is happening by end users, especially since such behavior is often contradictory.
Therefore, I will begin by saying that everyone should understand how devices should behave when requesting DNS and what to expect from them. Then I will explain how unpredictable the behavior becomes when using DNS suffix search paths, how insufficient documentation affects all of this, and end with a brief overview of the lessons that can be learned from all of this. But first, I’ll demonstrate how dangerous the end user’s misunderstanding of what is happening with DNS can be.
So, after you typed in the address bar of the browser www.google.com, your computer sends a request to a local DNS server, and the job of finding the thing you need, returning the request and answering is now assigned to it. The local server accesses the root server with a request to access the .com server, and the root server sends it to the .com server. That one checks if the local server is authorized for requests to google.com and sends it to the ns.google.com server. Finally, the local server receives a response with the IP address of the resource you need and sends it to you.
This is the normal DNS behavior that everyone expects from it. Everyone thinks that it’s enough just to send a request from the device to your local DNS server to do all the hard work, and then get an answer to your request. But not everyone imagines that this process consists of many important steps.
For example, your device is trying to find an answer on www.google.com , but this whole process, which took us as many as 8 slides, will only happen if you type in the browser’s query string exactly this address - www.google .com . This is the fully qualified domain name that is associated with root DNS. Many people believe that the full domain name ends with a period, which is incorrect. The presence of a dot at the end of the full name is still assumed, and because of this, trouble occurs. Let's try to print 4 variations of the name:
www.google.com
google.com
www
www.google.com .
each of which behaves differently with respect to DNS behavior. All this is customizable, but usually no one does it.
Let's take a look at what actually happens in these situations. There are several factors that influence decision making on the client’s side before he decides to send a DNS query. Two of them are the paths to search for the suffix and DNS devolution.
Both have many customizable parameters that affect their behavior, and behave differently in different versions of Windows and in different service packs.
This is how most people will use the search path suffix. If your company is called foo and you own the domain foo.com, and the name of the active directory is ad.foo.com, you can use the suffix of the search paths ad.foo.com or foo.com and push it into the client part of the system build or group policy.
If one of your clients tries to resolve the short name www, then Windows XP will behave by default. First, it will send a DNS query on the path www.ad.foo.com , then on the path www.foo.com and at the end a NetBIOS query will follow - just www.
If your device requests the www.phx resource , the default behavior of XP will be the first www.phx request , because it has two labels, then a www.phx.ad.foo.com request will follow , then www.phx.foo.com . Since the entire name is less than 15 bytes, an attempt will also be made to access NetBIOS, and the request will look like www.phx .
Starting with the Windows versions released after XP sp.3, all requests are reduced to the DNS look - www.phx and NetBIOS - www.phx , after which everything stops, there are no other ways.
Since most people design solutions based on expected behavior, after the usual order of things breaks down, they start the game with the registry and group security policy settings to fix compatibility issues. Thus, it turns out that Microsoft broke the DNS resolution.
Before XP, and before Microsoft changed behavior in XP, in the absence of DNS lookups, the Windows operating system used DNS resolution to look up and respond. Without a search path, if a client requests www, Windows adds only one domain that knows, it joins a specific domain that takes from DHCP or from the Active Directory directory service. If the first request was www.phx.ad.foo.com , then ascending through the domain, the request is consistently changed to www.ad.foo.com , www.foo.com , and finally, www.com and this stops everything.
18:30 min.
Conference DEFCON 21. DNS can be dangerous for your health. Part 2
Thank you for staying with us. Do you like our articles? Want to see more interesting materials? Support us by placing an order or recommending to friends, 30% discount for Habr users on a unique analogue of the entry-level servers that we invented for you: The whole truth about VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps from $ 20 or how to share the server? (Options are available with RAID1 and RAID10, up to 24 cores and up to 40GB DDR4).
VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps until December for free if you pay for a period of six months, you can order here .
Dell R730xd 2 times cheaper? Only we have 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV from $ 249in the Netherlands and the USA! Read about How to build an infrastructure building. class c using servers Dell R730xd E5-2650 v4 worth 9000 euros for a penny?