A DNS Message Format contains 5 sections

+---------------------+ | Header | +---------------------+ | Question | +---------------------+ | Answer | +---------------------+ | Authority | +---------------------+ | Additional | +---------------------+

the question for the name server RRs answering the question RRs pointing toward an authority RRs holding additional information

1. Header - Includes: 1. Bits 0-15 are the query identifier 2. Bit 16 - QR bit, The message is a query if the value is 0. The message is a response if the value is 1/ 3. Bits 17-20 - Opcode values - Identifies the query type. The message is a standard query if 0, The message is an inverse query if 1, The message is a server status request if 2. 4. Bit 21 - AA - Authoritative answer - If set, it indicates the responding name server is an aurhority for the domain name in question. 5. Bit 22 - TC - Indicates the message was truncated. 6. Bit 23 - RD - Recursion Desired - Set in a query and indicates the query should be persued recursively. 7. Bit 24 - RA - Recursion Available - A bit that is set or cleared in a response indicating that recursion is available. 8. Bit 25-27 - Z - Future use, required to always be 0 9. Bit 28-31 - RCODE - Response code - No error if 0, Format error if 1, Server failure if 2 10. Word 3 - QDCOUNT - Indicates the number of DNS querise (entries in the question section) 11. Word 4 - ANCOUNT - Indicates the number of answers (Resource records in the answer section) 12. Word 5 - NSCOUNT - The number of name server records in the authority records section. 13. Word 6 - ARCOUNT - The number of resource records in the additional records section. 2. Question - Includes: 1. QNAME - Domain name strings with a length byte followed by a string of the designated length. 2. QTYPE - Two bytes indicating the query type 3. QCLASS - Two bytes indicating the class field such as IN for internet. 3. Answer - Resource Records (RRs) answering the question 1. NAME - domain name 2. TYPE - Two bytes with resource record type.

3. CLASS - Two bytes indicating the class of the data 4. TTL - A 32 bit unsigned integer indicating the time interval in seconds that the may be stored on the DNS server. 5. RDLENGTH - 16 bits indicating the length of the RDATA field in bytes. 6. RDATA - This may be the IP address for a domain name but the information varies depending on the type and class of the resource record. 4. Authority - Resource Records (RRs) pointing to an authority - The format is the same as the Answer section. 5. Additional - Resource Records (RRs) holding additional information - The format is the same as the Answer section.

Common way of attack on DNS

* Denial-of-service (DoS) attacks: DoS attacks occur when DNS servers are flooded with recursive queries in an attempt to prevent the DNS server from servicing legitimate client requests for name resolution. A successful DoS attack can result in the unavailability of DNS services, and in the eventual shut down of the network. * Footprinting: Footprinting occurs when an intruder intercepts DNS zone information. When the intruder has this information, the intruder is able to discover DNS domain names, computer names, and IP addresses which are being used on the network. The intruder then uses this information to decide on which computers he/she wants to attacks. * IP Spoofing: After an intruder has obtained a valid IP address from a footprinting attack, the intruder can use the IP address to send malicious packets to the network, or access network services. The intruder can also use the valid IP address to modify data. * Redirection: A redirection attack occurs when an intruder is able to make the DNS server forward or redirect name resolution requests to the incorrect servers. In this case, the incorrect servers are under the control of the intruder. A redirection attack is achieved by an intruder corrupting the DNS cache in a DNS server that accepts unsecured dynamic updates.

Scenario 1 - Intranet Deployment

Let us reconsider the scenario discussed in Section 2. CMU can deploy AVES to restore bidirectional connectivity within the CMU intranet so that DSL users will be able to access their home computers directly from any host within the CMU intranet. To do so, CMU would deploy waypoints and upgrade its local DNS servers to make them AVES-aware. By upgrading the local DNS servers, initiator-specific bindings can be created easily since an initiator's IP address is now available in the IP headers of its DNS queries to the AVES-aware local DNS servers.

Figure 5: Control path operations for intranet deployment Figure 5 shows how this scheme works. Under this scheme, reusable-IP networks will use a common domain name suffix, say aves.cmu.edu, for easy identification. In our example, the reusable-IP network has a domain name home1.aves.cmu.edu. are upgraded AVESaware local DNS servers. The control path operations are as follows. Initiator 's DNS query for is directly sent to one of the AVES-aware local DNS servers, (step 1). is by configuration aware of the IP address of the AVES-aware NAT gateway and the reusable-IP address of . Upon receiving the DNS query, selects at random a waypoint among a set it (step 2). The SETUP message

knows, in this case contains . When ,

, and sends a SETUP message to

, and

, which are necessary to create a data path translation table entry on

receives the SETUP message, it examines its data path translation table to see if it on more compactly by , NAT gateway

can accept the request. Let us denote a translation table entry . Then, , and responder if and only if,

can accept the request for initiator

That is, if

already has a translation table entry for initiator

, and the responder of that entry

is not the same as the one in the SETUP message, then

must reject the request and reply with

a REJECT message because cannot be used to relay a particular initiator to more than one responder. On receiving a REJECT message, for simplicity, the AVES-aware DNS server will simply do nothing and let the initiator perform the DNS name lookup again to retry. In our example, the admission control criterion is satisfied, so accepts the request, creates the corresponding translation table entry, and sends back an ACCEPT message (step 3). Finally, when receives the ACCEPT message, it responds to 's DNS query for with the IP address

of the selected waypoint, , with the time-to-live field set to zero (step 4). Note that the messages between waypoints and the AVES-aware DNS servers are authenticated to prevent unknown sources from gaining control of the system. Also, the messages can be lost in the network. Waypoint failure and packet loss are simply handled by initiator 's DNS query timeout/retry mechanism. Limitations of this scheme are discussed in Section 6.

Scenario 2 - General Deployment

There are two major disadvantages of the previous deployment scheme. First, reusable-IP hosts are still unreachable from hosts that do not belong to CMU's intranet. Second, deployment requires upgrading CMU's local DNS servers and thus requires CMU's consent. It is possible to overcome both of these short-comings by using a technique called delayed binding at the expense of lowered performance. The basic idea is that, a waypoint does not need to know the identity of the initiator to accept a request. It can accept the request optimistically and wait for the connection from the initiator to arrive, and only at that time admission control is performed and the actual binding is created. Under this scheme, reusable-IP networks will use a common domain name suffix that is independent of any organization, say avesnet.net. Waypoints and AVES-aware DNS servers are independently deployed for the avesnet.net domain. No upgrade to any existing DNS server is needed. When a DNS query is received by an AVES-aware DNS server for
avesnet.net,

although the initiator's IP address (

) is no longer known, the AVES-aware , ,

DNS server can still select a waypoint

and send it a SETUP message containing

and

(the IP address of the initiator's local DNS server). Without knowing

can no

longer perform the admission control test stated in Section 3.3.1. However,

can make use of

whatever information it has and decide whether to accept the request (in the simplest case, always accepts the request). If accepts the request, it replies with an ACCEPT message, and , and executes the algorithm

immediately enters a wait state for a short period of time, shown in Figure 6. During this time, requests are serialized.

does not accept other in-coming SETUP requests. Thus,

Figure 6: Waypoint wait state algorithm for general deployment In summary, during this wait state, when a new connection from some initiator (indicated by a TCP SYN packet or any non-TCP packet), arrives is

is potentially the initiator that

waiting for. Thus, checks to see if violates the admission control criterion (note that in Figure 6 denotes a waypoint translation table entry as defined in Section 3.3.1). If so, the packet must be rejected, and is recorded in the set of violators. If later a new connection from

initiator arrives, and does not violate the admission control criterion, and has no existing translation table entry for , then a new translation table entry is created for and bound to responder . Upon exiting the wait state, connections from initiators in must be rejected for a should not

time period to force these initiators to retry their connections. Note that be too large or it may negatively affect future requests from the same initiator.

We have fully implemented delayed binding in our prototype system and it works well (see Section 5 for details). Since this technique is independent of organizational boundaries, it is

actually feasible for our prototype system to provide service to reusable-IP networks outside of CMU. One disadvantage of delayed binding is that connections need to be retried whenever an admission control violation is committed. Fortunately, when the number of waypoints is greater than the average number of simultaneous sessions opened by an initiator, the chance of this can be kept small. Another disadvantage is that the peak rate at which the whole system can accept new sessions is limited to sessions per second, where is the number of IP addresses

assigned to waypoints. Our prototype system, with 50 IP addresses and a of 2 seconds, can accept 25 sessions per second. While this is quite reasonable for CMU's DSL users, we do not advocate the use of our system to serve a popular web server.