Vì sao DNS truyền thống dễ bị tấn công?
Tưởng tượng bạn gọi tổng đài nội bộ hỏi số phòng của đối tác. Một kẻ xấu chen ngang đường dây, đọc cho bạn số phòng của văn phòng giả mạo. Bạn bước vào và mất sạch tài liệu mật. Giao thức DNS truyền thống hoạt động hệt như vậy.
Mỗi khi truy vấn itfromzero.com, client gửi gói tin UDP qua cổng 53 mà không hề có mã hóa hay xác thực danh tính. Kẻ tấn công trên cùng mạng LAN hoặc cùng router ISP có thể thực hiện kỹ thuật DNS Cache Poisoning. Chúng liên tục bắn các gói tin trả lời giả mạo vào DNS Resolver nội bộ với transaction ID đoán trước. Nếu gói tin giả đến sớm hơn vài mili-giây so với DNS server thật, Resolver sẽ lưu đè IP của hacker vào bộ nhớ đệm (cache).
Hậu quả rất nghiêm trọng. Toàn bộ máy trạm trong công ty khi gõ địa chỉ web mail, ERP hay cổng thanh toán sẽ tự động trỏ thẳng về máy chủ mạo danh. Giải pháp dứt điểm cho lỗ hổng này là triển khai DNSSEC (DNS Security Extensions).
DNSSEC bảo vệ bản ghi DNS như thế nào?
DNSSEC không che giấu dữ liệu truy vấn như DoH (DNS over HTTPS) hay DoT (DNS over TLS). Thay vào đó, nó ký số mã hóa (cryptographic signature) lên từng bản ghi. Bất kỳ resolver nào nhận kết quả cũng có thể tự xác minh: Bản ghi này có đúng do chính chủ xuất bản không? Dữ liệu có bị can thiệp trên đường truyền không?
Bốn loại bản ghi mới trong DNSSEC
- RRSIG (Resource Record Signature): Chữ ký số gắn kèm từng tập bản ghi (A, TXT, MX). Bản ghi này có hạn dùng cụ thể để chống tấn công replay.
- DNSKEY: Khóa công khai (Public Key) đặt tại zone để Resolver dùng giải mã và xác thực chữ ký RRSIG.
- DS (Delegation Signer): Bản ghi băm (hash) của DNSKEY, được lưu ở DNS server cấp trên (ví dụ
.vnhoặc.com). Bản ghi này tạo nên chuỗi tin cậy liên tục (Chain of Trust) từ Root DNS xuống. - NSEC / NSEC3: Bản ghi chứng minh một subdomain không tồn tại mà không làm lộ sơ đồ các subdomain khác trong hệ thống.
Cơ chế tách khóa: ZSK và KSK
Để vừa bảo mật vừa thuận tiện khi vận hành, DNSSEC tách việc ký thành hai tầng khóa:
- ZSK (Zone Signing Key): Khóa dùng định kỳ để ký các bản ghi (A, CNAME, MX). ZSK thường dùng thuật toán ECDSA P-256 hoặc RSA 1024/2048-bit, chu kỳ xoay vòng (key rollover) ngắn từ 30 đến 90 ngày.
- KSK (Key Signing Key): Khóa cấp cao chỉ dùng ký lên bản ghi DNSKEY. KSK có vòng đời dài hơn (1 đến 2 năm). Mỗi lần thay KSK, bạn bắt buộc phải cập nhật lại bản ghi DS tại nhà đăng ký tên miền (Registrar).
Các bước triển khai DNSSEC trên BIND9
1. Bật DNSSEC Validation trên Resolver nội bộ
Nếu server của bạn làm nhiệm vụ phân giải DNS cho mạng văn phòng, hãy kích hoạt tính năng kiểm tra chữ ký số từ các DNS server ngoài Internet.
Mở file /etc/bind/named.conf.options và cấu hình:
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no;
listen-on { 127.0.0.1; 192.168.1.10; }; # Đổi thành IP server của bạn
listen-on-v6 { any; };
};Kiểm tra cú pháp và khởi động lại BIND:
sudo named-checkconf
sudo systemctl restart bind92. Cấu hình ký tự động (Inline Signing) cho Authoritative Server
Từ BIND 9.16 trở lên, cơ chế dnssec-policy giúp quản lý vòng đời và tự động xoay khóa mà không cần viết script cronjob thủ công.
Khai báo policy trong file /etc/bind/named.conf.local:
dnssec-policy "standard-policy" {
keys {
ksk key-directory lifetime unlimited algorithm ecdsap256sha256;
zsk key-directory lifetime 60d algorithm ecdsap256sha256;
};
};
zone "itfromzero.lab" {
type primary;
file "/var/lib/bind/db.itfromzero.lab";
key-directory "/etc/bind/keys";
dnssec-policy standard-policy;
inline-signing yes;
};3. Khởi tạo thư mục khóa và sinh key
Tạo thư mục chứa Private Key và phân quyền chặt chẽ cho user bind:
sudo mkdir -p /etc/bind/keys
sudo chown -R bind:bind /etc/bind/keys
sudo chmod 750 /etc/bind/keysNếu muốn chủ động sinh khóa thủ công bằng dnssec-keygen, bạn chạy lệnh sau (chọn thuật toán 13 – ECDSAP256SHA256 để chữ ký nhẹ và tốc độ xử lý nhanh):
cd /etc/bind/keys
# Sinh ZSK
sudo dnssec-keygen -a ECDSAP256SHA256 -n ZONE itfromzero.lab
# Sinh KSK với flag -f KSK
sudo dnssec-keygen -a ECDSAP256SHA256 -n ZONE -f KSK itfromzero.lab
# Gán quyền đọc file khóa cho BIND
sudo chown bind:bind /etc/bind/keys/K*Tải lại cấu hình zone để BIND tự động ký và xuất file .signed:
sudo rndc reload itfromzero.lab
sudo rndc signing -list itfromzero.lab4. Đẩy bản ghi DS lên Registrar
Để hoàn thiện chuỗi tin cậy, bạn cần đưa bản ghi DS lên nhà cung cấp tên miền (Cloudflare, Namecheap, PA Vietnam, INET,…).
Trích xuất thông số DS từ file public key của KSK:
dnssec-dsfromkey /etc/bind/keys/Kitfromzero.lab.+013+*.keyĐầu ra hiển thị tương tự:
itfromzero.lab. IN DS 2371 13 2 A1B2C3D4E5F67890123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0Điền 4 thông số tương ứng vào trang quản trị DNSSEC của Registrar:
- Key Tag:
2371 - Algorithm:
13(ECDSAP256SHA256) - Digest Type:
2(SHA-256) - Digest: Chuỗi mã băm Hex 64 ký tự ở cuối.
5. Kiểm tra kết quả
Dùng lệnh dig để kiểm tra xem server đã trả về cờ ad (Authenticated Data) và bản ghi RRSIG chưa:
dig @127.0.0.1 itfromzero.lab A +dnssec +multilineNếu cấu hình chuẩn xác, phần header sẽ xuất hiện cờ flags: qr rd ra ad. Đồng thời, ngay dưới bản ghi A sẽ có một khối RRSIG chứa chữ ký số hợp lệ.
Những sự cố thường gặp khi vận hành DNSSEC
DNSSEC chặn đứng giả mạo nhưng cũng rất nhạy cảm với sai sót cấu hình. Dưới đây là 3 lỗi phổ biến nhất khiến toàn bộ domain bị lỗi SERVFAIL:
- Lệch giờ server (NTP Desync): Chữ ký RRSIG luôn có thời gian bắt đầu và kết thúc (Inception/Expiration). Nếu đồng hồ server lệch quá 5 phút so với chuẩn quốc tế, resolver trên thế giới sẽ coi chữ ký là không hợp lệ. Hãy luôn cài đặt
chronyhoặcsystemd-timesyncd. - Quên cập nhật DS khi đổi KSK: Nếu bạn xóa KSK cũ trên server nhưng chưa kịp cập nhật DS mới tại Registrar, chuỗi tin cậy bị đứt. Resolver trên Internet sẽ lập tức chặn truy cập vào tên miền của bạn.
- Private Key bị mất quyền đọc: Khi backup hoặc khôi phục dữ liệu, hãy chắc chắn thư mục
/etc/bind/keysluôn giữ quyền sở hữu thuộc về userbind(hoặcnamedtùy distro).
Quy trình triển khai an toàn nhất là bật DNSSEC validation trên Resolver trước. Sau đó, chạy thử nghiệm trên các domain phụ trước khi áp dụng chính thức cho hệ thống production.
