OPERATIONAL SCENARIOS FOR DNS AND NS USING BIND (ISC)

"It is always the same thing! Administrators and network operators install products as easy as they are drinking water. They do not read the manuals and want that software product works as a miracle."

System Network Manager

INTRODUCTION

All NS and DNS problems are related to acknowlegment. Please, take this as a suggestion for a study sequence. This is not a statement.

The first step is understand what is the difference between NS and DNS.

The second step é understand the behaviors implemented by a Name Translation Service and its purposes.

The third step is that there is a DNS PROTOCOL, which deals, exclusively, on traffic of request and response datagrams through network and its formats of content and states (not behavior).

The fourth, and last step, is set up a translation service names reliable, understanding the network architecture, remembering that the service is constantly subject to attacks and proned to contamination.

A name translation service is the application that performs the direct and/or pseudo-reverse translations (such as BIND), using a set of tables, and asking other remote services contained within one specific table (hint table and recursive translation).

Any computer running a translate name application is an NS (Name Server), but only that who was delegated directly or indirectly by the DNS root of the Internet will be a DNS (Domain Name System). Thus, the DNS is a state delegation acknowledged assigned to NS, because that NS is part of the Internet Domain Name System.



Being a DNS indicates that NS has authority in their answers about one or more zones. That is, any DNS is a NS, but that same NS may not be a DNS for another zone.

One NS can be configured to have one or more BEHAVIORS. The most common behaviors are called MASTER, SLAVE and CACHE.

The behavior indicates that one master NS (note that NS is not DNS!) contains the original translation tables (directly and / or pseudo-inverse) for one or more zones.

Usually a ZONE must have tables for direct and reverse translations. In Brazil, one zone should have 2 DNS (Domain Name System) for the direct translation. The REGISTRO.BR tolerates "no reverse translation". In fact, the number of DNS must be at least 2 (1 for the direct translation of the zone, and other one for the reverse translation). However the two translations can be performed by the same NS, but the CACHE MUST be isolated. There is some advantage in having the same redundant nameservers of one ZONE (1 of them located in the nearby network ZONE and another network outside the ZONE).



The DNS direct translation must be reachable via the Internet. The translation service that operates as a cache MUST NOT be reached from from Internet about NS queries, but NS Cache MUST query Internet DNSs!! Note that the NS CACHE IS NOT A DNS!

The DNS of direct or pseudo-reverse translation MUST TRANSLATE ONLY THE ZONES ASSIGNED TO IT (so it is a DNS, otherwise it would be a NS).

Communication between NSs, or between a client and a NS, uses the DNS PROTOCOL. The protocol defines how the request and responses are mounted, signaling authority, recursion, etc., but does not inform questions about behaviors.

Considering these concepts, it is clear that we have 5 NSs providing the translation services:

1 DNS Master for direct translation (It has the original direct translation table)
1 DNS Master for pseudo-reverse tranlation (It has the original pseudo-reverse translation table)
1 DNS Slave for direct translation (It will get copies of direct translation table from Master)
1 DNS Slave for pseudo-reverse translation (It will get copies of pseudo-reverse translation table from Master)
1 NS Cache, working as recursive with access control allowed, ONLY, to truested clients.

WHERE THEY ARE INSTALLED?

Normally, all networks designed with security in mind, protects the INTERNAL networks from Internet through a Packet Filters (erroneously termed as FIREWALL, which is the name given to a SET OF FILTERS: packets, circuits, and applications).



The Slave DNS, located in the DMZ, should be configured to respond only to the names of the zones copied from MASTER. Another SLave DNS is located at outside network. Since this last one query the tables using TCP protocol then the external access MUST BE controlled and monitored. For best protection, it is recommended that the external Slave DNS requests the tables to the DNS Slave located at DMZ. (Yes! It works!)

The NS Master, located in the Internal Network, will feed the DNS slaves with its tables, but should not provide any information beyond that. NS Master MUST NOT BE a DNS! The NS Cache must have the file named.ca slightly modified (including DNS INTERNAL zones) to avoid unnecessary external inquiries related to INTERNAL ZONES, since YOU (administrator) has control over the IPs of your DNS ZONES.

In case of any failure to connect to the Internet, NS CACHE will query the NS MASTER about Internal zones. If the change is not carried out then the whole network will collapse, since internal clients will query the internal NS cache and it will not find the NS MASTER.

ALL network clients should point to one of the DNS of internal zone AND to the INTERNAL NS CACHE, so the client can receive the translation from external systems.

The NS CACHE IS NOT TO BE DEFINED as NS (RR NS) of any INTERNAL ZONE and should NOT be accessed by EXTERNAL requests. The DMZ should have its own NS CACHE. Packet and Application Filters must observe the datagrams of DNS PROTOCOL having the DMZ NS CACHE as destination, ensuring that the ANSWERS are received and external requests are blocked.

None INTERNAL network CLIENT must query the DMZ NS CACHE, since it is subject to malicious actions and must pass by periodic REFRESH of CACHE. DMZ NS CACHE attempts DMZ clients only.

The Packet Filter must have rules blocking packet containing a source address belonging to the INTERNAL or DMZ networks, Multicast and Broadcast datagrams, and must analyse the value of the field of translation datagrams to identify its type (query or response). One DNS Protocol Application Filter MUST check that DNS packet consistency.

DNSSEC

Due to the way the operating PROTOCOL DNS and implementation errors, one vulnerability exploitation results in the possibility of data memory contaminating an NS requester with false translations, even with all the precautions above. The weakness is in explored NSs with recursion enabled.

A malicious element attempts to infect target system (usually a misconfigured DNS or NS CACHE with recursion enabled). He knows that this contamination will be temporary. So he asks the NS CACHE target on the translation of the name, eg a portal from a bank. Immediately after that request it sends a fake set of responses containing the address of the NS configured maliciously, which contains, for example, a fake site of a bank.

Any NS Client CACHE target ordering the same translation on that period of contamination will receive the false translation and may have the credentials stolen.

Understanding such scenario, the solution was to "authenticate" the answer. For this, the DNS database must enter a set of keys ZSK (Zone Signed Key, temporary) and KSK (Key Signing Key, long period). The ZSK authenticates ZONE translation while KSK authenticates DNS. That is, a real translation will be certified by the ZONE key, which will be certified by the DNS key for all DNS chain. Such endorsements are reviewed before the requisition of other translations, that is not related to the translation of the name of the Bank's website, for example.

This way, that forgery translation can be detected and fraud avoided. Thus, ICANN recommends, motivates and requests that the DNS ZONE be configured with DNSSEC, especially when it requires any confidentiality or financial transaction.

CONCLUDE

So, it is the operational scenario with BIND (ISC)??. Other alternatives are:
a) the installation and configuration of a NS FORWARDING for a second semi-militarized DMZ, or
b) the installation and configuration of a Proxy-DNS.

Any comments? Contact us!