497 lines
18 KiB
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 -> server (named) port 53
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
Response:
|
|
server port 53 -> client same port that request was sent from
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
name server to name server:
|
|
53 -> 53
|
|
53 <- 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 & 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 & 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 ©</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%"> </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%"> </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%"> </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 ========================================================= -->
|