document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-02-03 23:40:14 +08:00
Code Issues Packages Projects Releases Wiki Activity

TSL&PRF

Browse Source
This commit is contained in:
Xingyu Wang 2020-08-02 01:00:43 +08:00
parent 8c6e15af59
commit 365300f0b7
2 changed files with 227 additions and 235 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

235
sources/tech/20200728 Digging for DNS answers on Linux.md
View File

@ -1,235 +0,0 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Digging for DNS answers on Linux)
[#]: via: (https://www.networkworld.com/article/3568488/digging-for-dns-answers-on-linux.html)
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
Digging for DNS answers on Linux
======
Dig is a powerful and flexible tool for interrogating domain name system (DNS) servers. In this post, we’ll take a deep dive into how it works and what it can tell you.
[Laurie Avocado][1] [(CC BY 2.0)][2]
Dig is a powerful and flexible tool for interrogating DNS name servers. It performs DNS lookups and displays the answers that are returned from the name servers that were involved in the process along with details related to the search. System and [DNS][3] administrators often use **dig** to help troubleshoot DNS problems. In this post, we’ll take a deep dive into how it works and see what it can tell us.
To get started, it's helpful to have a good mental image of how DNS or domain name system works. It's a critical part of the global Internet because it provides a way to look up and, thereby, connect with servers around the world. You can think of it as the Internet's address book and any system that is properly connected to the Internet should be able to use it to look up the IP address of any properly registered server.
### Getting started with dig
The **dig** tool is generally installed on Linux systems by default. Here’s an example of a **dig** command with a little annotation:
```
$ dig www.networkworld.com
; <<>> DiG 9.16.1-Ubuntu <<>> www.networkworld.com <== version of dig you’re using
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6034
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION: <== details on your query
;www.networkworld.com. IN A
;; ANSWER SECTION: <== results
www.networkworld.com. 3568 IN CNAME idg.map.fastly.net.
idg.map.fastly.net. 30 IN A 151.101.250.165
;; Query time: 36 msec <== query time
;; SERVER: 127.0.0.53#53(127.0.0.53) <== local caching resolver
;; WHEN: Fri Jul 24 19:11:42 EDT 2020 <== date and time of inquiry
;; MSG SIZE rcvd: 97 <== bytes returned
```
If you get a response like this, is it good news?  The short answer is “yes”. You got a reply in a timely manner. The status field (status: NOERROR) shows there were no problems. You’re connecting to a name server that is able to supply the requested information and getting a reply that tells you some important details about the system you’re inquiring about. In short, you’ve verified that your system and the domain name system are getting along just fine.
Other possible status indicators include:
**SERVFAIL** – The name that was queried exists, but no data is available or available data is invalid.
**NXDOMAIN** – The name in question does not exist.
**REFUSED** – The zone does not exist at the requested authority and the infrastructure is not set up to provide responses when this is the case.
Here's an example of what you'd see if you were looking up a domain that doesn't exist:
```
$ dig cannotbe.org
; <<>> DiG 9.16.1-Ubuntu <<>> cannotbe.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35348
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
```
In general, **dig** provides more details than **ping**, though **ping** will respond with "Name or service not known" if the domain doesn't exit. When you ask about a legitimate system, you get to see what the domain name system knows about the system, how those records are configured and how long it takes to retrieve that data.
In fact, sometimes **dig** can respond with information when **ping** cannot respond at all and that kind of information can be very helpful when you're trying to nail down a connection problem.
### DNS record types and flags
One thing we can see in the first query above is the presence of both **CNAME** and **A** records. The **CNAME** (canonical name) is like an alias that refers one domain name to another. Most systems that you dig for won’t have a **CNAME** record, but only an **A** record. If you run a “dig localhost” command, you will see an **A** record that simply refers to 127.0.0.1 – the "loopback" address that every system uses. An **A** record maps a name to an IP address.
The DNS record types include:
* A or AAAA -– IPv4 and IPv6 addresses
* CNAME –- alias
* MX –- mail exchanger
* NS –- name server
* PTR –- a reversing entry that lets you find a system name when providing the IP address
* SOA –- start of authority record
* TXT –- some related text
We also see a series of “flags” on the fifth line of output. These are defined in [RFC 1035][4] which defines the flags included in the header of DNS messages and even shows the format of headers.
```
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
```
The flags shown in the fifth line in the initial query above are:
* **qr** = query
* **rd** = recursion desired
* **ra** = recursion available
Other flags described in the RFC include:
* **aa** = authoritative answer
* **cd** = checking disabled
* **ad** = authentic data
* **opcode** = a 4-bit field
* **tc** = truncation
* **z** (unused)
### Adding the +trace option
You will get a LOT more output from **dig** if you add **+trace** as an option. It will add information that shows how your DNS query rooted through the hierarchy of name servers to locate the answer you’re looking for.
All the **NS** records shown below reflect name servers – and this is just the first section of data you will see as the query runs through the hierarchy of name servers to track down what you're looking for. 
```
$ dig +trace networkworld.com
; <<>> DiG 9.16.1-Ubuntu <<>> +trace networkworld.com
;; global options: +cmd
. 84895 IN NS k.root-servers.net.
. 84895 IN NS e.root-servers.net.
. 84895 IN NS m.root-servers.net.
. 84895 IN NS h.root-servers.net.
. 84895 IN NS c.root-servers.net.
. 84895 IN NS f.root-servers.net.
. 84895 IN NS a.root-servers.net.
. 84895 IN NS g.root-servers.net.
. 84895 IN NS l.root-servers.net.
. 84895 IN NS d.root-servers.net.
. 84895 IN NS b.root-servers.net.
. 84895 IN NS i.root-servers.net.
. 84895 IN NS j.root-servers.net.
;; Received 262 bytes from 127.0.0.53#53(127.0.0.53) in 28 ms
...
```
Eventually, you'll get information tied directly to your request.
```
networkworld.com. 300 IN A 151.101.2.165
networkworld.com. 300 IN A 151.101.66.165
networkworld.com. 300 IN A 151.101.130.165
networkworld.com. 300 IN A 151.101.194.165
networkworld.com. 14400 IN NS ns-d.pnap.net.
networkworld.com. 14400 IN NS ns-a.pnap.net.
networkworld.com. 14400 IN NS ns0.pcworld.com.
networkworld.com. 14400 IN NS ns1.pcworld.com.
networkworld.com. 14400 IN NS ns-b.pnap.net.
networkworld.com. 14400 IN NS ns-c.pnap.net.
;; Received 269 bytes from 70.42.185.30#53(ns0.pcworld.com) in 116 ms
```
### Picking your responder
You can use the **@** sign to specify a particular name server that you want to handle your query. Here we’re asking the primary name server for Google to respond to our query:
```
$ dig @8.8.8.8 networkworld.com
; <<>> DiG 9.16.1-Ubuntu <<>> @8.8.8.8 networkworld.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43640
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;networkworld.com. IN A
;; ANSWER SECTION:
networkworld.com. 299 IN A 151.101.66.165
networkworld.com. 299 IN A 151.101.194.165
networkworld.com. 299 IN A 151.101.130.165
networkworld.com. 299 IN A 151.101.2.165
;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jul 25 11:21:19 EDT 2020
;; MSG SIZE rcvd: 109
```
The command shown below does a reverse lookup of the 8.8.8.8 IP address to show that it belongs to Google's DNS server.
```
$ nslookup 8.8.8.8
8.8.8.8.in-addr.arpa name = dns.google.
```
#### Wrap-Up
The dig command is an essential tool for both grasping how DNS works and troubleshooting connection problems when they arise.
Join the Network World communities on [Facebook][5] and [LinkedIn][6] to comment on topics that are top of mind.
--------------------------------------------------------------------------------
via: https://www.networkworld.com/article/3568488/digging-for-dns-answers-on-linux.html
作者：[Sandra Henry-Stocker][a]
选题：[lujun9972][b]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://www.networkworld.com/author/Sandra-Henry_Stocker/
[b]: https://github.com/lujun9972
[1]: https://www.flickr.com/photos/auntylaurie/15997799384
[2]: https://creativecommons.org/licenses/by/2.0/legalcode
[3]: https://www.networkworld.com/article/3268449/what-is-dns-and-how-does-it-work.html
[4]: https://tools.ietf.org/html/rfc1035
[5]: https://www.facebook.com/NetworkWorld/
[6]: https://www.linkedin.com/company/network-world

227
translated/tech/20200728 Digging for DNS answers on Linux.md Normal file
View File

@ -0,0 +1,227 @@
[#]: collector: (lujun9972)
[#]: translator: (wxy)
[#]: reviewer: (wxy)
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (Digging for DNS answers on Linux)
[#]: via: (https://www.networkworld.com/article/3568488/digging-for-dns-answers-on-linux.html)
[#]: author: (Sandra Henry-Stocker https://www.networkworld.com/author/Sandra-Henry_Stocker/)
在 Linux 上挖掘 DNS 应答中的秘密
======
> dig 是一个强大而灵活的工具，用于查询域名系统（DNS）服务器。在这篇文章中，我们将深入了解它的工作原理以及它能告诉你什么。
![Laurie Avocado][1]
`dig` 是一款强大而灵活的查询 DNS 名称服务器的工具。它执行 DNS 查询，并显示参与该过程的名称服务器返回的应答以及与搜索相关的细节。系统管理员和 [DNS][3] 管理员经常使用 `dig` 来帮助排除 DNS 问题。在这篇文章中，我们将深入了解它的工作原理，看看它能告诉我们什么。
开始之前，对 DNS（域名系统）的工作方式有一个基本的印象是很有帮助的。它是全球互联网的关键部分，因为它提供了一种查找世界各地的服务器的方式，从而可以与之连接。你可以把它看作是互联网的地址簿，任何正确连接到互联网的系统，都应该能够使用它来查询任何正确注册的服务器的 IP 地址。
### dig 入门
Linux 系统上一般都默认安装了 `dig` 工具。下面是一个带有一点注释的 `dig` 命令的例子：
```
$ dig www.networkworld.com
; <<>> DiG 9.16.1-Ubuntu <<>> www.networkworld.com <== 你使用的 dig 版本
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6034
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION: <== 你的查询细节
;www.networkworld.com. IN A
;; ANSWER SECTION: <== 结果
www.networkworld.com. 3568 IN CNAME idg.map.fastly.net.
idg.map.fastly.net. 30 IN A 151.101.250.165
;; Query time: 36 msec <== 查询用时
;; SERVER: 127.0.0.53#53(127.0.0.53) <== 本地缓存解析器
;; WHEN: Fri Jul 24 19:11:42 EDT 2020 <== 查询的时间
;; MSG SIZE rcvd: 97 <== 返回的字节数
```
如果你得到了一个这样的应答，是好消息吗？简短的回答是“是”。你得到了及时的回复。状态字段（`status: NOERROR`）显示没有问题。你正在连接到一个能够提供所要求的信息的名称服务器，并得到一个回复，告诉你一些关于你所查询的系统的重要细节。简而言之，你已经验证了你的系统和域名系统相处得很好。
其他可能的状态指标包括：
- `SERVFAIL`：被查询的名称存在，但没有数据或现有数据无效。
- `NXDOMAIN`：所查询的名称不存在。
- `REFUSED`：该区域的数据不存在于所请求的权威服务器中，并且在这种情况下，基础设施没有设置为提供响应。
下面是一个例子，如果你要查找一个不存在的域名，你会看到什么？
```
$ dig cannotbe.org
; <<>> DiG 9.16.1-Ubuntu <<>> cannotbe.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35348
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
```
一般来说，`dig` 比 `ping` 会提供更多的细节，如果域名不存在，`ping` 会回复 “名称或服务未知”。当你查询一个合法的系统时，你可以看到域名系统对该系统知道些什么，这些记录是如何配置的，以及检索这些数据需要多长时间。
事实上，有时 `dig` 可以在 `ping` 完全不能响应的时候进行响应，当你试图确定一个连接问题时，这种信息是非常有用的。
### DNS 记录类型和标志
在上面的第一个查询中，我们可以看到一个问题，那就是同时存在 `CNAME` 和 `A` 记录。`CNAME`（<ruby>规范名称<rt>canonical name</rt></ruby>）就像一个别名，把一个域名指向另一个域名。你查询的大多数系统不会有 `CNAME` 记录，而只有 `A` 记录。如果你运行 `dig localhost` 命令，你会看到一个 `A` 记录，它就指向 `127.0.0.1` —— 这是每个系统都使用的“回环”地址。`A` 记录用于将一个名字映射到一个 IP 地址。
DNS 记录类型包括：
* `A` 或 `AAAA`：IPv4 或 IPv6 地址
* `CNAME`：别名
* `MX`：邮件交换器
* `NS`：名称服务器
* `PTR`：一个反向条目，让你根据 IP 地址找到系统名称
* `SOA`：表示授权记录开始
* `TXT` 一些相关文本
我们还可以在上述输出的第五行看到一系列的“标志”。这些定义在 [RFC 1035][4] 中 —— 它定义了 DNS 报文头中包含的标志，甚至显示了报文头的格式。
```
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA| Z | RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
```
在上面的初始查询中，第五行显示的标志是：
* `qr` = 查询
* `rd` = 进行递归查询
* `ra` = 递归数据可用
RFC 中描述的其他标志包括：
* `aa` = 权威答复
* `cd` = 检查是否禁用
* `ad` = 真实数据
* `opcode` = 一个 4 位字段
* `tc` = 截断
* `z`（未使用）
### 添加 +trace 选项
如果你添加 `+trace` 选项，你将从 `dig` 得到更多的输出。它会添加更多信息，显示你的 DNS 查询如何通过名称服务器的层次结构找到你要找的答案。
下面显示的所有 `NS` 记录都反映了名称服务器 —— 这只是你将看到的数据的第一部分，因为查询通过名称服务器的层次结构来追踪你要找的东西：
```
$ dig +trace networkworld.com
; <<>> DiG 9.16.1-Ubuntu <<>> +trace networkworld.com
;; global options: +cmd
. 84895 IN NS k.root-servers.net.
. 84895 IN NS e.root-servers.net.
. 84895 IN NS m.root-servers.net.
. 84895 IN NS h.root-servers.net.
. 84895 IN NS c.root-servers.net.
. 84895 IN NS f.root-servers.net.
. 84895 IN NS a.root-servers.net.
. 84895 IN NS g.root-servers.net.
. 84895 IN NS l.root-servers.net.
. 84895 IN NS d.root-servers.net.
. 84895 IN NS b.root-servers.net.
. 84895 IN NS i.root-servers.net.
. 84895 IN NS j.root-servers.net.
;; Received 262 bytes from 127.0.0.53#53(127.0.0.53) in 28 ms
...
```
最终，你会得到与你的要求直接挂钩的信息：
```
networkworld.com. 300 IN A 151.101.2.165
networkworld.com. 300 IN A 151.101.66.165
networkworld.com. 300 IN A 151.101.130.165
networkworld.com. 300 IN A 151.101.194.165
networkworld.com. 14400 IN NS ns-d.pnap.net.
networkworld.com. 14400 IN NS ns-a.pnap.net.
networkworld.com. 14400 IN NS ns0.pcworld.com.
networkworld.com. 14400 IN NS ns1.pcworld.com.
networkworld.com. 14400 IN NS ns-b.pnap.net.
networkworld.com. 14400 IN NS ns-c.pnap.net.
;; Received 269 bytes from 70.42.185.30#53(ns0.pcworld.com) in 116 ms
```
### 挑选响应者
你可以使用 `@` 符号来指定一个特定的名称服务器来处理你的查询。在这里，我们要求 Google 的主名称服务器响应我们的查询：
```
$ dig @8.8.8.8 networkworld.com
; <<>> DiG 9.16.1-Ubuntu <<>> @8.8.8.8 networkworld.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43640
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;networkworld.com. IN A
;; ANSWER SECTION:
networkworld.com. 299 IN A 151.101.66.165
networkworld.com. 299 IN A 151.101.194.165
networkworld.com. 299 IN A 151.101.130.165
networkworld.com. 299 IN A 151.101.2.165
;; Query time: 48 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jul 25 11:21:19 EDT 2020
;; MSG SIZE rcvd: 109
```
下面所示的命令对 `8.8.8.8` IP 地址进行反向查找，以显示它属于 Google 的 DNS 服务器。
```
$ nslookup 8.8.8.8
8.8.8.8.in-addr.arpa name = dns.google.
```
### 总结
`dig` 命令是掌握 DNS 工作原理和在出现连接问题时排除故障的重要工具。
--------------------------------------------------------------------------------
via: https://www.networkworld.com/article/3568488/digging-for-dns-answers-on-linux.html
作者：[Sandra Henry-Stocker][a]
选题：[lujun9972][b]
译者：[wxy](https://github.com/wxy)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
[a]: https://www.networkworld.com/author/Sandra-Henry_Stocker/
[b]: https://github.com/lujun9972
[1]: https://images.techhive.com/images/article/2017/01/05_tools-100704412-large.jpg
[2]: https://creativecommons.org/licenses/by/2.0/legalcode
[3]: https://www.networkworld.com/article/3268449/what-is-dns-and-how-does-it-work.html
[4]: https://tools.ietf.org/html/rfc1035
[5]: https://www.facebook.com/NetworkWorld/
[6]: https://www.linkedin.com/company/network-world