The core work of DNS is to translate domain names into computer IP addresses. It is implemented based on the UDP protocol. This article will elaborate on all DNS-related knowledge points such as DNS-related concepts, resolution, and scheduling principles (load balancing and area scheduling). @pdai
Introduction to DNS
The domain name system is not as simple as the phone number address book. The address book is mainly used by a single individual. There is no problem if the same name appears in the address book of different individuals, but the domain name is used by everyone in the group. Must be unique. In order to achieve the purpose of uniqueness, the Internet adopts a hierarchical naming method when naming. Each domain name (this article only discusses English domain names) is a label sequence (labels), composed of letters (AZ, az, upper and lower case equivalent), numbers (0-9) and connectors (-), the total length of the label sequence It cannot exceed 255 characters. It is divided into labels by dots. Each label should be within 63 characters. Each label can be regarded as a hierarchical domain name. The lowest-level domains are written on the left, and the highest-level domains are written on the right. The domain name service is mainly implemented based on UDP, and the port number of the server is 53.
Domain Hierarchy
Note: The first domain names are all marked with a dot at the end, such aswww.kernel.org.. The dot at the end indicates the root domain name server. Later, it was found that all URLs must be added with the last dot, which is simplified. In the way of writing, simply do not add all thewww.kernel.org, but you can also parse it normally if you add a dot after the URL.
domain name server
It is not enough to have a domain name structure. There is also something to resolve the domain name. The mobile phone address book is resolved by the address book software, and the domain name needs to be resolved by the domain name server all over the world. The domain name server is actually the host with the domain name system. Hierarchical division from high to low can be divided into the following categories:
- Root domain name server : The highest-level domain name server is also the most important domain name server. If the local domain name server cannot resolve the domain name, it will turn to the root domain name server for help. There are 13 root domain name servers with different IP addresses in the world, and their names are named with an English letter, from a to m. These servers are controlled by various organizations and authorized by ICANN (Internet Corporation for Assigned Names and Numbers), due to the incredible number of names being resolved every minute, there are mirror servers for virtually every root server, Each root server shares the same IP address with its mirror server, and there are only 6 groups of root server mirrors (F, I (3 sets), J, L) in mainland China. When you make a request to a root server, the request is routed to the mirror server closest to you for that root server. All root nameservers know the domain names and addresses of all top-level nameservers, if a request is made to the root server for "pdai.tech", the root server will not be able to find a match for "pdai.tech" in its log file record of. But it will find the TLD record for "tech" and send back to the requester the address of the TLD server responsible for the "tech" address.
- Top-level domain name server : Responsible for managing the second-level domain names registered under the top-level domain name server. When the root domain name server tells the queryer the address of the top-level domain name server, the queryer will then go to the top-level domain name server to query. For example, if you still query "pdai.tech", the root domain name server has already told the queryer the address of the "tech" top-level domain name server, the "tech" top-level domain name server will find the record of the "pdai.tech" domain name server, and the domain name server will check its area. file and found that it had a zone file associated with "pdai.tech". Inside this file, there is a record for this host. This record describes the IP address where this host is located and returns the final answer to the requester.
- Authority Domain Name Server : Responsible for domain name resolution in a zone
- Local domain name server : When a host sends a DNS query request, the query request is first sent to the local domain name server.
DNS resolution process
I found a good example online
The steps of DNS resolution of .com.fi international financial domain name are divided into 9 steps. If each resolution has to go through 9 steps, the speed of browsing the website will not be so fast. The reason why we can maintain such a fast access speed now , In fact, the general analysis is to run through the fourth step on it. Unless a region is completely accessed for the first time (in the case of no cache), it will go through 9 steps, which is rarely the case.
- 1. The local client sends a domain name resolution request, finds the local HOST file, and sends the request to the local domain name server.
- 2. Send the request to the local domain name server.
- 3. When the local domain name server receives the request, it first queries the local cache.
- 4. If there is this record item, the local domain name server will directly return the query result to the browser.
- 5. If there is no such record in the local DNS cache, the local domain name server will directly send the request to the root domain name server.
- 6. The root domain name server then returns the address of the primary domain name server of the queried domain (subdomain of the root) to the local domain name server.
- 7. The local server sends a request to the domain name server returned in the previous step, and then the server that accepts the request queries its own cache. If there is no such record, it returns the address of the relevant lower-level domain name server.
- 8. Repeat step 7 until the correct record is found.
- 9. The local domain name server saves the returned result to the cache for next use, and returns the result to the client at the same time.
Precautions:
Recursive query : In this mode, the DNS server receives a client request and must reply to the client with an accurate query result. If the DNS server does not store query DNS information locally, the server will query other servers and submit the returned query result to the client.
Iterative query : If the server where the DNS is located has no results that can be responded, it will provide the client with the address of other DNS servers that can resolve the query request. When the client sends a query request, the DNS server does not directly reply to the query result, but tells the client. Another DNS server address, the client submits a request to this DNS server, and loops in turn until the query result is returned.
Why DNS is usually based on UDP
Using UDP-based DNS protocol requires only one request and one response
Using the TCP-based DNS protocol requires three handshakes, sending data and responding, and waving four times.
Obviously, DNS based on TCP protocol wastes more network resources!
Of course, the above is only an analysis based on the number of data packets and the level of network resources occupied. What about the level of data consistency?
DNS data packets are not that kind of large data packets, so using UDP does not need to consider sub-packaging. If packets are lost, all packets are lost. If data is received, all data are received! So you only need to consider the case of packet loss, even if the packet is lost, just re-request it once. And the DNS message allows filling in the sequence number field. For the request message and its corresponding response message, this field is the same, and it can be used to distinguish which request the DNS response corresponds to.
DNS is usually based on UDP, but when the data length is greater than 512 bytes, in order to ensure the transmission quality, a TCP-based implementation will be used
DNS query
dig query
Use dig to view the whole process, and you can understand it by looking at the following return- dig www.sina.com
pdaiMbp:/ pdai$ dig www.sina.com
; <<>> DiG 9.10.6 <<>> www.sina.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15304
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.sina.com. IN A
;; ANSWER SECTION:
www.sina.com. 32 IN CNAME us.sina.com.cn.
us.sina.com.cn. 32 IN CNAME spool.grid.sinaedge.com.
spool.grid.sinaedge.com. 32 IN A 115.238.190.240
;; Query time: 20 msec
;; SERVER: 192.168.3.1#53(192.168.3.1)
;; WHEN: Fri Jan 31 14:53:39 CST 2020
;; MSG SIZE rcvd: 108- dig +trace www.sina.com // Hierarchical query
pdaiMbp:/ pdai$ dig +trace www.sina.com
; <<>> DiG 9.10.6 <<>> +trace www.sina.com
;; global options: +cmd
. 52722 IN NS f.root-servers.net.
. 52722 IN NS k.root-servers.net.
. 52722 IN NS m.root-servers.net.
. 52722 IN NS l.root-servers.net.
. 52722 IN NS d.root-servers.net.
. 52722 IN NS i.root-servers.net.
. 52722 IN NS c.root-servers.net.
. 52722 IN NS e.root-servers.net.
. 52722 IN NS a.root-servers.net.
. 52722 IN NS g.root-servers.net.
. 52722 IN NS b.root-servers.net.
. 52722 IN NS h.root-servers.net.
. 52722 IN NS j.root-servers.net.
;; Received 228 bytes from 192.168.3.1#53(192.168.3.1) in 3 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20200213050000 20200131040000 33853 . zMeZpKg/LGzpVjlBUJRfkmk8tSvZW+L0UFHnzSn8agztJ8sMGU+knBLW 5LLoPoh6iG7exLV5wVIJZVh+0ISk3AG85VJXZ3HSTWcHZfjMOYI7JXpe pv/5JqT9Eai0ScEJAowDa1qctGOE/LHdNwr30VF8U0LoZL0iXVN3KQ4k iKnl0S0hB41KH+BHFcNpWqxKHRK2piMZRNe8+8Nu9I4GilfW/D90e69p SgG7puU3J3srarhccj0OS5WcLi6nsMf/2k0C6rQMe+WD7aOVZXoLts93 /thoNSWIprseKrYze2STnuG+T/VxzZRJ3fjoZARGHtDf3gTibHC2syXL xaXz5w==
;; Received 1172 bytes from 198.97.190.53#53(h.root-servers.net) in 54 ms
sina.com. 172800 IN NS ns1.sina.com.cn.
sina.com. 172800 IN NS ns2.sina.com.cn.
sina.com. 172800 IN NS ns3.sina.com.cn.
sina.com. 172800 IN NS ns1.sina.com.
sina.com. 172800 IN NS ns2.sina.com.
sina.com. 172800 IN NS ns4.sina.com.
sina.com. 172800 IN NS ns3.sina.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200207054811 20200131043811 56311 com. N15f7ia8A0pd2A5iWM/8t+T6gs8mQJaOWe/aj3bs4cWxpG7WmCaquZp7 6gfbfotFmss+DuBm9MAd6bwe2fm9m60FQgROWGOZwGRrvZqawy/5eDeV sLIJqhnwM0lT1PuDgNe2SFYsV506melwC4cEtR8M6gkX3nwYMCf6Frus anO+4Lufi229N5Y00N4x9vrlO3zsGBR1yg2xBki9Ni379A==
TGAG8VMC6NS5VVK68CIGRJ6Q414N2KB2.com. 86400 IN NSEC3 1 1 0 - TGAGRAEN3DVBS761O1PSQ1TU0407EVHO NS DS RRSIG
TGAG8VMC6NS5VVK68CIGRJ6Q414N2KB2.com. 86400 IN RRSIG NSEC3 8 2 86400 20200206061700 20200130050700 56311 com. TMrk1/56Wa+isS5Y6OFQz9OZWMAAbt2TOEzaBp1Uuj9z1Eg4uio92+ff sWRB6vACYSBAJJLy4NPJfqxYpue39hvaDgFRYAZreDuCC0x+p9yi7yQ8 JaN2mS7W8Mbv0iEV0AUyzZGyhYq83DA58slNSGRhZfcvLYBAETURyH0X bJp+Hgq0bqXOqGyi/lAAv8/2mr+tiramb/pNst1MBBPaig==
;; Received 791 bytes from 192.48.79.30#53(j.gtld-servers.net) in 215 ms
www.sina.com. 60 IN CNAME us.sina.com.cn.
us.sina.com.cn. 60 IN CNAME spool.grid.sinaedge.com.
;; Received 103 bytes from 180.149.138.199#53(ns2.sina.com.cn) in 30 msThe correspondence between domain names and IPs is called a "record". According to the usage scenario, "records" can be divided into different types (types), as we have seen earlier, there are A records and NS records.
Common DNS record types are as follows.
- A : Address record (Address), which returns the IP address pointed to by the domain name.
- NS : Domain name server record (Name Server), returns the server address that saves the next-level domain name information. This record can only be set to a domain name, not an IP address.
- MX : Mail record (Mail eXchange), returns the server address that receives email.
- CNAME : Canonical Name record, returns another domain name, that is, the domain name currently queried is a jump of another domain name, see below for details.
- PTR : Pointer Record, only used to query domain names from IP addresses, see below for details.
Generally speaking, for the safety and reliability of the service, there should be at least two NS records, and there can also be multiple A records and MX records, which provides redundancy of the service and prevents a single point of failure.
CNAME records are mainly used for internal redirection of domain names, providing flexibility for server configuration, and users cannot perceive them.
host query
pdaiMbp:/ pdai$ host www.sina.com
www.sina.com is an alias for us.sina.com.cn.
us.sina.com.cn is an alias for spool.grid.sinaedge.com.
spool.grid.sinaedge.com has address 115.238.190.240
spool.grid.sinaedge.com has IPv6 address 240e:f7:a000:221::75:71nslookup query
pdaiMbp:/ pdai$ nslookup
> www.sina.com
Server: 192.168.3.1
Address: 192.168.3.1#53
Non-authoritative answer:
www.sina.com canonical name = us.sina.com.cn.
us.sina.com.cn canonical name = spool.grid.sinaedge.com.
Name: spool.grid.sinaedge.com
Address: 115.238.190.240whois query
pdaiMbp:/ pdai$ whois www.sina.com
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
refer: whois.verisign-grs.com
domain: COM
organisation: VeriSign Global Registry Services
address: 12061 Bluemont Way
address: Reston Virginia 20190
address: United States
contact: administrative
name: Registry Customer Service
organisation: VeriSign Global Registry Services
address: 12061 Bluemont Way
address: Reston Virginia 20190
address: United States
phone: +1 703 925-6999
fax-no: +1 703 948 3978
e-mail: info@verisign-grs.com
contact: technical
name: Registry Customer Service
organisation: VeriSign Global Registry Services
address: 12061 Bluemont Way
address: Reston Virginia 20190
address: United States
phone: +1 703 925-6999
fax-no: +1 703 948 3978
e-mail: info@verisign-grs.com
nserver: A.GTLD-SERVERS.NET 192.5.6.30 2001:503:a83e:0:0:0:2:30
nserver: B.GTLD-SERVERS.NET 192.33.14.30 2001:503:231d:0:0:0:2:30
nserver: C.GTLD-SERVERS.NET 192.26.92.30 2001:503:83eb:0:0:0:0:30
nserver: D.GTLD-SERVERS.NET 192.31.80.30 2001:500:856e:0:0:0:0:30
nserver: E.GTLD-SERVERS.NET 192.12.94.30 2001:502:1ca1:0:0:0:0:30
nserver: F.GTLD-SERVERS.NET 192.35.51.30 2001:503:d414:0:0:0:0:30
nserver: G.GTLD-SERVERS.NET 192.42.93.30 2001:503:eea3:0:0:0:0:30
nserver: H.GTLD-SERVERS.NET 192.54.112.30 2001:502:8cc:0:0:0:0:30
nserver: I.GTLD-SERVERS.NET 192.43.172.30 2001:503:39c1:0:0:0:0:30
nserver: J.GTLD-SERVERS.NET 192.48.79.30 2001:502:7094:0:0:0:0:30
nserver: K.GTLD-SERVERS.NET 192.52.178.30 2001:503:d2d:0:0:0:0:30
nserver: L.GTLD-SERVERS.NET 192.41.162.30 2001:500:d937:0:0:0:0:30
nserver: M.GTLD-SERVERS.NET 192.55.83.30 2001:501:b1f9:0:0:0:0:30
ds-rdata: 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CFC41A5766
whois: whois.verisign-grs.com
status: ACTIVE
remarks: Registration information: http://www.verisigninc.com
created: 1985-01-01
changed: 2017-10-05
source: IANA
No match for domain "WWW.SINA.COM".
>>> Last update of whois database: 2020-01-31T07:03:29Z <<<Online tool query
https://www.nslookuptool.com/chs/
DNS scheduling principle
This section is transferred from: [NetEase MC] DNS scheduling principle analysis
Now, most applications and businesses use domain names as service entry points, so it is very common to use DNS for load balancing and regional scheduling. NetEase Cloud also has a DNS-based scheduling system. Some users do not use NetEase Cloud's live streaming SDK, but some third-party streaming software, such as obs, for live streaming, so they cannot use our GSLB global scheduling server for scheduling. For these users, we use DNS scheduling to return different resolution results for requests from different regions, and schedule requests to the server node closest to the user, thereby reducing delayed access.
At first glance, DNS scheduling is so simple and convenient, so why not let all users go through DNS scheduling? Wondering why? Come, let's continue.
Inaccurate geolocation scheduling
In the DNS resolution process, only the DNS cache server communicates with the authoritative server, so the authoritative server can only schedule according to the IP of the DNS cache server. Therefore, DNS scheduling has a premise: assuming that the cache DNS used by the user is in the same network as the user itself, that is, at least in the same AS (autonomous domain), under this premise, DNS resolution is accurate. Usually, the user uses the local cache provided by the ISP (local DNS for short), and the local DNS is generally in the same network as the user. At this time, DNS scheduling is effective.
However, in recent years, many Internet manufacturers have promoted BGP Anycast-based public DNS (Public DNS), and these Anycaset IP nodes are generally far less than those of various ISPs. For example, Guangzhou Telecom users may use a certain public DNS, but this The closest user in the public DNS is the Shanghai Telecom node, or even more extreme such as Google DNS 8.8.8.8, there is no node in mainland China (the nearest is Taiwan). Unfortunately, many users in China use Google DNS, which actually reduces their network access experience. In general, the use of public DNS actually destroys the above premise, resulting in the failure of DNS zone scheduling. Users think that they get faster and safer DNS resolution, but they actually get wrong resolution, which increases network access delay .
An example of the area scheduling process of the traditional DNS protocol is shown in the figure below. Suppose a business provides services to the outside world as foo.163.com, with one node in Beijing and one in Tokyo. The business expects domestic users from mainland China to visit the Beijing node, while non-mainland users visit Tokyo. node. Because the authority is based on the DNS cache to determine the returned results, so when users use a different DNS cache, may resolve to different results.
In 2011, several companies led by Google proposed a DNS extension scheme, edns-client-subnet (hereinafter referred to as ECS). IP), so that the authority can return the correct result based on this information. Currently, the program is still in the draft stage. This solution solves the problem of inaccurate resolution caused by remote DNS mentioned above, but it also brings some problems:
- At least both cache and authoritative support are required to complete complete ECS parsing
- ECS adds a lot of cache pressure to the cache, because theoretically it may be necessary to allocate space for each IP segment to cache the parsing results
Uncertain when the rule change will take effect
When the cache server queries the authoritative server to obtain the record, it will cache it. During the validity period of the cache, if it receives a query of the same record, the cache server will directly return it to the client without the need to query the authoritative server again. , the cache needs to initiate the query again. This cache validity period is the TTL.
While DNS's caching mechanism shortens the client's record resolution time in most cases, caching also means a delay in effective synchronization. When the records of the authoritative server change, it takes a while for all clients to resolve the new results, because it is likely that the cache server is still caching the old records.
The process of changing authoritative records to take effect on the entire network is called propagation. Its time is uncertain. The theoretical maximum value is the value of TTL. For record changes or deletions, this time is the original TTL of the record. The new record is the nTTL value of the domain.
If the original TTL of a domain name record is 18000, it can be considered that changing the record theoretically takes 5 hours to ensure that the record can take effect on the entire network. Assuming that the business side of the domain name wants to shorten the switching time, the correct way is to modify the record at least 5 hours in advance, and only change a small TTL, such as 5 minutes, wait for the change to be synchronized to the entire network, and then modify the pointed Operation, confirm that it is correct, and then modify the TTL to the original value.
Although the DNS protocol standard suggests that the cache server should remember or shorten the TTL value, in fact, some DNS caches will modify the TTL of the authoritative server and make it larger, which is very common among several major domestic operators. For example, the TTL value of a domain record is actually set to 60, but in the operator's DNS cache, it becomes a value of 600 or more, and even some DNS caches do not follow the TTL mechanism. These will affect the actual effective time of the domain name.
High availability
To avoid being affected by DNS caching, it is necessary to ensure high availability of IP nodes with A records in DNS. In this regard, the solution adopted by NetEase Cloud DNS scheduling system is to perform load balancing among multiple live server nodes in the same area, and only expose one virtual IP to the outside world. Troubleshoot the faulty node, and for DNS, because the virtual IP remains unchanged.
DNS security related
Part of this chapter is referenced from: OneAPM blog
Criminals will exploit vulnerabilities in any Internet service or protocol, including the Domain Name System (DNS) of course. They register one-off domains for spam campaigns and botnet management, as well as steal domains for phishing and malware downloads. They inject malicious query code to exploit vulnerabilities in nameservers or disrupt the name resolution process. They can inject fake responses to pollute the parser cache or harden DDOS attacks. They even use DNS as a covert channel for data exfiltration or malware updates.
You may not be able to learn about every new DNS exploit, but you can use firewalls, network intrusion detection systems, or domain name resolvers to report signs of suspicious DNS behavior as a proactive measure.
Let’s talk about the most commonly used methods first: DNS劫持 and DNS污染 .
What is DNS Hijacking
DNS hijacking refers to hijacking the DNS server, obtaining control of the resolution record of a domain name by some means, and then modifying the resolution result of the domain name, resulting in the transfer of the access to the domain name from the original IP address to the modified designated IP. The result is that specific URLs cannot be accessed or are fake URLs, so as to achieve the purpose of stealing data or destroying original normal services. DNS hijacking works by tampering with the data on the DNS server to return a wrong query result to the user.
Symptoms of DNS hijacking: After users in some regions successfully connect to broadband, they open any page for the first time and point to content pages such as "Telecom Megastar" and "Netcom Yellow Pages Ads" provided by ISPs. There is also a Baidu website that appears when a user visits a Google domain name. These are all DNS hijacking.
What is DNS Pollution
DNS pollution is a method that makes ordinary users unable to communicate with them because they get fake target host IPs. It is a DNS cache poisoning attack (DNS cache poisoning). The way it works is: because the usual DNS query does not have any authentication mechanism, and the DNS query is usually based on UDP, which is a connectionless and unreliable protocol, so the DNS query is very easy to be tampered with, by hacking the DNS query on UDP port 53. Detection, once a request matching the keyword is found, it will immediately pretend to be the resolution server (NS, Name Server) of the target domain name and return false results to the queryer.
DNS pollution occurs in the first step of user requests, directly interfering with the user's DNS requests from the protocol.
Symptoms of DNS pollution : At present, many websites that are banned from accessing are achieved through DNS pollution, such as YouTube, Facebook and other websites.
Workaround :
- For DNS hijacking, it can be solved by using free public DNS servers abroad. For example OpenDNS (208.67.222.222) or GoogleDNS (8.8.8.8).
- For DNS pollution, it can be said that it is difficult for individual users to solve the problem only by setting. Usually, VPN or remote domain name resolution can be used to solve the problem, but most of this requires the purchase of paid VPN or SSH, etc., or it can be manually set by modifying the Hosts method. The correct IP address for the domain name.
Why DNS Traffic Monitoring
A combination of DNS queries or traffic signatures that indicate suspicious or malicious code is occurring on the network. E.g:
- 1. DNS queries from forged source addresses, or DNS queries with unauthorized use and no egress filter addresses, if abnormally large DNS query volume is observed at the same time, or DNS queries are performed using TCP instead of UDP, this may indicate that there is a compromised network in the network. Infected host, under DDoS attack.
- 2. An abnormal DNS query may be a sign of an exploit against a domain name server or resolver (as determined by the target IP address). At the same time, these queries may also indicate a malfunctioning device on the network. The cause may be malware or unsuccessful malware removal.
- 3. In many cases, DNS queries require resolution of domain names that are known to be malicious, or have common characteristics of Domain Name Generation Algorithms (DGA) (related to illegal botnets), or are sent to resolvers for unauthorized use The query is strong evidence to prove the existence of the infected host in the network.
- 4. DNS responses can also reveal signs of suspicious or malicious data spreading between network hosts. For example, the length or combined characteristics of DNS responses can reveal malicious or illegal behavior. For example, the response message is unusually large (amplification attack), or the Answer Section or Additional Section of the response message is very suspicious (cache pollution, covert channel).
- 5. A DNS response for its own domain name combination, if it resolves to an IP address different from the one you publish in the authoritative zone, or a response from a domain name server that is not an authoritative zone host, or resolves to a hostname for the zone with the wrong name ( NXDOMAIN ) A positive response indicates that the domain name or registered account may have been hijacked or the DNS response has been tampered with.
- 6. DNS responses from suspicious IP addresses, such as from addresses assigned to IP segments of the broadband access network, DNS traffic present on non-standard ports, unusually large numbers of response messages that resolve to short time-to-live (TTL) domain names, or unusual A large number of response messages containing "name error" ( NXDOMAIN ) are often the manifestation of the host being controlled by a botnet, running malware, or being infected.
DNS traffic monitoring
How can these mechanisms be applied on network firewalls to detect such threats with the help of network intrusion detection systems, traffic analysis and log data?
firewall
Let's start with the most commonly used security system, the firewall. All firewalls allow custom rules to prevent IP address spoofing. Add a rule to deny DNS queries from IP addresses outside the specified range, thereby preventing the DNS resolver from being used as an open reflector by DDOS attacks.
Next, enable DNS traffic inspection to detect suspicious byte patterns or abnormal DNS traffic to prevent domain name server software exploits. Introductions to common firewalls with this feature can be found on many websites (eg Palo Alto, Cisco, WatchGuard, etc.). Sonicwall and Palo Alto can also monitor and block specific DNS tunnel traffic.
Intrusion Detection System
Whether you use Snort, Suricata, or OSSEC, you can create rules that require the system to report DNS requests from unauthorized clients. You can also create rules to count or report NXDomain responses, responses containing records with small TTL values, DNS queries initiated over TCP, DNS queries on non-standard ports, and suspicious large-scale DNS responses, etc. Any field, any value in a DNS query or response message is basically "detectable". The only thing that limits you is your imagination and familiarity with DNS. Firewall's IDS (Intrusion Detection System) provides both allow and deny configuration rules for most common detection items.
Traffic Analysis Tool
Both Wireshark and Bro have demonstrated that passive traffic analysis is effective in identifying malware traffic. Capture and filter DNS data between clients and resolvers as PCAP (Network Packet) files. Create a script to search these network packets for some kind of suspicious behavior you are investigating. Or use PacketQ (originally DNS2DB) to do direct SQL queries on network packets.
(Remember: clients are prohibited from using any other resolvers or non-standard ports than their own local resolvers.)
DNS passive replication
The method involves using sensors on resolvers to create a database of all DNS transactions (queries/responses) that go through a given resolver or resolver group. Including DNS passive data in the analysis is important for identifying malware domains, especially if the malware uses an algorithmically generated domain name. Palo Alto's firewall and security management system, which uses Suricata as an IDS (intrusion detection system) engine, is an example of a security system that uses a combination of passive DNS and IPS (intrusion prevention system) to defend against known malicious domains.
Parser logging
The local resolver's log files are the last item to investigate DNS traffic, and probably the most obvious source of data. With logging turned on, you can use tools like Splunk plus getwatchlist or OSSEC to collect DNS server logs and search for known malicious domains.
Although this article mentions a lot of information links, case studies and practical examples, it only involves a drop in the number of methods for monitoring DNS traffic, and omissions are inevitable. If you want to monitor DNS traffic comprehensively, quickly, and effectively, try DNS server monitoring. .
DNS server monitoring
Application Manager provides comprehensive in-depth availability and performance monitoring of the Domain Name System (DNS), as well as monitoring individual DNS monitor properties such as response time, record type, available records, search fields, search values, search value status, and search time etc.
Some key components monitored in DNS:
| index | describe |
|---|---|
| Response time | give the response time of the DNS monitor in milliseconds |
| record type | Displays the time it takes for the record type to connect to the DNS server |
| Available records | Output True or False depending on available record types |
| search field | Displays the field type used for DNS servers |
| search value | Displays the search value performed in the DNS server |
| search value status | Displays the search value status according to the output: Success or Failed |
| search time | Search execution time in DNS server |
监控可用性 and 响应时间 and other performance statistics. This data can be charted and reported out-of-the-box into performance graphs and reports grouped by usability and sophistication.
In the event of a problem with the DNS server or any specific attribute within the system, notifications and warnings are generated based on configured thresholds, and actions are automatically performed as configured. At present, DNS monitoring tools at home and abroad mainly include New relic, appDynamic, and OneAPM.
Reference article
- 【NetEase MC】Analysis of DNS scheduling principle
- Getting Started with DNS Principles
- DNS principle and its resolution process [Wonderful Analysis]
- What do we talk about when we talk about networking (2) -- how DNS works
- How can businesses defend against malware that exploits DNS tunneling?
- Five tips for monitoring DNS traffic and preventing security risks!
- Detailed explanation of DNS protocol and analysis of message format
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。