- DNS đã được dùng hơn 35 năm kể từ thập niên 1980 và cấu trúc cũng khá ổn định, nhưng nhiều lập trình viên vẫn mất rất lâu mới có thể tự tin debug các vấn đề cơ bản
- Điểm khó không hẳn nằm ở độ phức tạp của bản thân DNS, mà ở chỗ có quá nhiều thành phần vô hình như cache của resolver, thư viện DNS cục bộ, hay các cuộc trao đổi với authoritative nameserver
dig rất mạnh nhưng cấu trúc đầu ra và thuật ngữ của nó khá lạ, và dù các tính năng như +norecurse rất hữu ích thì việc diễn giải kết quả vẫn không trực quan- Những cái bẫy phổ biến như negative caching, lịch sử
musl không hỗ trợ TCP DNS, resolver bỏ qua TTL, nginx cache vĩnh viễn, hay Kubernetes ndots đều rất khó học nếu chưa từng được ai chỉ ra trước
- Với những người chỉ thỉnh thoảng mới đụng đến DNS, cheat sheet sẽ hữu ích, còn các vấn đề khó thử nghiệm có thể được giảm bớt nhờ môi trường thử nghiệm an toàn như Mess With DNS
DNS khó dù là công nghệ cũ
- DNS đã được sử dụng hơn 35 năm từ thời RFC 1034, được dùng trên mọi website trên Internet, và ở nhiều khía cạnh vẫn hoạt động khá giống 30 năm trước
- Dù vậy, việc debug những vấn đề cơ bản như “đã cấu hình domain đúng nhưng không resolve được” hay “kết quả DNS của
dig và trình duyệt khác nhau” vẫn có thể tốn nhiều thời gian
- Những người thấy DNS khó thường hay mắc ở các điểm sau
- Không cảm thấy thoải mái ngay cả với những thay đổi DNS đơn giản của website
- Dễ nhầm rằng bản ghi DNS được push đi, trong khi thực tế chúng được pull
- Dù biết khái niệm cơ bản nhưng vẫn bối rối với các chi tiết như negative caching, hay sự khác nhau giữa truy vấn DNS của
dig và của trình duyệt
Resolver và nameserver vô hình
- Luồng cơ bản khi gửi một yêu cầu DNS từ máy tính có vẻ đơn giản
- Máy tính gửi yêu cầu đến một máy chủ gọi là resolver
- Resolver kiểm tra cache, và nếu cần thì hỏi tiếp authoritative nameserver
- Nhưng trong quá trình debug thực tế, có nhiều yếu tố quan trọng vốn không lộ ra sẵn
- Khó biết bên trong cache của resolver đang có gì
- Không rõ ở máy cục bộ thì thư viện DNS nào đang xử lý yêu cầu
- Có thể là libc
getaddrinfo, glibc, musl, implementation của Apple, mã DNS riêng của trình duyệt, hoặc implementation tùy biến riêng
- Mỗi implementation hơi khác nhau về cấu hình, cách cache và mức hỗ trợ tính năng
- DNS của
musl trước đầu năm 2023 vẫn chưa hỗ trợ TCP
- Không nhìn thấy được cuộc trao đổi giữa resolver và authoritative nameserver
- Nếu theo dõi được resolver đã hỏi authoritative nameserver nào và nhận về câu trả lời gì thì sẽ dễ hiểu nhiều vấn đề DNS hơn rất nhiều
Cách tiếp cận để làm lộ ra hệ thống ẩn
- Chỉ riêng việc chỉ ra những thành phần bị ẩn là gì cũng đã giúp ích rất nhiều cho việc học
- Nếu không biết rằng ngay trong một máy tính cũng có thể dùng nhiều thư viện DNS khác nhau tùy tình huống, bạn có thể bị rối trong thời gian dài
- Mess With DNS thử nghiệm theo kiểu fishbowl để cho thấy những phần thường bị che khuất
- Nó cho phép thấy được một phần cuộc trao đổi giữa resolver và authoritative nameserver
- Cũng có cách đưa thông tin debug trực tiếp vào phản hồi DNS
Gợi ý mà Extended DNS Errors mang lại
- Extended DNS Errors là một cách mới để máy chủ DNS đưa thêm thông tin debug vào phản hồi
- Nếu truy vấn domain không tồn tại
xjwudh.com bằng dig @8.8.8.8 xjwudh.com, bạn có thể thấy lỗi bổ sung như sau
; EDE: 12 (NSEC Missing): (Invalid denial of existence of xjwudh.com/a)
- Ví dụ này có vẻ liên quan đến DNSSEC, và điểm quan trọng là trong phản hồi có thêm thông điệp debug
- Để thấy được ví dụ trên thì cần phiên bản
dig mới hơn
dig mạnh nhưng khó đọc
dig rất hữu ích để kiểm tra trạng thái nội bộ của DNS- Dùng
dig +norecurse có thể kiểm tra một DNS resolver cụ thể đang có bản ghi nào trong cache
8.8.8.8 dường như trả về SERVFAIL nếu phản hồi không có sẵn trong cachegoogle.com có trong cache nên trả về NOERROR cùng bản ghi Ahomestarrunner.com không có trong cache nên trả về SERVFAIL, nhưng điều đó không có nghĩa là không tồn tại bản ghi DNS
- Đầu ra của
dig khá khó đọc nếu chưa quen
- Những tiêu đề như
->>HEADER<<-, flags:, OPT PSEUDOSECTION:, QUESTION SECTION:, ANSWER SECTION: khá lạ
- Việc xuống dòng và khoảng trắng giữa các phần không tạo cảm giác nhất quán
- Từ
MSG SIZE rcvd: 47, rất khó đoán liệu ngoài rcvd còn có trường nào khác hay không
- Bạn phải biết rằng khi nói có 1 bản ghi trong phần
ADDITIONAL, trên thực tế OPT PSEUDOSECTION đang đóng vai trò đó
- Đầu ra của
dig trông giống một script lớn dần theo thời gian một cách hữu cơ hơn là một định dạng được thiết kế có chủ đích ngay từ đầu
Cách làm công cụ DNS dễ đọc hơn
- Sẽ hữu ích nếu có tài liệu giải thích chính đầu ra của
dig
- how to use dig giải thích cấu trúc đầu ra của
dig và cách rút gọn đầu ra mặc định
- Cũng có thể tạo ra các công cụ thân thiện hơn
- Có các lựa chọn thay thế như dog, doggo, DNS lookup tool
- Tuy vậy, khi cần các tính năng nâng cao như
+norecurse, có thể vẫn tiện hơn nếu xử lý bằng riêng dig
- Thay thế toàn bộ phạm vi tính năng rộng của
dig là một công việc lớn
- Cũng có thể thêm tùy chọn kiểu
+human vào đầu ra của dig để hiển thị cùng một thông tin theo cách có cấu trúc hơn
- Có thể tách rõ header, truy vấn, phản hồi, phần bổ sung, thời gian, máy chủ, giao thức và kích thước phản hồi
- Đây không phải là cách giảm lượng thông tin mà là trình bày cùng một thông tin theo cách dễ đọc hơn
dig mới hơn có định dạng đầu ra +yaml
- Nó có thể tạo cảm giác rõ ràng hơn, nhưng cũng có thể quá dài đến mức ngay cả một phản hồi DNS đơn giản cũng không vừa màn hình
Những cái bẫy DNS thường gặp nhưng khó học
- DNS có những cái bẫy khá thường gặp, nhưng rất khó biết nếu chưa từng được ai chỉ ra
-
negative caching
- Nếu truy cập một domain chưa có bản ghi DNS, trạng thái “không tồn tại” của bản ghi đó có thể bị cache lại
- Nếu trạng thái này bị cache trong vài giờ thì sẽ rất phiền
-
Khác biệt trong implementation của getaddrinfo
-
Resolver bỏ qua TTL
- Dù đặt TTL của bản ghi DNS là 5 phút, một số resolver vẫn có thể bỏ qua và cache lâu hơn, chẳng hạn 24 giờ
-
Vấn đề cấu hình nginx
- Nếu cấu hình nginx sai, nó có thể cache bản ghi DNS mãi mãi
-
Kubernetes ndots
- ndots có thể làm DNS trong Kubernetes chậm đi
Cách chia sẻ và tài liệu hóa các cái bẫy
- Kiến thức về các cái bẫy kỳ quặc rất khó có được, và việc mọi người cứ phải lặp lại cùng một vấn đề là điều kém hiệu quả
- Khi giải thích một chủ đề, việc chỉ ra luôn các cái bẫy phổ biến sẽ rất hữu ích
- Cách cộng đồng gom lại các cái bẫy phổ biến cũng rất hữu ích
- Với Bash, shellcheck cực kỳ hữu ích như một bộ sưu tập các cái bẫy bash
- Việc tài liệu hóa các cái bẫy DNS cũng khó vì vấn đề mỗi người gặp phải khác nhau
- Người 3 năm mới cấu hình DNS cho domain cá nhân một lần và người vận hành DNS cho domain có lưu lượng lớn sẽ gặp các cái bẫy khác nhau
Việc ít dùng và khó thử nghiệm
- Nhiều người rất hiếm khi đụng đến DNS
- Nếu 3 năm mới làm việc với DNS một lần thì việc thấy nó khó học là điều tự nhiên
- Những cheat sheet kiểu “quy trình thay đổi nameserver” có thể hữu ích
- DNS cũng là công nghệ khiến người ta ngại thử nghiệm vì sợ làm hỏng domain của chính mình
- Mess With DNS được tạo ra để giảm bớt gánh nặng khi thử nghiệm như vậy
1 bình luận
Ý kiến trên Hacker News
Tôi không đồng ý với bài này. Tôi nghĩ DNS không thực sự khó học, chỉ là ít người chịu bỏ thời gian để học mà thôi
Điểm hay của DNS là hệ thống cho bạn biết trạng thái nội bộ của nó khi truy vấn. Có thể dễ dàng xem xét máy chủ DNS của một zone đã biết và hiểu cách nó hoạt động; các công cụ miễn phí như
digcũng được dùng rộng rãiSuốt sự nghiệp, tôi luôn ngạc nhiên khi những người từng làm việc cùng lại nhớ nhất kiến thức DNS của tôi, vì tôi không nghĩ mình biết điều gì thần bí hay đặc biệt. DNS được chuẩn hóa rất tốt, các triển khai máy chủ và client phổ biến cũng tuân thủ chuẩn khá nghiêm ngặt, và cũng dễ quan sát bằng công cụ miễn phí. Chỉ cần công sức và thời gian, chứ thật sự không khó
Trước đây tôi từng nghĩ “Không, thật ra nó dễ mà!” là một lời động viên khi ai đó nói “khó học”. Tôi thích DNS, và cũng nghĩ ở nhiều khía cạnh nó đơn giản đến đáng ngạc nhiên. Ví dụ tại https://implement-dns.wizardzines.com có hướng dẫn cách tự triển khai một DNS resolver đồ chơi bằng vài đoạn mã Python đơn giản
Nhưng theo thời gian, tôi học được rằng “Không, nó dễ học mà!” thường được tiếp nhận không phải như lời động viên “bạn làm được!”, mà giống “không phải nó khó, mà là bạn ngốc thôi”. Khi một chủ đề khiến mình bối rối suốt nhiều năm mà lại nghe “thật ra nó dễ mà?”, điều đó chẳng giúp được gì mấy
Vì vậy giờ tôi không nói như thế nữa, mà dành nhiều công sức để hiểu vì sao mọi người thấy một thứ nào đó khó và tìm cách giảm bớt các rào cản đó
BIND làm rất tốt nhiệm vụ của nó, nhưng file cấu hình không hay, tài liệu thì dài và khô khan, đôi khi phức tạp không cần thiết.
digrất mạnh, nhưng rút gọn mọi thứ như thể vẫn còn thời dùng terminal 80 cột. Khi debug vấn đề DNS, đã có lúc Wireshark là công cụ tốt hơndigNếu dùng PowerDNS hoặc các máy chủ DNS hiện đại khác, có lẽ việc thiết lập một máy chủ DNS chạy được sẽ dễ hơn nhiều. Tôi không biết client DNS hiện đại nào tốt nên cuối cùng vẫn quen với
dig. Là người dùng cờ--colorcủa lệnhip, tôi mong các công cụ nhưdigcũng có đầu ra hiện đại hơn. Cờ dòng lệnh thì tôi sẽ gom vào alias, chỉ cần họ thêm tính năng là đượcNói nghiêm túc,
MSG SIZE rcvd: 71đâu cần phải viết tắt.flags: qr rd racũng có thể viết đầy đủ. Tôi cũng không biết dấu chấm phẩy ở đầu dòng muốn truyền đạt điều gì, nó chỉ làm rối thêmKhông có gì lạ khi mọi người học DNS bằng các tài liệu/công cụ được cung cấp rồi thấy bối rối
Nếu “chỉ cần một chút công sức và thời gian”, vậy cần bao nhiêu công sức và thời gian? Nhiều người trong luồng này nói họ học bằng cách triển khai máy chủ, mất vài tháng mới hiểu, rồi lặp lại rằng “một khi đã hiểu thì khá dễ”. Vậy với một thứ phổ biến và đơn giản về mặt khái niệm như thế, chẳng phải ta có thể đồng ý rằng trên thực tế nó khó học sao
Ví dụ: quy tắc để trình duyệt cache và hết hạn các bản ghi DNS là gì? Các quy tắc đó có nhất quán giữa các trình duyệt không?
Tôi nghĩ bài viết đã nắm đúng trọng tâm. Bản thân DNS không khó, nhưng học DNS trong thế giới thực thì khó. Bởi vì rất nhiều phần ở giữa, từ lúc thực hiện truy vấn đến lúc nhận được kết quả như mong đợi, đều bị ẩn đi
Trước đây, cách kết nối Internet mặc định là một interface, một gateway, một nhà cung cấp máy chủ DNS. Giờ đây có thể kết nối đồng thời với nhiều WAN như LTE và WiFi, và người dùng khó biết đường phân giải thực tế nào đã được dùng. Không rõ đó là trình duyệt, giao diện chuẩn của thư viện C hệ thống, resolver cục bộ hay recursive resolver ở giữa, có cache cục bộ hay không, hay có tự động thêm các tùy chọn đặc biệt mặc định hay không
Ngay cả khi mọi thứ hoạt động, bạn cũng không thể mù quáng tin rằng truy vấn và phản hồi của một ứng dụng đã đi cùng đường với ứng dụng khác. Ba trình duyệt có thể dùng ba cách khác nhau, hệ điều hành lại hoạt động theo cách khác nữa, rồi mDNS còn có thể thêm lựa chọn thứ năm
Có câu đùa rằng trong khoa học máy tính chỉ có ba vấn đề khó: vô hiệu hóa cache và đặt tên
Còn DNS là một hệ thống cache dành cho tên của sự vật
https://reddit.com/comments/15c2ul2/comment/jtty9dy
Được quản lý trên toàn cầu (IANA), có tính phân cấp, liên hợp, và cũng dễ sửa đổi
DNS là loại công nghệ có sự lệch pha giữa mức độ trông có vẻ dễ và độ khó thực sự lộ ra khi đi sâu vào
Chúng ta dùng DNS hằng ngày, và nó trông rất dễ. Ngôn ngữ DNS trong đời thường là tên miền, truy vấn, địa chỉ IP. Ngôn ngữ này được phơi bày trực tiếp trong trình duyệt, và từ sự phơi bày đó ta xây dựng mô hình tinh thần về cách nó hoạt động
Nhưng bên trong lại có một ngôn ngữ hoàn toàn khác: zone, resolver, thẩm quyền được ủy quyền, và dấu chấm kỳ lạ phía sau tên miền cấp cao nhất
Ví dụ cả hai ta đều biết
host.example.co.uknghĩa là gì, nhưng nếu không có dấu chấm ở cuối, resolver có thể thử truy vấnhost.example.co.uk.example.co.ukVới thiết lập mặc định của Windows, trong trường hợp này nó có thể thử
host.example.co.uk.example.co,host.example.co.uk.example, rồi lạihost.example.co.uk.example, vàhost.example.co.uk.để lấy kết quả. Tuy nhiên tôi chưa từng thấy Windows thực sự thử lần đầu tiên đó; hành vi này có vẻ được thiết kế để DNS xử lý các môi trường doanh nghiệp lớn có Active Directory liên hợp kiểu quái vậtNgày nay trình duyệt rất có khả năng lén chuyển sang máy chủ DNS over HTTPS(DoH) mà không có sự đồng ý của người dùng và giao du với đủ loại đối tượng đáng ngờ. Truy vấn DNS là dữ liệu nền tảng, nên ISP vốn thích nhìn xem người dùng đi đâu. Nhà cung cấp hệ điều hành tất nhiên cũng có thể gửi “telemetry”. Google không sở hữu desktop, nhưng sở hữu trình duyệt, nên nếu khiến người dùng dùng máy chủ DNS “an toàn” thay vì DNS họ đã cấu hình thì điều đó có lợi cho họ. Những trò lắt léo này khiến việc xử lý sự cố IT thú vị hơn trước rất nhiều
Không cần quá lo về dấu chấm ở cuối. Dù sao thì gần như chắc chắn bạn cũng không đang dùng máy chủ DNS mà bạn nghĩ mình đang dùng. Tôi hiểu vì sao DoH được tạo ra, và với một số người dùng phổ thông nó cũng có lý do để dùng. Ví dụ, khi một người không phải chuyên gia IT dùng hotspot WiFi độc hại, việc trình duyệt an toàn quay về “căn cứ” để thực hiện truy vấn DNS sẽ bảo vệ họ phần nào. Nhưng việc nhà cung cấp trình duyệt có được giẫm đạp lên lựa chọn bảo mật endpoint của người dùng hay không lại là chuyện khác
DNS phức tạp hơn nhiều so với chỉ tra cứu địa chỉ. Ngày nay đó là chuyện tiền bạc, và thật ra từ khoảng năm 2000 nó đã luôn như vậy. Giờ có rất nhiều tập đoàn khổng lồ cực kỳ cứng đầu muốn quyết định ai sẽ kiếm lợi thông qua người dùng
Bản thân DNS thì dễ. Phân phối thông tin không phụ thuộc vào tổ chức mới thật sự khó
Vài năm trước tôi nhận ra mình chỉ hiểu DNS theo từng mảnh rời rạc. Tôi biết
dig(1), BIND, và khái niệm ở mức CS101 về cách phân giải DNS đệ quy hoạt động, nhưng lại thiếu kiến thức thực chiến cần thiết để thiết kế/triển khai một hệ thống không tầm thường, hoặc debug một hệ thống không hoạt độngVì vậy tôi đã đọc “DNS and BIND” gần như từ đầu đến cuối, và cũng cấu hình các máy chủ BIND thật cho vài website cá nhân ít quan trọng. Việc này không khó, nhưng cần đầu tư khá nhiều thời gian. BIND không phải đáp án đúng cho nhiều trường hợp sử dụng, nhưng vì rất nhiều khái niệm và thuật ngữ DNS vẫn xuất phát từ BIND nên nó rất đáng giá
Tôi nghĩ sách đang bị đánh giá thấp khi học những thứ như thế này. Tài liệu tìm thấy trên web thường là lý thuyết cấp cao, ví dụ sơ đồ khối về truy vấn đệ quy; hoặc tài liệu theo tác vụ như cách dùng
digđể thực hiện truy vấn đệ quy; hoặc tài liệu cấp thấp kiểu đọc source để hiểu chính sách retry của DNS client cục bộ. Để hiểu từng mảnh, cách chúng khớp với nhau, mục tiêu cần đạt được, cho tới các chi tiết triển khai như cache nằm ở đâu, gần như không có gì thay thế được cách tiếp cận toàn diện thường thấy trong sách. Trên web không phải hoàn toàn không có, nhưng hiếmMọi người làm IT nên có kiến thức thực hành về debug sự cố DNS
DNS trong lịch sử từng là kênh của các lỗ hổng bảo mật quan trọng, và nhiều khả năng sẽ tiếp tục như vậy. Những lỗ hổng này dẫn tới đường tấn công vào hầu như mọi giao thức khác như SMTP. Ngay cả hệ thống tổ chức chứng thực dùng cho HTTPS về cơ bản cũng phụ thuộc nặng nề vào một giao thức không an toàn. Nếu ngân hàng mua chứng chỉ DV thay vì OV, bạn có nhận ra không? Có lẽ là không
Vì vậy việc DNS trông khó học đối với người thiếu hứng thú chưa hẳn là điều xấu. Bởi ngay cả bây giờ vẫn thấy có người xây các tính năng liên quan đến DNS mà không bỏ thời gian hiểu đúng lịch sử của những thứ như ngẫu nhiên hóa cổng, nhiễm độc cache, AXFR
Xin tự quảng bá side project hơi ngượng một chút: bài viết nói sẽ tốt nếu phân giải DNS có chế độ “debug”, và Web UI của ComfyDNS có tính năng đó :3
https://comfydns.com/
Hình ở phía trên có ghi
TRACE google.com A INchính là tính năng đóComfyDNS cũng là một dự án để gãi đúng chỗ ngứa cá nhân của tôi. Tôi đã chán việc sửa file zone của bind9 bằng tay, và cũng tò mò DNS hoạt động như thế nào. Tôi biết phần bề mặt nhưng không biết chi tiết, nên đã triển khai RFC “từ đầu”. Tôi có dùng netty nhưng không dùng thư viện DNS. Khá thú vị
Nếu site không chịu nổi traffic và sập thì mong thông cảm. Đây là ứng dụng Rails chạy trên free tier của Oracle Cloud
Câu đùa tôi luôn nghe là DNS kết hợp hai vấn đề khó nhất trong khoa học máy tính: đặt tên và vô hiệu hóa cache
Đây không phải kiểu vô hiệu hóa cache khó. Thật ra gần như không cần “vô hiệu hóa”
Ở phía máy chủ, việc gửi lẫn phiên bản cũ và mới trong một thời gian cũng hoàn toàn được chấp nhận
Lại có cảm giác kiểu “lại thêm một bài như thế này”. Vào thập niên 1990, Internet nhỏ hơn, máy tính chậm hơn và kém mạnh hơn nhiều, nhưng chúng tôi học rất dễ
Với ISP thời đó, những thứ như DNS, LDAP, SMTP, IMAP là nền tảng của nền tảng, và người ta thực sự đọc các tài liệu chính thức như RFC. Muốn vận hành máy chủ trên Internet thì phải học, và chỉ cần đầu tư một chút thời gian, tức là dùng thời gian được trả lương ở chỗ làm, là có thể học được
Thế hệ lập trình viên và DevOps ngày nay không có kiên nhẫn hay tính chủ động, mong được đút tận miệng, rồi sao chép bừa từ StackOverflow và các blog giá trị thấp. Thay vì học nền móng đã dựng nên Internet, họ cầm lấy công cụ wrapper đang là mốt trong tuần đó, làm theo hướng dẫn tệ hại trên blog, rồi khi mọi thứ sụp đổ và công ty mất một khoản tiền lớn thì lại kêu oan. Vì họ đã không dành thời gian học các kiến thức nền tảng về cách mọi thứ thực sự vận hành trên Internet
Tôi đã thấy chuyện này lặp đi lặp lại. Thực ra không khó đến vậy. Chỉ cần chịu làm bài tập về nhà
Không khó. DNS là một trong số ít công nghệ không thay đổi nhiều, và cách nó hoạt động cũng khá trực quan
digcó thể hơi gây rối. Nó nhiều tính năng hơnnslookupcũ, nhưng kém trực quan hơn. Nhân tiện,nslookupvẫn hoạt động tốtTôi nghĩ một lý do khiến những người trẻ trong ngành bối rối với DNS và các giao thức cốt lõi là vì giờ đây quá nhiều thứ “cứ thế chạy”
Ví dụ, router WiFi ngày nay lấy ra khỏi hộp là “cứ thế chạy”. Đầu những năm 2000, để cấu hình những thứ như vậy cần một kỹ sư mạng biết DNS, IP, Ethernet, RFC1918, các giao thức định tuyến thực sự và rất nhiều thứ khác, và hẳn cũng hiểu rõ vì sao lại cấu hình như thế
Nếu bạn thấy DNS từ góc nhìn client khó hiểu, hãy thử cấu hình BIND ;-)
/lời than phiền của một ông già râu cổ
Lẽ ra phải để DHCP server của WRT54G cấp IP tĩnh của domain controller làm DNS server để phân giải tên đúng, nhưng tôi chỉ làm cho mọi thứ chạy bằng địa chỉ IP và các mục trong file hosts. MX record của domain cũng trỏ tới WAN IP của router, và không có PTR record. Nhìn lại thì việc email được chuyển suôn sẻ như vậy đúng là kỳ tích
Vài năm sau tôi mới hiểu DNS thực sự hoạt động thế nào, và đầu những năm 20 tuổi thì tiếp quản một intranet nội bộ dùng BIND làm nameserver cho tất cả zone domain doanh nghiệp bên ngoài. Khi chuyển cấu hình này sang VPS để tăng độ tin cậy, tôi đã học được rất nhiều về zone transfer, SOA, v.v. Tôi biết ơn trải nghiệm đó, nhưng ngày nay gần như mọi thứ đều được xử lý thay, nên nó trở thành hoạt động giá trị thấp. Dù tốt hay xấu, “IT” không được đánh giá theo cùng cách với “software engineering”
Tôi không thể quên lần Firefox phát hành bản cập nhật bật DNS-over-HTTPS mặc định. Chúng tôi đang dùng DHCP để cấp DNS server nội bộ cho các workstation, thì đột nhiên hàng loạt câu “Email của tôi biến mất rồi! Hỏng hết rồi!” ập đến. Webmail nội bộ và web server intranet trông như thể đã biến mất
Mất nhiều thời gian hơn mức cần thiết để hiểu chuyện gì đang xảy ra. Một phần là vì suy nghĩ “Đây là DNS mà, sao tự nhiên lại hỏng được?”. Nhưng khá rõ là Mozilla đã không lường trước vấn đề rất dễ dự đoán này
Ví dụ, khi truy vấn
thing.behind.cdn.it, tôi nhận một câu trả lời, còn người khác nhận một câu trả lời khác cho cùng tên đó. Bản thân chuyện ấy khá rõ ràng, nhưng sẽ phức tạp khi ai đó hỏi một cách hợp lý rằng “Bạn có thể mở lỗ trên firewall chothing.behind.cdn.itkhông?”Có máy chủ chuyển tiếp yêu cầu, có máy chủ ủy quyền, có máy chủ tra cứu hộ và có máy chủ không làm vậy. Còn có phép thuật search domain phía client, và cũng không chắc client hay thư viện resolver nội bộ có tôn trọng TTL hay không
Loại record thì vô số, và đôi khi máy chủ còn yêu cầu kết nối lại bằng TCP thay vì UDP
Vì vậy DNS khá phức tạp. Nó tạo ảo giác đơn giản vì hoạt động rất tốt và hầu hết phần khó nhằn đã được trừu tượng hóa thành những thứ “về cơ bản cứ thế chạy”
Thật đáng ngạc nhiên là tôi tự tin hơn nhiều trong việc hiểu mạng ở mức cao, bao gồm DNS và cả những thứ bên dưới như
ethtool, Ethernet frameTôi thích biết mọi thứ từ nền móng, nên đã chọn kỹ thuật điện thay vì khoa học máy tính ở đại học; có lẽ điều đó cũng không có gì đáng ngạc nhiên
Nguyên lý của DNS không khó đến vậy nếu hiểu rằng nó có tính đệ quy. Nhưng nếu muốn cấu hình có xét đến bảo mật, có hạ tầng đúng, và chỉnh đến từng chi tiết cuối cùng thì có rất nhiều thứ phải học. Nếu bỏ BIND ra khỏi câu chuyện thì nó không khó đến thế