25.02.2013 Views

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

TCP/IP Tutorial and Technical Overview - IBM Redbooks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

12.1.13 Transport<br />

Domain Name System messages are transmitted either as datagrams (UDP) or<br />

through stream connection (<strong>TCP</strong>):<br />

► UDP usage: Server port 53 (decimal).<br />

Messages carried by UDP are restricted to 512 bytes. Longer messages are<br />

truncated <strong>and</strong> the truncation (TC) bit is set in the header. Because UDP<br />

frames can be lost, a retransmission strategy is required.<br />

► <strong>TCP</strong> usage: Server port 53 (decimal).<br />

In this case, the message is preceded by a 2-byte field indicating the total<br />

message frame length.<br />

► STD 3 – Host Requirements requires that:<br />

– A Domain Name System resolver or server that is sending a<br />

non-zone-transfer query must send a UDP query first. If the answer<br />

section of the response is truncated <strong>and</strong> if the requester supports <strong>TCP</strong>, it<br />

tries the query again using <strong>TCP</strong>. UDP is preferred over <strong>TCP</strong> for queries<br />

because UDP queries have much lower overall processing cost, <strong>and</strong> the<br />

use of UDP is essential for a heavily loaded server. Truncation of<br />

messages is rarely a problem given the current contents of the Domain<br />

Name System database, because typically 15 response records can be<br />

accommodated in the datagram, but this might change as new record<br />

types continue to be added to the Domain Name System.<br />

– <strong>TCP</strong> must be used for zone transfer activities because the 512-byte limit<br />

for a UDP datagram will always be inadequate for a zone transfer.<br />

– Name servers must support both types of transport.<br />

As <strong>IP</strong>v6 becomes more pervasive throughout the Internet community, some<br />

problems are forecasted as a result of mixed <strong>IP</strong>v4/<strong>IP</strong>v6 network segments.<br />

Primarily, if a resolver that can only use <strong>IP</strong>v4 is forwarded to across a network<br />

segment that supports only <strong>IP</strong>v6, the resolver <strong>and</strong> the name server will be unable<br />

to communicate. As a result, the hierarchical namespace becomes fragmented<br />

into two sets of segments: those that support <strong>IP</strong>v4 <strong>and</strong> <strong>IP</strong>v6, <strong>and</strong> those that<br />

support only <strong>IP</strong>v6. This impending issue has been named the Problem of Name<br />

Space Fragmentation, <strong>and</strong> documented in RFC 3901. In order to preserve<br />

namespace continuity, RFC 3901 recommends the following:<br />

► Every recursive name server should be either <strong>IP</strong>v4 only, or dual <strong>IP</strong>v4 <strong>and</strong><br />

<strong>IP</strong>v6.<br />

► Every DNS zone should be served by at least one <strong>IP</strong>v4-reachable<br />

authoritative name server.<br />

Additional suggestions about configuring <strong>IP</strong>v6 DNS servers are in RFC 4339.<br />

450 <strong>TCP</strong>/<strong>IP</strong> <strong>Tutorial</strong> <strong>and</strong> <strong>Technical</strong> <strong>Overview</strong>

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!