Linux Network Administrator's Guide, Second Edition by Olaf Kirch and Terry Dawson Unconfirmed error reports are from readers. They have not yet been approved or disproved by the author or editor and represent solely the opinion of the reader. This page was updated February 18, 2003. Here's a key to the markup: [page-number]: serious technical mistake {page-number}: minor technical mistake : important language/formatting problem (page-number): language change or minor formatting problem ?page-number?: reader question or request for clarification UNCONFIRMED errors and suggestions from readers: [online] 9.8.3; 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: (1) 'pseudo' zones are created under the parent zone (that needs to be split delegated) as needed (2) instead of usual "ptr" entries, the parent zone server has cname entries pointing to entries within this pseudo zone (in an agreed upon manner) (3) the pseudo zones are delegated as needed to the servers that are to provide the split-reverse lookup service (4) the delegated server for the pseudo zone has ptr entries connecting the entries in the pseudo zone to the corresponding hostnames. in the above example, the parent zone is 12.76.149.in-addr.arpa and the two 'pseudo' zones are named 0-29 and 128-29 (in my case, the pseudo zones are not numbers but names that indicate the organization/entity that is using that particular range of ip addresses; the name of these pseudo zones is of course arbitrary). then, the authoritative server for the parent zone delegates these 'pseudo zones' to the name server that is going to provide the split reverse lookups. instead of ptr entries, this parent authoritative server has cname entries for each of the ip addresses in this range mapping to some corresponding names in the pseudo zone. as an example, the reverse lookup file might say 25.12.76.149.in-addr.arpa in cname 25.0-29.12.46.129.in-addr.arpa instead of the ususal in ptr entry pointing to the hostname corresponding to the ip address of 129.46.12.25 (say, euler.foobar.org). in the above, i have assumed the (obvious) agreed upon manner of using the last byte of the ip address (25) as the handle. now the zone 0-29.12.46.129.in-addr.arpa is delegated to an appropriate server; this server, in the zone file for this zone has the in ptr entry like so: 25.0-29.12.46.129.in-addr.arpa in ptr euler.foobar.org where euler.foobar.org is the hostname corresponding to the address 149.76.12.25. please note that i have used loose syntax. in reality, the entries in the files can be much shorter through the use of appropriate $origin directives. the only visible artifact of this is that the reverse lookup always shows an alias containing the handle used in the pseudo zone. (17) Second paragraph, last sentence: "...both upper- and lowercase numbers..." Should be: "...both upper- and lowercase letters...". {22} table 2-1: The ends of the class B and class C address ranges for private networks should be 172.31.255.255 and 192.168.255.255, respectively. They are incorrectly listed in the 11/00 reprint as 172.31.0.0 and 192.168.255.0, respectively. {26} Figure 2-2; Hi. In the diagram of subnetting, you have the FDDI address of the "sophos" gateway as "1.1". Since this is going onto the FFDI backbone, I believe it should be "1.4". It is correct for the gateways "niels" (1.12) and "gcc1" (1.2). If I'm wrong, it just shows why I bought the book! (35) Kernel Configuration - 2nd paragraph; "Think of it as a right of passage" should read "Think of it as a rite of passage". [60] In the following text: "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." (77) Second sentence of footnote: read: "and STMP worlds...." should read: "and SMTP worlds...." {83} 5th paragraph under Checking the ARP Tables; #arp -a the last line where the book indicates it is the address of vlager 172.16.2.4 which is not according to the /etc/hosts file in page 68, I am assuming this IP address should be 172.16.1.1 (140) Second paragraph, third sentence: "...the left-most bit corresponds to ASCII 32...." should be "...the left-most bit corresponds to ASCII 31...." (150) Second to last paragraph: The example shows a holdoff of 10 minutes but the text of the paragraph says the holdoff is 5 minutes. (155) In the listing of IP filtering criteria; The second item is:x * Socket number ( for TCP/UPD ) It should be: * Socket number ( for TCP/UDP ) change UPD to UDP( User Datagram Protocol ) (173) In the next to last paragraph; The text uses the wrong option when describing how to invoke verbose form. Instead of -u, it should be -v. [174] 4th paragraph, example of ipchains commands; 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. {198} Error in two firewall rules; Two rules have "deny", "DENY", these should be "DROP": # We want to deny incoming access by default $IPTABLES -P FORWARD deny should be # We want to deny incoming access by default $IPTABLES -P FORWARD DROP and # SMURF # Disallow ICMP to our broadcast address to prevent "Smurf" style attack. $IPTABLES -A FORWARD -m multiport -p icmp -i $ANYDEV -d $OURNET -j DENY should be # SMURF # Disallow ICMP to our broadcast address to prevent "Smurf" style attack. $IPTABLES -A FORWARD -m multiport -p icmp -i $ANYDEV -d $OURNET -j DROP (204) 1st paragraph: "TCB-based" should be: "TCP-based" (207) In the last paragraph of section "Accounting by Protocol", first sentence: IMCP should be: ICMP (328) 2nd paragraph: The sendmail.df file should be sendmail.cf. (345) 1st paragraph of section "The Real-time Blackhole List": MAPS is the Mail Abuse Prevention System, not the Mail Abuse Protection System. (375) figure 20-1: the host gargleblaster.com is misspelled as garglebaster.com. [381] In the first set of commands (toward the bottom of the page): 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? (416) In the fourth paragraph: the keyword should be mta, not organization. organization was described in the preceding paragraph.