ENUM DNS management issues

DNS server management issue

IPv6 DNS server management issue ENUM DNS server management issue

Is_a Is_a

Is_a

Fig. 3.1: The management hierarchy of general/IPv6/ENUM DNS server

Fig. 3.1 diagrams a simple hierarchy of management issues among general/IPv6/ENUM DNS servers. Just like the object-oriented language class hierarchy, the higher-level class is more general than the lower-level class. As a result, an IPv6 DNS server will inherit the management issues of a general DNS server.

Similarly, the security measures in ENUM DNS servers should be much more

41

reinforced than those in general DNS servers; that is, more resources (e.g., server

hardware, bandwidth, man power, etc.) are supposed to be involved.

Traditional PSTN service should meet the TELECOM carrier level; i.e., high reliability, capacity and speech quality. Therefore, ENUM DNS servers should meet the above criterions as well, which differentiate them from ordinary DNS servers.

Moreover, if an ENUM DNS is located on the IP network, most of the existing network attacks (e.g., DDoS attacks, system compromising, DNS spoofing, etc.) could possibly occur on the ENUM DNS. Since the DNS is the infrastructure of SIP/ENUM, if some ENUM DNS server fails, then the telephone number translation using ENUM DNS server will fail as well. Next, two scenarios will be given for illustrating the main ideas.

3.5.1 Scenario 1: Network attacks on ENUM DNS

In practice, DNS servers not only translate domain names into IP addresses, but also provide MX RR's for mail routing to deliver the mails. Moreover, on many Internet sites (e.g., SOHO people, etc.), all-in-one server (e.g., WWW, SMTP and DNS, etc.) is very common. However, the more unnecessary services are, the higher security threat is. For implementing ENUM DNS, it is supposed that the above situations should be avoided. For example, assume that a company X has its own ENUM DNS with all its subscribers' contacting information to provide the service.

When someone needs to reach some subscribers of X, he/she queries the ENUM DNS to get the related contacting information. Suppose some attacker Y would like to shut down X's services by DDoS attacks. If there is not any protecting mechanism (e.g., DNS, router, etc.), Y might flood the ENUM DNS server with as many packets (e.g., mail, DNS, web, etc.) as possible and make it become un-available or the subscribers

might wait for long time to get new connections.

Generally speaking, to secure the ENUM DNS, we need to take appropriate measures to implement and deploy the system architecture. First, it is necessary to separate other services from the ENUM DNS servers. Second, the ENUM DNS servers should be behind specific routers, separated from other internetworking equipments. Third, firewalls are required for helping filter out unwanted packets.

Finally, network behavior analysis via IDS (Intrusion Detection System) for early detecting the anomalous traffic could help identify possible attack sources in advance.

3.5.2 Scenario 2: DNS spoofing

Assume that a commercial bank X has its own ENUM DNS and provides service phone numbers in its web pages, from which the customers could get expected service information. For example, suppose a phone number, +886-2-23456789, is put on some web page of X and the corresponding E.164 domain name is 9.8.7.6.5.4.3.2.2.6.8.8.e164.arpa. Basically, if some user Z from his/her ISP using DNS server Dz would like to call X's service, the X's ENUM DNS should map the domain name into the sip service, "sip:[email protected]" and return it to Dz for Z's usage.

Now suppose there is no well protection mechanism on X's ENUM DNS, if a bad guy Y would try to get the customers' personal banking information of X by cheating, he might establish another faked site with similar web pages in advance and follow this by conducting DNS spoofing. For example, another different scenario, with DNS spoofing involved, about user Z using DNS server Dz might be as follows.

First, Y would set up his own ENUM DNS server containing some true authoritative data about Y and faked data about X. Second, Y might manage to bring

43

the attention of Dz by using Dz directly (or indirectly via some other legal user of Dz, say, W) to query some domain data about Y. Third, the ENUM DNS of Y will return faked responses containing additional records of X (e.g., an NAPTR of 9.8.7.6.5.4.3.2.2.6.8.8.e164.arpa maps to sip:[email protected]., etc.) to Dz.

Fourth, the poisoned data about X is put into the DNS cache of Dz. Finally, if someone (e.g., the user Z, etc.) using Dz would like to call X's service later, the phone call would be mis-directed and intercepted by Y.

Even though DNS spoofing problems had been identified, and some mechanisms had been proposed and implemented to address the problem on newer versions of DNS software programs; however, most DNS servers on many Internet sites only implement parts of these mechanisms, or even none at all, due to many problems such as performance and ignorance. Moreover, if we would like to adopt the ENUM DNS approach for providing commercial transactions in the future, it is also important to ensure the authenticity and integrity of the data by adopting DNS software with appropriate characteristics, which will be discussed later.

3.5.3 Scenario 3: Mailing errors due to the lack of reverse DNS entries

The mail server of a small company W worked fine for a long period time.

However, due to the cost/performance considerations, the administrator was asked by the boss to move their Internet connection (e.g., originally with a leased line Internet connection) to another new ISP that provided cheaper ADSL links, with their mail domain name(s) kept unchanged. In the first few days, it seemed that all were OK.

However, after that, users started complaining that they had mailing problems. While some users said that their outbound messages to specific destinations got bounced immediately each time, others complained that they got intermittent (e.g. sometimes successful, sometimes failed) bounced messages to many destinations. At first, the

administrator suspected that the remote SMTP hosts might have some unusual (even unreasonable?) changes of the access control mechanisms against their mail host.

However, after contacting many recognized administrators of some remote sites and having discussions with them, he finally got the solution to the problems.

Currently, there is a convention by many Internet sites to block SMTP connections from personal ADSL users since most of the SPAM messages were found to be

injected from personal ADSL and dialup users [LT+03-1] [LT+03-2]. It turned out that their mail server, with a new ADSL link, had a reverse DNS mapping name under the ISP’s ADSL-styled name. After changing it to another one different from the

ADSL-styled format, the problem was fixed.

45