BỘ THÔNG TIN VÀ TRUYỀN THÔNG
TRUNG TÂM INTERNET VIỆT NAM - VNNIC

Kỹ thuật ánh xạ số điện thoại - DNS

Ánh xạ số điện thoại E.164 vào hệ thống DNS là nền tảng của ENUM, nó cho phép sử dụng hệ thống quản lý phân cấp của DNS, các thủ tục truy vấn Internet đã phát triển để mở rộng nội dung thông tin chứa trong cùng 1 số điện thoại, vốn vẫn được coi là duy nhất, và thường được coi là tương ứng gần nhất đối với 1 chủ thể. Với 1 số điện thoại ứng với một cá nhân nào đó, thông qua các phép truy vấn (giống như tra cứu danh bạ, trang vàng) có thể tìm được rất nhiều các thông tin liên quan. Ở đây chỉ khác là hệ thống lưu trữ thông tin là hệ thống DNS được sửa đổi, phép truy vấn là thủ tục DNS đã rất phát triển. Với thế mạnh của dịch vụ Internet, các truy vấn dựa trên DNS được coi là rất dễ triển khai và ứng dụng.

Như vậy với ENUM, có thể thấy viễn thông và Internet đã có điểm hội tụ. Trong tài liệu này còn có thể tìm thấy rất nhiều điểm hội tụ khác nữa giữa 2 lĩnh vực này.

Một cách vắn tắt, để tìm được tên miền tương ứng với một số E.164 nào đó, các bước sau sẽ được thực hiện:

I. Các bước định dạng truy vấn ENUM

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 IDDD[1], theo dạng (VD): +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

Trong hệ thống tên miền, người ta sử dụng một trường dữ liệu đặc biệt là trường NAPTR để chỉ ra các cách 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ó.

Việc xử lý các trường NAPTR được thực hiện thông qua một thuật toán gọi là thuật toán NAPTR, đầu vào của thuật toán này là chuỗi thể hiện số E.164 theo định dạng như định nghĩa trong bước 2 của quá trình chuyển đổi nói trên, tức là chuỗi đầu vào có dạng: "+8448226115"

II. Cấu trúc của trường NAPTR

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ụ 1

$ORIGIN 5.1.1.6.2.2.8.4.4.8.e164.arpa.

IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:hmcuong@hmcuong.vnnic.net!" .

IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:hmcuong@vnnic.net!" .

IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+8448226115!" .

IN NAPTR 100 10 "u" "ldap+E2U" "!^+84(.*)$!ldap://ldap.vnnic.net.vn/cn=01!" .

III. Ý nghĩa của các trường trong cấu trúc NAPTR

1. Trường "thứ tự" (order) là một số nguyên không dấu 16 bit, được bắt buộc sử dụng khi có nhiều bản ghi NAPTR được trả về trong cùng 1 dữ liệu phản hồi. Khi đó bản ghi NAPTR có thứ thự nhỏ hơn sẽ được sử dụng.

2. Trường "độ ưu tiên" (preference) là một số nguyên không dấu 16 bit, được sử dụng (nên) khi nhiều bản ghi NAPTR được trả về, có cả thứ tự giống nhau. Trường này tương tự như trường độ ưu tiên trong bản nghi 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.

3. Trường "cờ": (flag) là 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ữ liệu trả về là một URI.

4. Trường "dịch vụ" (service) là một chuỗi ký tự, 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ế".

5. 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. Cú pháp của trường này sẽ được bàn đến sau, thông qua các thuật toán của thủ tục DDDS

6. Trường "thay thế" (replacement) có thể là một tên miền mới để truy vấn tuỳ 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).

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

Đầu vào của thuật toán là một chuỗi số E.164 được mã hoá theo đị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]

Dịch vụ hỗ trợ cuộc gọi là E2U

Xem xét lại Ví dụ 1, ở đây chỉ dùng cờ "u" để chỉ ra kết quả là các URI, một số các dịch vụ được sử dụng là :

- Dịch vụ SIP (thủ tục tra cứu SIP URI được định nghĩa trong [RFC2543]), dịch vụ phân giải sử dụng là "sip+E2U", trường regexp chỉ ra rằng số E.164 đầu vào sẽ được thay thế hoàn toàn bằng một chuối SIP URI là "sip:hmcuong@hmcuong.vnnic.net", và như vậy ứng dụng SIP sẽ có thể thực hiện các truy vấn tiếp theo để kết nối tới đầu cuối SIP tương ứng

- Dịch vụ email sử dụng dịch vụ phân giải "mailto+E2U", trả về chuỗi URI của dịch vụ mail là: "mailto:hmcuong@vnnic.net", và như vậy ứng dụng thư điện tử sẽ có được một URI mới để thực hiện các truy vấn tiếp theo (trong trường hợp này ứng dụng sẽ thực hiện truy vấn DNS thông thường để tìm bản ghi MX tương ứng với tên miền "vnnic.net", và thực hiện việc chuyển email...)

- Dịch vụ telephone sử dụng dịch vụ phân giải "tel+E2U", nói chung có thể trả về một số điện thoại bất kỳ ứng với khả năng kết nối của đầu cuối bị gọi (Ví dụ có thể trả lại số ISDN thay vì số telephone thông thường). Tuy nhiên có trường hợp trả về đúng với số đầu vào (ở đây là 8448226115) thì có thể bị lặp (tức là có thể sẽ lại bắt đầu chu trình truy vấn từ số này, sử dụng tất cả các chu trình nói trên một cách vô định). Ứng dụng đầu cuối có trách nhiệm xử lý các trường hợp lặp này.

Dịch vụ thư mục (directory) dùng để tìm kiếm thông tin kiểu trang vàng, sử dụng thủ tục LDAP với dịch vụ phân giải là "ldap+E2U". Trong trường hợp này, thuật toán trả về chuỗi URI cho phép sử dụng LDAP để truy vấn thông tin. Với các số E.164 có mã quốc gia là 84 thì ứng dụng có thể sử dụng truy vấn tiếp theo là truy vấn LDAP tới máy chủ thư mục có địa chỉ là "ldap.vnnic.net.vn" với URI là "ldap://ldap.vnnic.net.vn/cn=01 "