VietNetwork.Vn

Phân giải DNS là một dịch vụ quan trọng, nếu không có dịch vụ này hoạt động chính xác thì tên miền sẽ không được phân giải chính xác thành địa chỉ IP, ngăn cản các dịch vụ mạng khác hoạt động chính xác. Do đó, điều quan trọng không kém là biết cách khắc phục sự cố DNS trên máy khách Linux và khắc phục mọi sự cố để giảm sự gián đoạn.

Có nhiều điểm có thể xảy ra lỗi trong quá trình tra cứu DNS, chẳng hạn như tại hệ thống thực hiện tra cứu, tại bộ đệm ẩn DNS hoặc trên máy chủ DNS bên ngoài. Ở đây chúng tôi sẽ đề cập đến cách kiểm tra những điều này và thực hiện các thử nghiệm khác nhau để xác định chính xác vấn đề nằm ở đâu.

1. Cấu hình máy chủ cục bộ

Trước hết, điều quan trọng là phải hiểu phần 'máy chủ lưu trữ' của tệp /etc/nsswitch.conf, cấu hình mặc định cho máy chủ lưu trữ được hiển thị bên dưới.

hosts: files dns myhostname
Về cơ bản, điều này có nghĩa là việc phân giải tên máy chủ sẽ được thực hiện theo thứ tự được chỉ định, từ trái sang phải. Các tệp đầu tiên sẽ được kiểm tra, tiếp theo là DNS.

Vì các tệp là tệp đầu tiên nên chúng sẽ được kiểm tra trước, tệp này tham chiếu tệp /etc/hosts cục bộ chứa tên máy chủ lưu trữ tĩnh tới ánh xạ địa chỉ IP. Tệp này được ưu tiên hơn bất kỳ độ phân giải DNS nào, mọi thay đổi đối với tệp sẽ được đặt thẳng vào bộ đệm DNS của máy chủ cục bộ đó. Dưới đây là một dòng ví dụ về cấu hình từ/etc/hosts

1.1.1.1 google.com
Vì mục nhập này nằm trong tệp máy chủ cục bộ của chúng tôi, nếu chúng tôi cố gắng truy cập   Đăng nhập để xem liên kết, máy cục bộ của chúng tôi sẽ nghĩ rằng 1.1.1.1 là địa chỉ IP chính xác của   Đăng nhập để xem liên kết và sẽ không thực hiện tra cứu DNS. Điều này được thể hiện bên dưới bằng cách cố gắng ping   Đăng nhập để xem liên kết, DNS không được tham khảo vì có mục nhập tệp máy chủ được ưu tiên.

[ root@centos ~]# ping google.com
PING google.com (1.1.1.1) 56(84) bytes of data.
Nếu không có mục nào trong tệp máy chủ, DNS sẽ được sử dụng tiếp theo theo /etc/nsswitch.conf. Các máy chủ được sử dụng để phân giải DNS sẽ được chỉ định trong tệp /etc/resolv.conf, bên dưới là cấu hình ví dụ của tệp này.

nameserver 192.168.0.1
Trong trường hợp này, tất cả các truy vấn DNS của hệ thống của chúng tôi sẽ chuyển đến máy chủ DNS tại 192.168.0.1. Các máy chủ DNS cấp hai và cấp ba khác cũng có thể được chỉ định ở đây làm bản sao lưu.

2. Kiểm tra DNS

Để phân giải DNS thành công thành 192.168.0.1, máy chủ DNS tại 192.168.0.1 sẽ cần chấp nhận lưu lượng TCP và UDP qua cổng 53 từ máy chủ của chúng tôi. Có thể sử dụng trình quét cổng như công cụ nmap để xác nhận xem máy chủ DNS có khả dụng trên cổng 53 như minh họa bên dưới hay không.

Lưu ý: Để cài đặt nmap, hãy chạy 'yum install nmap -y'.

[root@centos ~]# nmap -sU -p 53 192.168.0.1
Starting Nmap 6.40 ( http://nmap.org ) at 2015-08-26 15:22 AEST
Nmap scan report for 192.168.0.1
Host is up (0.00091s latency).
PORT   STATE         SERVICE
53/udp open|filtered domain
MAC Address: 02:00:79:55:00:0D (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 0.29 seconds

[root@centos ~]# nmap -sT -p 53 192.168.0.1
Starting Nmap 6.40 ( http://nmap.org ) at 2015-08-26 15:22 AEST
Nmap scan report for 192.168.0.1
Host is up (0.00099s latency).
PORT   STATE SERVICE
53/tcp open  domain
MAC Address: 02:00:79:55:00:0D (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 0.07 seconds
Cần lưu ý rằng việc quét UDP bằng nmap không đáng tin cậy do bản chất của UDP, đây là lý do tại sao trạng thái được liệt kê là mở hoặc được lọc. Chúng ta có thể thấy rõ rằng TCP 53 chắc chắn đang mở và phản hồi, đó là một dấu hiệu tốt, nếu trạng thái được báo cáo là đã lọc, điều tiếp theo cần điều tra sẽ là kết nối với máy chủ DNS, đặc biệt là bất kỳ tường lửa nào chạy trên máy chủ DNS sẽ cần được cấu hình để cho phép lưu lượng TCP và UDP cổng 53 vào.

Bằng cách chạy chụp gói, chúng tôi có thể xem bất kỳ truy vấn DNS nào qua mạng, trong ví dụ này, chúng tôi đang chạy tcpdump tới máy chủ DNS cục bộ của mình tại 192.168.0.1 và chúng tôi có thể thấy yêu cầu của mình từ 192.168.0.100 yêu cầu bản ghi A của   Đăng nhập để xem liên kết dưới dạng cũng như phản hồi 216.58.220.142 được trả về từ máy chủ DNS cục bộ của chúng tôi.

[root@testing ~]# tcpdump -n host 192.168.0.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
15:29:52.439222 IP 192.168.0.100.32811 > 192.168.0.1.domain: 8134+ A? google.com. (28)
15:29:52.440153 IP 192.168.0.1.domain > 192.168.0.100.32811: 8134 1/0/0 A 216.58.220.142 (44)
Công cụ Domain Information Groper ( Dig ) có thể được sử dụng để thực hiện các truy vấn DNS như minh họa bên dưới. Chúng tôi đang truy vấn lại   Đăng nhập để xem liên kết và chúng tôi lại được trả lại địa chỉ IP bản ghi A là 216.58.220.142.

Lưu ý: Dig được cung cấp bởi gói bind-utils có thể được cài đặt với 'yum install bind-utils'.

[root@testing ~]# dig google.com

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.3 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32536
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             65      IN      A       216.58.220.142
Trạng thái của truy vấn đào đã trả về chính xác địa chỉ IP từ máy chủ DNS cục bộ của chúng tôi tại 192.168.0.1 và trạng thái là KHÔNG LỖI, được trả về khi truy vấn đã được giải quyết thành công. Mã phản hồi có thể giúp bạn trong quá trình khắc phục sự cố, để biết danh sách đầy đủ về chúng, hãy tham khảo RFC 5395.

3. Kiểm tra máy chủ DNS có thẩm quyền

Với Dig, chúng tôi cũng có thể truy vấn trực tiếp các máy chủ tên có thẩm quyền cho một miền, đây là những máy chủ DNS lưu giữ các bản ghi có thẩm quyền cho vùng DNS của miền – nguồn gốc của sự thật. Nếu nhận được phản hồi chính xác từ máy chủ DNS có thẩm quyền nhưng không nhận được khi truy vấn máy chủ DNS của riêng bạn thì bạn nên điều tra xem tại sao máy chủ DNS cục bộ của bạn không thể giải quyết bản ghi.

Để lấy tên máy chủ của một miền, chúng ta có thể sử dụng lệnh 'whois' như hình bên dưới. Đây là một phần của gói whois và có thể được cài đặt với 'yum install whois -y' nếu chưa có.

[root@testing ~]# whois google.com | grep -i "name server"
   Name Server: NS1.GOOGLE.COM
   Name Server: NS2.GOOGLE.COM
   Name Server: NS3.GOOGLE.COM
   Name Server: NS4.GOOGLE.COM
Như được hiển thị,   Đăng nhập để xem liên kết hiện có 4 máy chủ định danh có thẩm quyền, nếu chúng tôi thực hiện đào trực tiếp với bất kỳ máy chủ nào trong số này, chúng tôi sẽ nhận được phản hồi có thẩm quyền, đó là phản hồi cập nhật và không được lưu trong bộ nhớ cache trực tiếp từ nguồn chứ không phải từ máy chủ DNS cục bộ của chúng tôi. Trong ví dụ dưới đây, chúng tôi đã chạy truy vấn của mình đối với @ns1.google.com

[root@testing ~]# dig @NS1.GOOGLE.COM google.com

; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.3 <<>> @NS1.GOOGLE.COM google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3477
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;google.com.                    IN      A

;; ANSWER SECTION:
google.com.             300     IN      A       216.58.220.142
Mặc dù bản ghi A được trả về giống nhau trong trường hợp này, nhưng hãy lưu ý rằng trong phản hồi đào này, chúng ta hiện có cờ "aa" trong tiêu đề thể hiện rằng đây là câu trả lời có thẩm quyền và không phải là phản hồi được lưu trong bộ nhớ cache. Nếu chúng ta chạy lại lệnh dig này, TTL 300 giây được trả về trong phần câu trả lời sẽ liên tục cho biết rằng TTL là 300 giây vì phản hồi là có thẩm quyền.

Tuy nhiên, nếu chúng tôi chạy quá trình đào này mà không chỉ định @ns1.google.com, chúng tôi sẽ truy vấn máy chủ DNS 192.168.0.1 không có thẩm quyền đối với miền   Đăng nhập để xem liên kết, sau khi có kết quả đầu tiên, bản ghi sẽ được lưu vào bộ nhớ cache cục bộ. Điều này có thể được xác nhận bằng cách chạy lại lệnh dig, vì giá trị TTL sẽ giảm xuống cho đến khi về 0 và bị xóa hoàn toàn khỏi bộ đệm.

Bằng cách truy vấn trực tiếp máy chủ định danh có thẩm quyền, chúng tôi đảm bảo rằng chúng tôi nhận được phản hồi cập nhật nhất thay vì phản hồi tiềm ẩn cũ được lưu trong bộ nhớ đệm từ máy chủ DNS cục bộ hoặc bộ đệm DNS cục bộ của chúng tôi.

Vì DNS là một dịch vụ quan trọng nên có thể khắc phục sự cố nên đây là một kỹ năng hữu ích. Theo mặc định, trước tiên Linux sẽ kiểm tra tệp máy chủ cục bộ /etc/hosts trước khi truy vấn các máy chủ DNS được xác định trong /etc/resolv.conf. Điều quan trọng là phải xác nhận rằng các máy chủ DNS chính xác đã được chỉ định trong tệp này và bạn có thể kết nối với chúng trên cổng TCP/UDP 53. Có thể kiểm tra các truy vấn DNS bằng lệnh dig, đối với máy chủ DNS cục bộ hoặc đối với máy chủ có thẩm quyền. máy chủ định danh cho miền sẽ cung cấp kết quả cập nhật không được lưu trong bộ nhớ cache.