2.2.1. Định dạng truy vấn ENUM
Một cách vắn tắt, để tìm được tên miền dành riêng cho ENUM tương ứng với một số E.164 nào đó, các định dạng sau sẽ được thực hiện:
1. Số E.164 phải được viết dưới dạng đầy đủ theo quy định của ITU, bao
gồm cả các mã quốc gia IDDD2, theo dạng như +84-4-8226115;
2. Bỏ đi các ký tự không phải số, trừ dấu "+": +8448226115;
3. Bỏ nốt dấu "+": 8448226115;
4. Bỏ dấu chấm "." vào giữa các chữ số: 8.4.4.8.2.2.6.1.1.5;
5. Đảo ngược thứ tự: 5.1.1.6.2.2.8.4.4.8;
6. Thêm chuỗi "e164.arpa" vào cuối:
5.1.1.6.2.2.8.4.4.8.e164.arpa
Mỗi quốc gia khi triển khai ENUM sẽ có một tên miền con (subdomain) trong hệ thống tên miền dành riêng cho ENUM (dưới tên .e164.arpa - tên được coi là
ROOT của tên miền ENUM) và bằng cách này, mỗi thuê bao dịch vụ ENUM sẽ
có được một tên miền riêng tương ứng với số E.164 của mình. Một cách tổng
quát, với định dạng truy vấn ENUM, hệ thống tên miền dành riêng e164.arpa có
cấu trúc phân cấp như sau.
Hình 10. Cấu trúc phân cấp tên miền e164.arpa dành riêng cho ENUM
2
International Direct Dialing Digits
4.8.e164.arpa (Vietnam) 6.8.e164.arpa (China) e164.arpa (ROOT) 2.8.e164.arpa x.x.x....x.6.8.e164.arpa 5.6.e164.arpa 5.1.1.6.2.2.8.4.8.e164.arpa
Với định dạng này, trong hệ thống tên miền người ta sử dụng một loại bản ghi dữ liệu đặc biệt là bản ghi NAPTR để chỉ ra các cách tiếp cận khác nhau khi kết nối tới 1 trạm có định danh nào đó. Nói một cách khác, nó chỉ ra các dịch vụ mà trạm đó có.
Cách khai báo các bản ghi NAPTR trong hệ thống DNS như sau:
ENUM-Domain IN NAPTR order preference flag service regexp replacement
Tên miền IN NAPTR thứ tự mức ưu tiên cờ dịch vụ biểu thức thay thế.
Ví dụ:
$ORIGIN 5.1.1.6.2.2.8.4.4.8.e164.arpa.
IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:tantm@vnnic.net.vn!". IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:tantm@vnnic.net.vn!". IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+8448226115!".
IN NAPTR 100 10 "u" "http+E2U" "!^.*$!http://www.vnnic.net.vn!".
Ta sẽ xem xét ý nghĩa và cấu trúc định dạng, khai báo các bản ghi NAPTR này trong phần sau.
2.2.2. Nguyên tắc xử lý các yêu cầu chuyển đổi số ENUM
Trong xử lý các yêu cầu chuyển đổi ENUM, đầu vào của thuật toán là một chuỗi số E.164 được mã hoá theo các định dạng đã quy định ở trên, đầu ra của thuật toán là một chuỗi định danh tài nguyên thống nhất URI trong dạng thức tuyệt đối của nó theo [RFC2396].
Trường thứ tự trong bản ghi NAPTR sẽ chỉ ra theo thứ tự nào các bản ghi DNS sẽ được giải thích rõ. Đó là vì DNS không đảm bảo thứ tự của các bản ghi trả về trong phần trả lời của một gói tin DNS. Trong phần lớn các trường hợp, ENUM không phải là một sản phẩm bởi vì các biểu hiện thông thường sẽ là '!^.*$!' cho lần truy vấn đầu tiên và như vậy sẽ ảnh hưởng đến luật kết thúc. Tuy nhiên, có những trường hợp khác (những luật chưa kết thúc) tại nơi 2 luật khác nhau và cả hai cùng phù hợp với chuỗi đơn ứng dụng, mục đích của hệ thống là phải tìm ra được một luật có thể phù hợp hơn với một phần của chuỗi đơn ứng dụng so với những luật khác. Ví dụ bằng cách dùng một bản ghi chưa kết thúc NAPTR, một tập các số đưa ra sẽ được gửi tới hệ thống và cùng được chỉ định theo kế hoạch (adsbygoogle = window.adsbygoogle || []).push({});
nếu một luật phù hợp với luật chuyển đổi đầu vào là dịch vụ dùng SIP thì luật định nghĩa SIP sẽ được dùng nhưng nếu luật khác phù hợp với một phần dài hơn của chuỗi đơn ứng dụng lại chỉ ra rằng đầu vào là một ứng dụng khác (như dịch vụ nhắn tin) thì luật sẽ hướng đến một dịch vụ mức cục bộ. Như vậy nếu luật phù hợp ngắn hơn đến trước luật dài, nó có thể che đi các luật khác. Do vậy thứ tự trong đó mỗi luật được kiểm tra lại chuỗi đầu vào là trường hợp mà rất nhiều ứng dụng DDDS tận dụng.
Trong trường hợp cả hai luật có cùng tác dụng hoặc đồng nhất trong ứng dụng thì trật tự cho các bản ghi đó được thiết lập cùng giá trị. Trường hợp này, mức độ ưu tiên được dùng để chỉ ra gợi ý chọn lựa mang tính cục bộ nhờ vào quyền của vùng đó.
Đối với ENUM điều này thể hiện rõ ở đâu một máy trạm được cho phép áp dụng một chính sách địa phương còn ở đâu thì không. Trường thứ tự trong bản ghi NAPTR là một yêu cầu từ phía bên nắm giữ số E.164 rằng các bản ghi đó được sinh ra theo cách cụ thể nào. Trường ưu tiên chỉ đơn thuần là sự đề xuất từ phía nắm giữ số E.164 rằng một bản ghi bản ghi này là tốt hơn so với bản ghi khác. Một vận hành máy trạm đòi hỏi ENUM phải bám vào trường thứ tự, nhưng cũng có thể đơn giản lấy giá trị ưu tiên mà máy trạm chỉ ra phương pháp chọn lựa.
2.2.3. Hệ thống DDDS
Hệ thống dò tìm đại diện tự động (DDDS) là một thành phần cơ bản quan trọng của ENUM. Nó được đưa vào ENUM để giải quyết các vấn đề gặp phải khi thể hiện các tài nguyên gắn kết với số ENUM một cách tối ưu nhất và hỗ trợ các giải pháp chuyển đổi chuỗi số thành dữ liệu động tốt nhất.
DDDS được sinh ra như kết quả của một hướng nghiên cứu mới của nhóm làm
việc chuyên trách của IETF về "tên tài nguyên thống nhất" Uniform Resource
Names (URN) để giải quyết vấn đề: làm thế nào có thể tìm kiếm được thông tin về một URN nếu trong URN không chứa các thông tin định vị dịch vụ mạng (chẳng hạn không chứa tên hoặc địa chỉ máy chủ truy vấn). Một hệ thống được đưa ra có thể sử dụng một cơ sở dữ liệu luật dùng để áp đặt lên URN nhằm tìm ra thông tin trên từng đoạn của URN. Đầu tiên, hệ thống này được gọi là dịch vụ
dò tìm thiết bị truy vấn RDS (Resolver Discovery Service), chỉ dùng được với các URN. Sau này, phương pháp tương tự được áp dụng trên các chuỗi không phải URN và trở thành DDDS.
DDDS được mô tả bởi một hệ thống các tài liệu chuẩn của IETF, gồm 5 phần với các RFC số 3401, 3402, 3403, 3404, 3405. DDDS được định nghĩa đơn giản là một thuật toán tổng quát nhằm áp dụng một luật chuyển đổi chuỗi thu nhận được một cách động lên một chuỗi đơn của ứng dụng. Nói cách khác, DDDS là phương pháp dùng để chuyển đổi chuỗi thành dữ liệu một cách động, sử dụng để hỗ trợ cấu hình động cho các hệ thống uỷ quyền (delegation).
Để làm được việc này, DDDS sử dụng các luật chuyển đổi chuỗi áp đặt tuần tự và lặp lại lên các chuỗi đầu vào cho tới khi điều kiện kết thúc đạt được và ánh xạ kết quả vào các dữ liệu chứa trong cơ sở dữ liệu DDDS.
Việc thực hiện DDDS được mô tả qua thuật toán sau:
Luật bắt đầu (First well known rule)
Tìm khóa trong CSDL DDDS
Áp dụng các luật lên các chuỗi duy nhất cho tới khi kết quả không rỗng nhận được thỏa mãn yêu cầu của ứng dụng
Đầu ra của luật cuối cùng chính là kết quả cần tìm của ứng dụng
Kết thúc luật cuối cùng chưa ?
Chuỗi đầu vào duy nhất của ứng dụng
Khóa đầu tiên Khóa Tập hợp luật Tập hợp luật Khóa Sai Đúng CSDL DDDS luôn nhận 1 khóa và trả về 1 luật
Đầu vào là luật và chuỗi ứng dụng Đầu ra là khóa hoặc kết quả
Nếu luật chưa kết thúc thì đầu ra của nó là khóa mới để áp dụng
tiếp tìm các tập hợp luật khác
Đầu tiên, chuỗi đơn đầu vào của ứng dụng được áp đặt một luật gọi là luật bắt đầu (First Well Known Rule). Luật này do ứng dụng định ra, chứ không phải lấy từ cơ sở dữ liệu. Luật này nhằm tìm ra khoá đầu tiên dùng để truy vấn cơ sở dữ liệu DDDS.
Với khoá tìm được, truy vấn cơ sở dữ liệu DDDS sẽ tìm được luật áp dụng tiếp theo. Luật này áp dụng lên chuỗi đầu vào sẽ cho khoá mới, hoặc cuối cùng là kết quả đầu ra mong muốn.
Để thấy được sự phức tạp của các biểu thức áp dụng trong DDDS, ta xem xét ví dụ sau:
Xem xét 1 URN có định dạng lấy từ MIME3 "Content-Ids" như sau:
urn:cid:199606121851.1@bar.example.com
Để truy vấn thông tin về URN này, ứng dụng thực hiện theo quy ước, ở đây việc đầu tiên là tìm thông tin về dạng dữ liệu MIME bằng cách tìm chuỗi dữ liệu giữa hai dấu ":" đầu tiên. Kết quả thu được là "cid".
Ứng dụng cũng được quy ước trước là với chuỗi thu được, nó phải thêm vào một đuôi "urn.arpa" để có được một khoá tìm kiếm đầy đủ. Khoá ở đây là "cid.urn.arpa".
Với truy vấn tên miền "cid.urn.arpa", ứng dụng thu được một bản ghi NAPTR như sau: (adsbygoogle = window.adsbygoogle || []).push({});
cid.urn.arpa.
;; order pref flags service regexp replacement IN NAPTR 100 10 "" ""
"!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" .
Do ở đây chỉ có 1 trường NAPTR trả về nên không có vấn đề sắp xếp thứ tự ưu tiên. Áp dụng luật thu được trên chuỗi URN ban đầu ta thu được chuỗi "example.com" (thành phần thứ 2 theo như biểu thức thay thế chỉ ra, giữa 2 dấu "!").
3
Truy vấn tiếp tên miền "example.com" ta thu được:
example.com.
;; order pref flags service regexp replacement IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com. IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com.
Chi tiết thêm về thuật toán DDDS tham khảo RFC34024.
Việc phân bố các luật DDDS qua DNS
Để có thể phân bố các luật DDDS một cách hiệu quả và đơn giản, DDDS sử dụng cơ sở dữ liệu DNS như một cơ sở dữ liệu phân bố luật, định nghĩa theo
[RFC3403]5. Các khoá ở đây là các tên miền và các luật được mã hoá bằng các
trường NAPTR. Một truy vấn khóa sẽ có dạng một truy vấn tên miền thông thường, kết quả trả về sẽ là một loạt các bản ghi NAPTR chứa các luật cần truy vấn. RFC3403 cũng đồng thời thay thế cho RFC2915 và được coi là định nghĩa chính thức của NAPTR. Các mô tả chính như sau:
Bộ mã được sử dụng trong các trường của NAPTR là UTF-8. Do đó nếu đầu vào/ đầu ra của các biểu thức có chứa các mã nằm ngoài bộ mã UTF-8 thì phải được biểu diễn bằng các tham chiếu theo kiểu một chuỗi byte để có thể thoả mãn được. Điều này cần được đặc biệt quan tâm khi áp dụng ở Việt Nam do các trường NAPTR được sử dụng có chứa mã tiếng Việt. Tuy nhiên trong khuôn khổ thời gian có hạn, luận văn này sẽ không bàn đến vấn đề mã đa ngữ trong các bản ghi NAPTR.
Tất cả các bản ghi DNS đều được gán một thời gian sống (time-to-live) tính bằng giây. Sau khi bản ghi được lấy về thì nó chỉ có giá trị trong khoảng thời
4
gian bằng time-to-live. Sau thời gian đó bản ghi coi như không còn giá trị và phải được truy vấn lại. Điều này cũng ảnh hưởng tới việc lưu trữ các luật DDDS vì ứng dụng phải đảm bảo là chỉ áp dụng các luật chưa bị quá hạn time-to-live. Nếu luật được áp dụng bị quá hạn, ứng dụng phải bắt đầu lại từ đầu việc áp dụng toàn bộ thuật toán.
Để tìm kiếm 1 tập hợp luật, ứng dụng phải sử dụng một truy vấn DNS tiêu chuẩn để tìm bản ghi NAPTR ứng với tên miền đã cho.
Cấu trúc định dạng, khai báo các bản ghi NAPTR trong hệ thống DNS
Như đã đề cập ở phần trên, cấu trúc khai báo các bản ghi NAPTR trong hệ thống DNS khi được thể hiện một cách đầy đủ có dạng như sau:
ENUM-Domain IN NAPTR order preference flag service regexp replacement
Tên miền IN NAPTR thứ tự mức ưu tiên(lựa chọn) cờ dịch vụ biểu thức thay thế.
Với cấu trúc này, định dạng gói tin NAPTR sẽ bao gồm:
1 15 THỨ TỰ (ORDER) LỰA CHỌN (PREFERENCE) CỜ (FLAGS) DỊCH VỤ (SERVICES) BIỂU THỨC (REGEXP) THAY THẾ (REPLACEMENT)
Hình 12. Định dạng gói tin NAPTR
Ở đây các chuỗi ký tự và tên miền được định nghĩa trong RFC1035.
THỨ TỰ là một số nguyên không dấu 16 bit biểu thị thứ tự mà bản ghi cần được xử lý được sắp xếp từ nhỏ đến lớn để có thể phản ánh đúng thứ tự các luật. THỨ TỰ được bắt buộc sử dụng khi có nhiều bản ghi NAPTR được trả về trong cùng một dữ liệu phản hồi, khi đó bản ghi NAPTR có thứ thự nhỏ hơn sẽ được sử dụng. Các bản ghi có cùng thứ tự được coi là cùng luật và việc xử lý sẽ phụ thuộc vào các trường LỰA CHỌN và DỊCH VỤ.
LỰA CHỌN cũng biểu thị thứ tự ưu tiên trong việc xử lý DDDS, nó chỉ ra thứ tự thực hiện trong trường hợp các trường THỨ TỰ là giống nhau. Ứng dụng có thể tìm các bản ghi có giá trị LỰA CHỌN cao hơn nếu nó muốn (ví dụ trường hợp nó không hỗ trợ tốt dịch vụ hay thủ tục nào đó).
Ứng dụng chỉ được xác định 1 THỨ TỰ để xử lý, trong khi nó có thể thay đổi các bản ghi để có LỰA CHỌN tốt hơn.
CỜ là chuỗi dùng để xác định phương thức viết lại các trường trong bản ghi, do ứng dụng xác định. CỜ được thể hiện dưới dạng một chuỗi ký tự, chứa tham số ảnh hưởng tới lần truy vấn tiếp theo, thường được dùng để tối ưu hoá quá trình truy vấn. Cờ "u" được hiểu là luật này là luật áp dụng để kết thúc chu trình và dữ (adsbygoogle = window.adsbygoogle || []).push({});
liệu trả về là một chuỗi theo chuẩn nhận dạng tài nguyên thống nhất (URI6
). DỊCH VỤ là chuỗi xác định các tham số dịch vụ phù hợp cho hướng chuyển giao này, cũng do ứng dụng xác định. DỊCH VỤ được thể hiện, khai báo trong bản ghi NAPTR dưới dạng một chuỗi ký tự, nó chỉ ra thủ tục phân giải và dịch vụ phân giải sẽ sẵn sàng khi việc viết lại được thực hiện thông qua các trường "biểu thức" và "thay thế".
BIỂU THỨC REGEXP chứa chuỗi thay thế được áp dụng cho chuỗi đầu vào để có được tên miền tiếp theo để truy vấn tiếp. Biểu thức chỉ được áp dụng cho chuỗi đầu vào, chứ không áp dụng cho các chuỗi trung gian trong quá trình xử lý bản ghi.
THAY THẾ là chuỗi sử dụng để thay thế chuỗi trong trường hợp thay thế đơn giản. Cùng với BIỂU THỨC để tạo nên một biểu thức thay thế đầy đủ sử dụng trong DDDS.
Trong bản ghi NAPTR, trường "thay thế" (replacement) có thể là một tên miền
mới để truy vấn tùy theo các giá trị có thể của trường "cờ". Trường này được sử dụng khi trường "biểu thức" là một phép thay thế đơn giản. Bất kỳ giá trị nào của trường này cũng phải là một tên miền đầy đủ (full qualified domain name). Trường "biểu thức" (regexp - regular expression) chứa một chuỗi biểu thức
thay thế mà khi áp dụng vào chuỗi nguyên thuỷ sẽ tìm ra được tên miền nào sẽ được truy vấn tiếp theo.
Ngoài ra, trong các bản ghi NAPTR còn có sử dụng trường "độ ưu tiên" (preference) là một số nguyên không dấu 16 bit, thường được dùng khi có nhiều bản ghi NAPTR được trả về, trong đó có cả các thứ tự giống nhau. Trường này tương tự như trường độ ưu tiên trong bản ghi MX của DNS và được các nhà quản trị sử dụng để lái dịch vụ tới các máy chủ khác có khả năng xử lý tốt hơn.
Một lưu ý là tất cả các quá trình xử lý thay thế và truy vấn đều được ứng dụng thực hiện, bản thân hệ thống DNS không thực hiện tính toán xử lý nào.
Ở đây xuất hiện vấn đề xung đột trong các bản ghi NAPTR. Vì các bản ghi NAPTR trong cùng 1 khoá (một tên miền) có thể được sử dụng cho nhiều dạng ứng dụng khác nhau (ví dụ ENUM và URI có thể cùng truy vấn 1 tên miền nào đó), do đó luật trả về trong các NAPTR có thể sẽ chỉ thích hợp với 1 ứng dụng nào đó và đương nhiên không thích hợp với các ứng dụng còn lại. Cơ chế xử lý là một trong các cách:
Sử dụng các tên miền khác nhau cho các ứng dụng khác nhau.
Biểu thức phải được viết để có thể nhận dạng được ứng dụng truy vấn.