Errata

I am not sure whether I understand this correctly, but here is my comment in any case:

In the sample given to allow users to access WWW servers:

# Rule seems unneccesary - already included in iptables -P FORWARD DROP
iptables -A FORWARD -m tcp -p tcp -s 0/0 --sport 80 -d 172.16.1.0/24 --syn -j DROP

# Connections coming from the local side are made from a high, unknown port number, not 80 - otherwise only root would have been ab
le to browse.
iptables -A FORWARD -m tcp -p tcp -s 172.16.1.0/24 --sport 80 -d 0/0 -j ACCEPT

# Again -s 0/0 is redundant. --dport should be --sport
iptables -A FORWARD -m tcp -p tcp -d 172.16.1.0/24 --dport 80 -s 0/0 -j ACCEPT

{Chapter 15} The book says:

"Alan Cox first developed IPX support for the Linux kernel in 1985"

I believe the Linux Kernel (version 0.01) was released sometime around
1991. Perhaps the date should be 1995 instead of 1985.

[online version] http://www.linuxdoc.org/LDP/nag2/x15291.html#AEN15394;
Regarding the example:

friends@cybermail.com REJECT
aol.com REJECT
207.46.131.30 REJECT
postmaster@aol.com OK
linux.org.au RELAY

It states that: The next rule would accept email from postmaster@aol.com
despite the fact that the domain itself has a reject rule.

This is not true. As long as aol.com is listed as REJECT, emails from
postmaster@aol.com will be rejected, because host checking is done in
check_relay ruleset, while MAIL address checking is done in check_mail
ruleset. Failing either ruleset will lead to denied access.

[http://www.linuxdoc.org/LDP/nag2/x-087-2-resolv.howdnsworks.html#X-087-2-
RESOLV.DNS.LOOKUPS]

There is a reference to non-existent picture:

http://www.linuxdoc.org/LDP/nag2/OREILLY.BIND.DIAGRAM.gif.
in my opinion this should be:

http://www.linuxdoc.org/LDP/nag2/lag2_0801.jpg instead.

[chapter 6] I have read online on the Linux Documentation Project site.
In chapter 6, How DNS Works, Reverse Lookups, it is written that concerning
in-addr.arpa system zones "An even more severe restriction is that these
networks' netmasks have to be on byte boundaries.[...] However, if the
netmask were 255.255.255.128 instead, creating zones for the subnet
149.76.12.128 would be impossible, because there's no way to tell DNS that
the 12.76.149.in-addr.arpa domain has been split into two zones of
authority[...]"
I believe that's not true and that you can delegate such zones using :
0-29.12.76.149.in-addr.arpa and 128-29.12.76.149.in-addr.arpa to register
the NS for both zones in the parent DNS ("-29" stands for 29 bits in the
address mask).
The domain I belong to works this way.

{chapter 6} last paragrapah of section 6.2.4;
this has already been reported as a serious technical mistake; i believe it
is actually only a minor technical mistake. this is regarding delegation of
reverse lookup zones. the book says more-or-less-correctly that split
delegation within a byte is not possible. (i.e.) reverse lookup delegation
has to be for the whole 256 ip addresses in a block as a zone. however,
there is a well known kludge that can be used to accomplish this type of
split delegation. though an example is given by the previous errata report,
vital details are missing and the explanation given is wrong. i quote from
the previous errata report.

"I believe that's not true and that you can delegate such zones using
:0-29.12.76.149.in-addr.arpa and 128-29.12.76.149.in-addr.arpa to register
the NS for both zones in the parent DNS ("-29" stands for 29 bits in the
address mask). The domain I belong to works this way."

A better description of the kludge is as follows:

"Example 4-6 shows a very simple mgetty configuration file. This example
configures two serial devices. The first, /dev/ttyS0, supports a
Hayes-compatible modem at 38,400 bps. The second, /dev/ttyS0, supports a
directly connected VT100 terminal at 19,200 bps."

the second reference to /dev/ttyS0 should read /dev/ttyS1.
So the last sentence should read:

"The first, /dev/ttyS0, supports a Hayes-compatible modem at 38,400 bps.
The second, /dev/ttyS1, supports a directly connected VT100 terminal at
19,200 bps."

The discussion of the sample code doesn't make sense to me unless there is a missing line like:
ipchains -A input -p icmp -j ACCEPT
The line would be the sixth line of the sample.

[188-190; sec 9.9 online] "TOS Bit Manipulation"

I don't have a physical copy of the book, so I'm referencing the location via the
section (9.9 --- TOS Bit Manipulation). It's also not so much a "mistake" as much as
being significantly overtaken by events.

TOS bits were obsoleted by RFC 2474, in December of 1998. (So this part of the book
was out-of-date at the time when it was published). The real problem though is that
lowest two bits of the TOS byte were claimed for use by the ECN by RFC 2481,
published in January 1999, and supported by the Linux 2.4 kernel.

TOS bits are commonly in used by large parts of the Linux community, in particular
0x10 (for high throughput/interactive traffic) and 0x08 (for bulk traffic), which is
set by ssh/scp automatically. So recommending that the TOS bits be used is not
necessarily bad, since there doesn't seem to be any other recommended code points for
the differentiated services code points that are in common use.

However, the problem comes when this section recommends the use of TOS value 0x02,
for "minimum cost" for the NNTP and SMTP protocols. This is REALLY BAD, since the
two low bits are now reserved by the ECN protocol, and in particular, 0x02 is the the
"ECN Capable Transport" bit, and advertises that the host supports the ECN protocol.
Falsely setting this bit may cause routers to try to assume that the host can support
ECN when it can't --- and may result in routers penalizing the hosts that claim to
support ECN when they don't.

The sed line has a low-mark string of 00001 but the following text has
a low-mark string of 000001. Either way, I would have expected the
string to be 0000000001. Does it matter?