old-www/LDP/LG/issue50/tag/1.html

497 lines
18 KiB
HTML

<!--startcut ======================================================= -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<META NAME="generator" CONTENT="lgazmail v1.3B.f">
<TITLE>The Answer Guy 50: DNS Ports: A bit about Name Resolution Protocols</TITLE>
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000"
LINK="#3366FF" VLINK="#A000A0">
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<H4>"The Linux Gazette...<I>making Linux just a little more fun!</I>"</H4>
<P> <hr> <P>
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<center>
<H1><A NAME="answer">
<img src="../../gx/dennis/qbubble.gif" alt="(?)"
border="0" align="middle">
<font color="#B03060">The Answer Guy</font>
<img src="../../gx/dennis/bbubble.gif" alt="(!)"
border="0" align="middle">
</A></H1>
<BR>
<H4>By James T. Dennis,
<a href="mailto:linux-questions-only@ssc.com">linux-questions-only@ssc.com</a><BR>
LinuxCare,
<A HREF="http://www.linuxcare.com/">http://www.linuxcare.com/</A>
</H4>
</center>
<p><hr><p>
<!-- endcut ======================================================= -->
<!-- begin 1 -->
<H3 align="left"><img src="../../gx/dennis/qbubble.gif"
height="50" width="60" alt="(?) " border="0"
>DNS Ports: A bit about Name Resolution Protocols</H3>
<p><strong>From Matt Harrington on Sun, 02 Jan 2000
on the SAGE (USENIX Sysadmin's Guild) list</strong></p>
<!-- ::
DNS Ports: A bit about Name Resolution Protocols
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:: -->
<P><STRONG>
is the following true or false?
</STRONG></P>
<P><STRONG>
a client talks to a nameserver on port 53/tcp. the nameserver
answers back on a random udp port greater than 1023.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
It is false. An FAQ that will answer your question
is at:
</BLOCKQUOTE>
<BLOCKQUOTE><BlockQuote>
<A HREF="http://www.intac.com/~cdp/cptd-faq/section2.html#ports"
>http://www.intac.com/~cdp/cptd-faq/section2.html#ports</A>
</BlockQuote></BLOCKQUOTE>
<BLOCKQUOTE>
... However, I'll also add some detail here.
</BLOCKQUOTE>
<BLOCKQUOTE>
First point: normal DNS resolution occurs over UDP.
</BLOCKQUOTE>
<BLOCKQUOTE>
The usual sequence for a UNIX client is something like
this:
</BLOCKQUOTE>
<BLOCKQUOTE>
The application executes a call to <TT>"gethostbyname()</TT>"
(a standard library function, which is linked into
the libc on almost any UNIX platform). <TT> gethostbyname()</TT>
in glibc (Linux libc version 6.x) is implemented to
look at the contents of your <TT>/etc/nsswitch.conf</TT> file,
and apply a set of rules from that to load NSS (name
services systems) libraries. Most Linux systems are
configured to use libnsscompat.so --- which uses
NIS/NIS+, DNS and traditional UNIX files (<TT>/etc/hosts</TT>,
<TT>/etc/networks</TT>). You can see all of the NSS libraries
on most Linux systems using the command:
</BLOCKQUOTE>
<BLOCKQUOTE><BlockQuote><Code>
ls <TT>/lib/libnss*</TT>
</Code></BlockQuote></BLOCKQUOTE>
<BLOCKQUOTE>
... although you might have to look at the contents of
<TT>/etc/ld.so.conf</TT> for a list of other directories in
which other libnss libraries might exist.
</BLOCKQUOTE>
<BLOCKQUOTE>
Entries in <TT>/etc/nsswitch.conf</TT> will refer to these
libraries (take the basename of the library file and
trim off the "libnss" prefix to relate library name
to the nsswitch.conf keyword).
</BLOCKQUOTE>
<BLOCKQUOTE>
Before I get back to describing the DNS IP protocols
(your question) I'll mention that all this complexity and
redirection is actually useful since it allows an admin
to configure his Linux (or other GNU system) to use
files, DNS, NIS, NIS+, as well as more obscure Hesiod,
and new LDAP and NDS naming/directory services without
having to recompiling any of the standard utilities on
any system.
</BLOCKQUOTE>
<BLOCKQUOTE>
It's also important to realize that the Linux and UNIX
doesn't have any sort of "resolver daemon" nor is this
a function of the kernel (a system call or device driver
or anything like that). This is just a set of libraries
to which almost all other applications are linked.
</BLOCKQUOTE>
<BLOCKQUOTE>
When the system is configured to use DNS (as they
almost all are) then the library functions open and
read the <TT>/etc/resolv.conf</TT> file. This gives a list
of DNS servers to which the resolver will direct its
initial queries.
</BLOCKQUOTE>
<BLOCKQUOTE>
The query will be over UDP, with an arbitrary unprivileged
source port and a destination port of 53 (which is the
DNS query port listed in your <TT>/etc/services</TT> file).
</BLOCKQUOTE>
<BLOCKQUOTE>
The initial response should come from one of the DNS servers
as listed in <TT>/etc/resolv.conf</TT>, and be directed back to
(have a destination port equal to) the source of the query.
The source of the response should also be port 53.
</BLOCKQUOTE>
<BLOCKQUOTE>
Notice that I mentioned "initial" queries and responses.
That's because the DNS protocol allows a server to
refer the client to some other DNS server. Thus there
may be an initial response that amounts to: "I don't
know, go ask ..."
</BLOCKQUOTE>
<BLOCKQUOTE>
Thus the standard packet filtering rules that you're
thinking about require one to allow UDP traffic from
port 53 to any unprivileged port in your domain.
</BLOCKQUOTE>
<BLOCKQUOTE>
Naturally this seems a bit too loose. One approach is
to have the firewall track outstanding DNS requests
maintaining a context state and only permitting responses
back to host/port pairs that have outstanding DNS queries.
This is call "stateful" packet inspection and it is one
of the features that distinguishes a "firewall" from a
simple "packet filter."
</BLOCKQUOTE>
<BLOCKQUOTE>
(Actually I hate to use the term "firewall" because it
is so nebulous. However, I have to simplify a bit or
I can't say anything).
</BLOCKQUOTE>
<BLOCKQUOTE>
A better approach is to configure your caching name
server(s) so they never forward clients to other name
servers. Thus you can have one or more "sacrificial"
caching nameservers on your perimeter network, allow
all DNS traffic to those, and have a set of rules on
the interior router/packet filters that allows all
DNS traffic from those to your hosts.
</BLOCKQUOTE>
<BLOCKQUOTE>
This is the architecture I recommend.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
i can't seem to find the answer in various o'reilly books. of
course, someone walked off with the DNS one.
</STRONG></P>
<P><STRONG>
the reason i ask is that i'm trying to write a cisco access list
which blocks all traffic to my subnet. i still want to talk to
the nameservers though, which are on another subnet. note: i
don't even have access to the router. i'm just trying to make it
easy for the overworked network guys to put this filter in place.
</STRONG></P>
<P><STRONG>
DNS only seems to work if the following line is in place...
</STRONG></P>
<Pre><STRONG>
access-list ### permit udp host ip.of.name.server any gt 1023
</STRONG></Pre>
<P><STRONG>
---matt
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
You could restrict this to require that the packets
come <EM>from</EM> port 53.
</BLOCKQUOTE>
<BLOCKQUOTE>
Implicitly you are trying to use the architecture that
I've recommended above. You're trying to limit the
DNS traffic that comes into your subnet so that it
all comes from a particular name server.
</BLOCKQUOTE>
<BLOCKQUOTE>
Note that this requires that you configure your caching
name server so that it never "forwards" DNS requests
(tells the client to go ask a different server). This
is done by configuring the caching name server with
it's own "forwarders" directive (providing it with a
list of some nearby "better connected" nameservers), and
by using the "slave" directive in BIND 8.x.
</BLOCKQUOTE>
<BLOCKQUOTE>
Hope that explains it O.K. If not you might consider
posting a more detailed question to "Ask Mr. DNS" at
Acme Byte and Wire (<A HREF="http://www.acmebw.com/askmr.htm"
>http://www.acmebw.com/askmr.htm</A>).
</BLOCKQUOTE>
</BLOCKQUOTE>
<!-- sig -->
<!-- end 1 -->
<!-- . . . . . . . . . . . . . . . . . . . -->
<HR WIDTH="40%" ALIGN="center">
<!-- begin 1 -->
<H3 align="left"><img src="../../gx/dennis/bbubble.gif"
height="50" width="60" alt="(!) " border="0"
>DNS Ports: Answers from another Recipient</H3>
<p><strong>Robert Hajime Lanning answered on Sun, 02 Jan 2000
on the SAGE (USENIX Sysadmin's Guild) list</strong></p>
<BLOCKQUOTE>
Hmm. That message was to the SAGE (USENIX Sysadmin's Guild)
(<A HREF="http://www.usenix.org/sage"
>http://www.usenix.org/sage</A>) list, and not to my "Answer Guy"
persona as I'd initially thought.
</BLOCKQUOTE>
<!-- ::
DNS Ports: Answers from another Recipient
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:: -->
<P><STRONG>
DNS is udp not tcp
</STRONG></P>
<P><STRONG>
Zone transfers can be tcp.
</STRONG></P>
<P><STRONG>
Request:
client (libresolv) random above 1023 -&gt; server (named) port 53
</STRONG></P>
<P><STRONG>
Response:
server port 53 -&gt; client same port that request was sent from
</STRONG></P>
<P><STRONG>
name server to name server:
53 -&gt; 53
53 &lt;- 53
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
Mr. Robert Hajime Lanning answered Matt's question before I did.
However, I didn't see that until I got further through my
inbox.
</BLOCKQUOTE>
<!-- sig -->
<!-- end 1 -->
<!-- . . . . . . . . . . . . . . . . . . . -->
<HR WIDTH="40%" ALIGN="center">
<!-- begin 1 -->
<H3 align="left"><img src="../../gx/dennis/bbubble.gif"
height="50" width="60" alt="(!) " border="0"
>More on the DNS Ports &amp; Firewalling Question</H3>
<p><strong>Jim Duncan answered on Sun, 02 Jan 2000
on the SAGE (USENIX Sysadmin's Guild) list</strong></p>
<!-- ::
More on the DNS Ports &amp; Firewalling Question
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:: -->
<P><STRONG>
Matt Harrington writes:
is the following true or false?
</STRONG></P>
<P><STRONG>
a client talks to a nameserver on port 53/tcp. the nameserver answers
back on a random udp port greater than 1023.
</STRONG></P>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
False. The nameserver should answer back to the source port of the query.
</BLOCKQUOTE>
<P><STRONG><IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
i can't seem to find the answer in various o'reilly books. of course,
someone walked off with the DNS one.
</STRONG></P>
<P><STRONG>
the reason i ask is that i'm trying to write a cisco access list which
blocks all traffic to my subnet. i still want to talk to the nameservers
though, which are on another subnet. note: i don't even have access to
the router. i'm just trying to make it easy for the overworked network
guys to put this filter in place.
</STRONG></P>
<P><STRONG>
DNS only seems to work if the following line is in place...
</STRONG></P>
<Pre><STRONG>
access-list ### permit udp host ip.of.name.server any gt 1023
</STRONG></Pre>
<BLOCKQUOTE><IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
HEIGHT="28" WIDTH="50" BORDER="0"
>
RFC 2181, Clarifications to the DNS Specification, says:
</BLOCKQUOTE>
<Blockquote>
<BlockQuote>
4.2. Port Number Selection
</BlockQuote></BlockQuote>
<Blockquote><Blockquote>
Replies to all queries must be directed to the port from which they
were sent. When queries are received via TCP this is an inherent
part of the transport protocol. For queries received by UDP the
server must take note of the source port and use that as the
destination port in the response. Replies should always be sent from
the port to which they were directed. Except in extraordinary
circumstances, this will be the well known port assigned for DNS
queries [RFC1700].
</Blockquote></Blockquote>
<BLOCKQUOTE>
So this means if the query came in to port 53 from source port nnnnn, it
must go back out to port nnnnn, source port 53. And almost always, the
destination port inbound and source port outbound will be 53.
</BLOCKQUOTE>
<BLOCKQUOTE>
If your goal is to allow outside resolvers and servers to query your own
name servers, then you need to allow port 53, both UDP and TCP, through to
the IP address of your name server, e.g.,
</BLOCKQUOTE>
<blockquote><pre> access-list ### permit udp host ip.of.name.server eq domain any
access-list ### permit tcp host ip.of.name.server eq domain any
</pre></blockquote>
<BLOCKQUOTE>
Why tcp? Because if the response is too large for a UDP packet, the rules
say to retry using TCP. Also, TCP is typically used for zone transfers.
</BLOCKQUOTE>
<BLOCKQUOTE>
Some folks know the second rule but not the first -- a little knowledge is
a dangerous thing -- and so they apply two rules like this:
</BLOCKQUOTE>
<blockquote><pre> access-list ### permit udp host ip.of.name.server eq domain any
access-list ### permit tcp host ip.of.name.server eq domain host secondary.name.server
</pre></blockquote>
<BLOCKQUOTE>
They may have additional lines like the second, one for each secondary
name server providing fallback for their primary zones. But this is wrong
because it neglects the case where TCP is called into play because the UDP
response is too big for a single packet, and then things will begin to
fail in strange ways.
</BLOCKQUOTE>
<BLOCKQUOTE>
I should point out that some folks may never see this behavior because
they never see a response too big for UDP. Also, while there are a small
number of different servers out there, there are a multitude of resolvers,
and many of them are broken or not fully tested for situations like this.
It's possible that if the response it too big, the resolver may break
anyhow, regardless of the access-list configuration on the Cisco router.
</BLOCKQUOTE>
<BLOCKQUOTE>
It's easier, by the way, to provide access as in the first examples I list
above because you're explicitly allowing the access to domain name service
on the name server on the inbound interface. That's better than opening
up a huge range of ports, outbound, to do the inverse with "gt 1023".
</BLOCKQUOTE>
<BLOCKQUOTE>
Hope this helps.
</BLOCKQUOTE>
<BLOCKQUOTE>
Jim
</BLOCKQUOTE>
</BLOCKQUOTE>
<!-- sig -->
<!-- end 1 -->
<!--startcut ======================================================= -->
<P> <hr> <P>
<H5 align="center"><a href="http://www.linuxgazette.com/copying.html"
>Copyright &copy;</a> 2000, James T. Dennis
<BR>Published in <I>The Linux Gazette</I> Issue 50 February 2000</H5>
<H6 ALIGN="center">HTML transformation by
<A HREF="mailto:star@starshine.org">Heather Stern</a> of
Starshine Technical Services,
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A>
</H6>
<P> <hr> <P>
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
<TABLE WIDTH="95%"><TR VALIGN="center" ALIGN="center">
<TD colspan="2" rowspan="2"><A
HREF="../lg_answer50.html"
><IMG SRC="../../gx/dennis/answernew.gif"
ALT="[ Answer Guy Current Index ]"></A>
<TD colspan="2" rowspan="2"><A
HREF="../../tag/kb.html"
><IMG SRC="../../gx/dennis/answertoc.gif"
ALT="[ Index of Past Answers ]"></A></td>
<TD WIDTH="11%"><A HREF="../lg_answer50.html#greeting"><img
src="../../gx/dennis/smily.gif" alt="greetings" border="0"></A></TD>
<TD WIDTH="11%"><A HREF="1.html">1</A></TD>
<TD WIDTH="11%"><A HREF="2.html">2</A></TD>
<TD WIDTH="11%"><A HREF="3.html">3</A></TD>
<TD WIDTH="11%"><A HREF="4.html">5</A></TD>
</TR><TR VALIGN="center" ALIGN="center">
<TD WIDTH="11%"><A HREF="5.html">5</A></TD>
<TD WIDTH="11%"><A HREF="6.html">6</A></TD>
<TD WIDTH="11%"><A HREF="7.html">7</A></TD>
<TD WIDTH="11%"><A HREF="8.html">8</A></TD>
<TD WIDTH="11%"><A HREF="9.html">9</A></TD>
</TR><TR VALIGN="center" ALIGN="center">
<TD WIDTH="10%"><A HREF="10.html">10</A></TD>
<TD WIDTH="10%"><A HREF="11.html">11</A></TD>
<TD WIDTH="10%">&nbsp;</TD>
<TD WIDTH="10%"><A HREF="13.html">13</A></TD>
<TD WIDTH="11%"><A HREF="14.html">14</A></TD>
<TD WIDTH="11%"><A HREF="15.html">15</A></TD>
<TD WIDTH="11%"><A HREF="16.html">16</A></TD>
<TD WIDTH="11%"><A HREF="17.html">17</A></TD>
</TR><TR VALIGN="center" ALIGN="center">
<TD WIDTH="10%"><A HREF="18.html">18</A></TD>
<TD WIDTH="10%"><A HREF="19.html">19</A></TD>
<TD WIDTH="10%"><A HREF="20.html">20</A></TD>
<TD WIDTH="10%"><A HREF="21.html">21</A></TD>
<TD WIDTH="11%"><A HREF="22.html">22</A></TD>
<TD WIDTH="11%"><A HREF="23.html">23</A></TD>
<TD WIDTH="11%"><A HREF="24.html">24</A></TD>
<TD WIDTH="11%">&nbsp;</TD>
</TR><TR VALIGN="center" ALIGN="center">
<TD WIDTH="10%"><A HREF="26.html">26</A></TD>
<TD WIDTH="10%"><A HREF="27.html">27</A></TD>
<TD WIDTH="10%"><A HREF="28.html">28</A></TD>
<TD WIDTH="10%"><A HREF="29.html">29</A></TD>
<TD WIDTH="11%"><A HREF="30.html">30</A></TD>
<TD WIDTH="11%"><A HREF="31.html">31</A></TD>
<TD WIDTH="11%"><A HREF="32.html">32</A></TD>
<TD WIDTH="11%"><A HREF="33.html">33</A></TD>
</TR><TR VALIGN="center" ALIGN="center">
<TD WIDTH="10%"><A HREF="34.html">34</A></TD>
<TD WIDTH="10%">&nbsp;</TD>
<TD WIDTH="10%"><A HREF="36.html">36</A></TD>
<TD WIDTH="10%"><A HREF="37.html">37</A></TD>
<TD WIDTH="11%"><A HREF="38.html">38</A></TD>
<TD WIDTH="11%"><A HREF="39.html">39</A></TD>
<TD WIDTH="11%"><A HREF="40.html">42</A></TD>
<TD WIDTH="11%"><A HREF="41.html">41</A></TD>
</TR><TR VALIGN="center" ALIGN="center">
<TD WIDTH="10%"><A HREF="42.html">42</A></TD>
<TD WIDTH="10%"><A HREF="43.html">43</A></TD>
<TD WIDTH="10%"><A HREF="44.html">44</A></TD>
<TD WIDTH="10%"><A HREF="45.html">45</A></TD>
<TD WIDTH="11%"><A HREF="46.html">46</A></TD>
<TD WIDTH="11%"><A HREF="47.html">47</A></TD>
<TD WIDTH="11%"><A HREF="48.html">48</A></TD>
</TR></TABLE>
</TR><TR VALIGN="center" ALIGN="center">
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
<P> <hr> <P>
<!-- begin lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<A HREF="../index.html"
><IMG SRC="../../gx/indexnew.gif" ALT="[ Table Of Contents ]"></A>
<A HREF="../../index.html"
><IMG SRC="../../gx/homenew.gif" ALT="[ Front Page ]"></A>
<A HREF="../lg_bytes50.html"
><IMG SRC="../../gx/back2.gif" ALT="[ Previous Section ]"></A>
<A HREF="../../faq/index.html"
><IMG SRC="../../gx/dennis/faq.gif"
ALT="[ Linux Gazette FAQ ]"></A>
<A HREF="../lg_tips50.html"
><IMG SRC="../../gx/fwd.gif" ALT="[ Next Section ]"></A>
<!-- end lgnav ::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
<!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -->
</BODY></HTML>
<!--endcut ========================================================= -->