Haha. Mighty good question. No good answer. Derek

-----Original Message----- From: Richard A Steenbergen [mailto:ras@e-gerbil.net] Sent: Thursday, September 05, 2002 1:48 PM To: Derek Samford Cc: 'Owens, Shane (EPIK.ORL)'; nanog@nanog.org Subject: Re: IP address fee??

On Thu, Sep 05, 2002 at 01:36:27PM -0400, Derek Samford wrote:

...

Shane, There is a practice on that (At least here.). Generally we provide a Class C to our customers at no additional charge, but we have

Why in this day and age, 9 years after the invention of CIDR, are we still refering to "class C"'s?

-- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

On Thu, 5 Sep 2002, Richard Welty wrote:

about 2 years ago, interviewing fresh graduates for jobs, i found that they were still being taught classful networking at many colleges.

Current CCNA Exam Description: http://www.cisco.com/warp/public/10/wwtraining/certprog/testing/current_exam... ----------- Network Protocols * Describe the different classes of IP addresses (and subnetting). ----------- not to mention the tested routing protocols are RIPv1 and IGRP. Obviously all the "Get your CCNA in 30 seconds" books (and the official ones) mainly cover classful routing since that is what is tested. however you learn about Classless Routing in the CCNP.. "Key routing information including classful and classless routing protocols ... " -- Simon Lyall. | Newsmaster | Work: simon.lyall@ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon@darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz

On Thu, Sep 05, 2002 at 09:58:08PM -0400, Richard Welty wrote: [snip]

about 2 years ago, interviewing fresh graduates for jobs, i found that they were still being taught classful networking at many colleges.

Only half a year ago a teacher (university, subject: networking) told us (I'm a student) 'netmasks are not really needed, you can always infer them from the class'. By then he had already decided to ignore my corrections.. Greetz, Peter -- peter@dataloss.nl | http://www.dataloss.nl/ | Undernet:#clue

Possibly because that is what they are still teaching them as in school? Seriously... I'm not sure that the teachers I had for networking and systems admin had ever heard of CIDR. The textbooks hadn't. It was a nice bump in the learning curve when I hit the real world. *********** REPLY SEPARATOR *********** On 9/5/2002 at 1:48 PM Richard A Steenbergen wrote:

On Thu, Sep 05, 2002 at 01:36:27PM -0400, Derek Samford wrote:

...

Shane, There is a practice on that (At least here.). Generally we provide a Class C to our customers at no additional charge, but we have

Why in this day and age, 9 years after the invention of CIDR, are we still refering to "class C"'s?

-- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

-- Jeff Shultz Network Support Technician Willamette Valley Internet 503-769-3331 (Stayton) 503-390-7000 (Salem) tech@wvi.com ...most of us have as our claim to fame the ability to talk to inanimate objects and convince them they want to listen to us. -- Valdis Kletnieks in a.s.r

Thus spake "Richard A Steenbergen" <ras@e-gerbil.net>

On Thu, Sep 05, 2002 at 11:00:43AM -0700, Jeff Shultz wrote:

...

Possibly because that is what they are still teaching them as in school?

Seriously... I'm not sure that the teachers I had for networking and systems admin had ever heard of CIDR.

The textbooks hadn't. It was a nice bump in the learning curve when I hit the real world.

I've never seen a text book which had any relevance to modern networking which didn't cover CIDR.

Sadly, most texts I've read, and certainly all the current courseware I've looked at, still teach classful addressing and subnetting as the primary method with a sidebar on CIDR as the "new" method.

Perhaps if we all made a conscious effort to avoid using the term, new people who are learning from the examples they see around them would stop picking up on it as "how things work".

History is nice, but not knowing when to give up and move on is just sad.

The term class C sticks because it's so useful; you'll note that class [AB] aren't used much colloquially. This is how English evolves. S

On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote:

Because "Cee" is easier to pronounce than "slash twenty-four". Ease of use trumps open standards yet again :)

Nobody was talking. "/24" is easier to type than "class C". No trumps! Everybody loses! How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people. If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be "taught" long after it stopped having any relevance. Joe

I have tended as of late to avoid using the term "class A/B/C". Too many people at my job do not understand the meaning and make themselves look stupid. I have instead resorted to using mask be it a /24 or a /27 aka "slash 27" it seems to work well with the people who have some experience. Other you have to train from the binary "11111111.1111111.11111111.00000000". But in the end the classing of addresses has gone the way for EGP "depricated".

I never really used the "Class C" tag because it has rarely been correct at any place I've worked; the first place I worked, we had a class B and used 8-bit subnets of it for departments (before the CIDR notation became popular, the common name seemed to be 8-bit subnets); the next place, we had a /19 CIDR block out of Class A IP space as our primary address space (among 100 other network blocks). In neither case would it be correct to call a /24 a "Class C". Although I do call 203-space networks "Class C", because they are. A class refers to more than just the prefix length, it refers to the location in IP space as well. Classful routing still causes occasional headaches, in that people who don't configure their routers properly may accidentally be unable to reach the whole /8 which contains our /19 (among others, of course). Or if you use RIPv1, any IP outside your defined network statements is automatically advertised as the classful aggregate containing that IP (or doesn't that happen anymore?), causing horrible things to happen (I worked at one Australian university, one of our staff dialed up to another and specified their home static IP via PPP (IPCP), that universities' access server automatically inserted a class B into it's RIP and that university was doing RIPv1 with Telstra, effectively overriding the Australian routing table -- at the time, Telstra _were_ the network -- and black-holing us as they were further east than we were, ie, closer to the international gateway). Although I have to shamefully admit my very small contribution to Zebra was the classful routing assumptions for RIPv1 so we could use it at the university I worked at (in the end it couldn't handle interfaces dynamically appearing/disappearing so we used gated then migrated to a hacked up routed as gated wasn't handling newer Linux variants and I was terminating the student PPTP sessions on my personal workstation running Linux). David.

On Fri, 2002-09-06 at 10:00, Joe Abley wrote:

...

On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote:

...

Because "Cee" is easier to pronounce than "slash

twenty-four". Ease of use

...

...

trumps open standards yet again :)

Nobody was talking. "/24" is easier to type than "class C". No trumps! Everybody loses!

How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people.

If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be "taught" long after it stopped having any relevance.

Joe

-- Manolo Hernandez - Network Administrator Dialtone Internet - Extremely Fast Linux Web Servers phone://954-581-0097 fax://954-581-7629 mailto:manolo@dialtone.com http://www.dialtone.com "The only source of knowledge is experience." - A. Einstein

At 10:00 AM 9/6/02 -0400, Joe Abley postulated:

On Thu, Sep 05, 2002 at 01:13:27PM -0500, Stephen Sprunk wrote:

...

Because "Cee" is easier to pronounce than "slash twenty-four". Ease of use trumps open standards yet again :)

Nobody was talking. "/24" is easier to type than "class C". No trumps! Everybody loses!

How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people.

If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be "taught" long after it stopped having any relevance.

Joe

The class of an address is determined by the bit-pattern of the first octet of the address. 10.0.0.0 will always be a Class A address. 172.16.0.0 will always be a Class B address, and 192.168.0.0 will always be Class C address. I'm not aware of any RFC that rescinded the definition of the Class of an address. Masks, when associated with an address, enable one to determine (a), what network I'm on (if I'm an IP host) or (b) how many addresses exist within a given range of addresses (if I'm a routing table). Subnetting (robbing mask host bits (0's) to make network bits (1's) allowed one to more effectively use the decreasing amounts of networks that required less than the default number of addresses (65,536 in the case of a Class B) by more effeciently using the space one had been allocated. With subnetting, I can take one Classful network and make many (sub)networks from it. There was no way prior to 1993, however, to effectively represent the range of addresses in more than one Classful network. CIDR, simply stated, says that one can use any address with any mask, regardless of the original class of the address, to represent a range of addresses (i.e. rob network bits to make host bits). It allows the properties of IP to be more effectively used for IP host addressing (only need a /23 to support 400 IP hosts (a very effecient 78% use of the allocated space), as well as (one of the original, primary reasons for CIDR) aggregate ("Supernet") "X" traditional Class C's into one routing statement (who today would advertise delivery to the range of 4,096 addresses from, for example, 192.168.192.0 through 192.168.207.255 with 16 individual traditional Class C statements?). Since NANOG is "the front line", then perhaps that is where the oral tradition should be teaching the history of IP addressing, from Classful addressing (default masks) to Subnetting (other than default) to Supernetting (ranges of addresses regardless of original - or legacy if you will - class (Classless)). The prefix, of course, does not refer to the class of the address, but the number of contiguous ones in the mask. As far as pronounciation goes, I prefer "slash 24" to "two fifty five dot two fifty five dot two fifty five dot zero" :) $.02 Ted Fischer

On Fri, Sep 06, 2002 at 11:41:07AM -0500, Stephen Sprunk wrote:

I'd bet most of the customers I deal with learned networking from OS manuals or CCNA study books, all of which still teach classful addressing as the primary method. All of the ones I work with use the term "C" or "class C" to refer to a /24, and all are noticeably slower when dealing with non-/24 masks.

The point of communication is to get an idea across; if most of the people you communicate with don't understand slash notation, then you use terms they're familiar with even if they're imprecise or inaccurate.

I think NANOG's ISP-centric membership may skew the perception of our lexicon's state. Most network operators are not ISPs.

And half the internet's users type "u r kewl", and think that ethernet is a broadband connection. Just because a misconception is popular doesn't mean we should indulge it. :) Think of it as a public service, if you make an effort to say "/24", and someone asks and you explain it, thats one less confused person circulating around teaching others. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

On Fri, Sep 06, 2002 at 10:39:05PM +0200, Jeroen Massar wrote: [snip]

Or even better... actual popquiz question*: "What is the subnet mask of a class E?" ;) Does anybody know that one ? Without looking into docs that is.

There is none, just as there is none for class D. Greetz, Peter -- peter@dataloss.nl | http://www.dataloss.nl/ | Undernet:#clue

On Fri, 6 Sep 2002, Iljitsch van Beijnum wrote:

Ok, if I connect to their network I'll remove "ip subnet-zero" and "ip classless" from my configs to revert to the defaults that still reflect the pre-1993 state of affairs, but if they want to connect to "our" network, they should play nice and follow the rules we use here.

The National Security Agency has issued the following principles and guidance for security configuration of IP routers, with detailed instructions for Cisco System routers. A brief passage from the document: By default, a Cisco router will make an attempt to route almost any IP packet. If a packet arrives addressed to a subnet of a network that has no default network route, then IOS will, with IP classless routing, forward the packet along the best available route to a supernet of the addressed subnet. This feature is often not needed. On routers where IP classless routing is not needed, disable it as shown below. Central# config t Enter configuration commands, one per line. End with CNTL/Z. Central(config)# no ip classless Central(config)# exit http://nsa2.www.conxion.com/cisco/download.htm Geez, people are worried about the NSA tapping the Internet. How about worrying the NSA connecting misconfigured routers to the Internet? Yes, even the NSA has bad network days. They just don't like to talk about it.

Not that it will more people the trouble of sending me more messages, but yes I'm aware the NSA guide states:

"The goal for this guide is a simple one: improve the security provided by routers on US Department of Defense (DoD) operational networks."

Inside the DoD, they may want to only use classful routing. The recommendation may be valid for that environment.

Highly unlikely. From what experience I have w/ DOD networks a lot of them tend to be early large allocations (whole class B's or even a class A or two) that have since been subnetted - a lot. If you peruse the allocation lists as far as who has what I believe that you'll that there are a lot of large classfull delegations to DOD networks, and not near as many "class C" blocks. Turning off ip classless in any of the enviroments I've seen would be nothing short of catastrophic. OTOH having lived through several so called security audits, I can certainly believe that this would be on one of the checklists. Note: I've intentionally used classful notation, not because I'm an idiot (although I'm always open to that possibility :), but because it represents the historical aspects of these allocations.

Unfortunately, some security firms and organizations have taken the NSA guide as a rulebook. I've seen a lot of security checklists copied directly from the NSA Router Security and Configuration Guide. Even worse, I've seen very expensive security vulnerability reports recommending clients change their routers based on the NSA guide, such as turning off ip classless.

If you are building a network in the outside of the DoD some of the NSA recommendations should *NOT* be followed.

--

-=-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-<>-=-=-=-=-=-=-< Ryan Mooney ryan@pcslink.com <-=-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-><-=-=-=-=-=-=->

On Friday, September 6, 2002, at 04:04 PM, Iljitsch van Beijnum wrote:

On Fri, 6 Sep 2002, Joe Abley wrote:

...

How many people learn about networks from certification courses or in school, anyway? It was always my impression that people learnt mainly by listening to other people.

Well, maybe, if you define "listening to people" as "reading what people write".

That too, in the context of written discussions, rather than books or manuals.

...

If networking on the front lines is an informal oral tradition more than it is a taught science, then perhaps it's natural for obsolete terminology to continue to be "taught" long after it stopped having any relevance.

Actually, I would assume it to be the other way around: if you only communicate with people who are active in the field who are aware of all the new tricks, how are you going to learn about obsolete stuff?

I think there is often a directed graph of information flow for particular subjects. There will be nodes in the graph which correspond to people who have done research, and who speak with some accuracy. There are other nodes which listen selectively to the interpretations of others, derive rules of thumb and pass their filtered wisdom onto other nodes, but do no research from sources that might be considered authoritative. The effectiveness of this information-sharing network is hampered by the unreliability of individual nodes to filter information they receive, the inconsistent manner in which the information is processed, the near-complete absense of filters on information passed to other nodes, and the ad-hoc summarisation that happens throughout the network regardless of the intentions of the origin nodes. Sounds almost eerily familiar. Many ISPs provide a fertile learning environment for people who are able and willing to learn, regardless (in spite of!) of initial training and qualification. However, I seem to think that there are lots of people in organisations that run IP networks who don't have the opportunity to learn how to do lots of different things, and many of them don't have the time, ability or inclination to go research questions from the bottom up. Rules of thumb and networking myths abound in that environment. The people who are most able to appreciate finer technical points are also those who are most likely to get bored and go find a more interesting job somewhere else, etc, etc. "ICMP is a security risk." "You can't use the first and last subnets." Education is hard. Joe

On Fri, Sep 06, 2002 at 10:04:08PM +0200, Iljitsch van Beijnum wrote: [snip]

About classfulness: I think it's more relevant, even today, than many people like to admit. Why is it that I can type "network 192.0.2.0" in my Cisco BGP config and the box knows what I'm talking about, but "network 192.0.2.0/24" is no good?

That is because Cisco is quite classful-centric, still. I think defaults for netmasks, based on classes, are very bad. They cause trouble (like the time a certain ISP announced 62/8 to all it's peers on AMS-IX). Cisco should support the /n notation! Greetz, Peter -- peter@dataloss.nl | http://www.dataloss.nl/ | Undernet:#clue

Tony Tauber wrote:

On Thu, 5 Sep 2002, Richard A Steenbergen wrote:

...

On Thu, Sep 05, 2002 at 01:36:27PM -0400, Derek Samford wrote:

...

Shane, There is a practice on that (At least here.). Generally we provide a Class C to our customers at no additional charge, but we have

Why in this day and age, 9 years after the invention of CIDR, are we still refering to "class C"'s?

At least as importantly, why do 254 addresses get provided where the actual need might not warrant that quantity?

Because it's easier to do the reverse DNS? Sorry to contribute to the general noise, but that answer's close to the truth. -- ...some sort of steganographic chaffing and winnowing scheme already exists in practice right here: I frequently find myself having to sort through large numbers of idiotic posts to find the good ones. -- Rufus Faloofus

On Thu, Sep 05, 2002 at 03:19:08PM -0400, Christian Malo wrote: [snip]

these days you can easily delegate reverse using CIDR with BIND ...

http://www.faqs.org/rfcs/rfc2317.html

And you can do it even easier without RFC2317: http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.h... Greetz, Peter -- peter@dataloss.nl | http://www.dataloss.nl/ | Undernet:#clue

On Fri, Sep 06, 2002 at 02:21:35PM +0200, Brad Knowles wrote:

At 11:11 AM +0200 2002/09/06, Peter van Dijk wrote:

...

And you can do it even easier without RFC2317:

http://homepages.tesco.net/~J.deBoynePollard/FGA/avoid-rfc-2317-delegation.h...

Nope. Fundamentally broken. Delegations must occur at the apex of a zone.

That is a common misconception. Recursing resolvers couldn't care less if they are written according to spec (unlike old BIND versions, for example). Also, it's easy (with tinydns) or not very hard (with BIND) to implement given solution without violating your condition. Have a look, for example, at the reverses for 193.109.122.192/28 and let me know if you can find anything wrong with those. Greetz, Peter -- peter@dataloss.nl | http://www.dataloss.nl/ | Undernet:#clue

On Fri, Sep 06, 2002 at 09:10:45AM -0400, Valdis.Kletnieks@vt.edu wrote:

On Fri, 06 Sep 2002 14:42:39 +0200, Peter van Dijk <peter@dataloss.nl> said:

...

That is a common misconception. Recursing resolvers couldn't care less if they are written according to spec (unlike old BIND versions, for example).

Well... way back when (18 months or so)...

I'm not referring to that particular problem, but read on.

On Thu, 01 Feb 2001 18:11:34 PST, Paul Vixie <vixie@mfnx.net> said:

...

pi@vuurwerk.nl (Pim van Riezen) writes:

...

bogosity while updating 8.2.2-P7 to 8.2.3:

(1) 8.2.3 Doesn't accept the "(" in the SOA string to be on the next line after the IN SOA. Our script-generated zonefiles, about 45000 of them, all had this.

Neither do the relevant RFC's, or any other DNS implementation. Pre-8.2.3 was simply _wrong_ to accept that syntax.

If you want to be the *next* guy who gets bit for 45K zones when the *next* next release starts enforcing something that was illegal-but-worked-mostly, be my guest....

A fun note is that BIND, in that situation (I worked for Vuurwerk at that time as well), just put some (high-ascii) garbage in the logfile and segfaulted, instead of reporting a nice error. Ofcourse it is also highly broken that the RFC specifies the zonefile syntax. [I think we're drifting offtopic here] Greetz, Peter -- peter@dataloss.nl | http://www.dataloss.nl/ | Undernet:#clue

On Fri, Sep 06, 2002 at 03:32:00PM +0200, Brad Knowles wrote: [snip]

...

Have a look, for example, at the reverses for 193.109.122.192/28 and let me know if you can find anything wrong with those.

Okay, so you've made 192.122.109.193.in-addr.arpa a zone (delegated from bit.nl within 122.109.193.in-addr.arpa, which is delegated from RIPE's 193.in-addr.arpa), and this zone has an SOA and NS records defined. Other than the fact that this zone is within the in-addr.arpa tree, this would seem to be fairly normal behaviour for any other zone in any other tree.

in-addr.arpa is not special from a DNS point-of-view.

However, it doesn't appear to have a PTR record. Contrariwise, 193.122.109.193.in-addr.arpa has an SOA, NS RRs, and a PTR. I'm sure your other zones look similar.

Indeed 192 doesn't have a PTR - it's the network number. 193 and a few others do indeed have PTR's.

Bizarre. Truly bizarre. Somehow, I feel compelled to make some remark about "perverting the course of the DNS", or somesuch.

What am I doing wrong in this case? A zone is delegated, the nameserver receiving the delegation serves this zone. No apexes mismatch. Greetz, Peter -- peter@dataloss.nl | http://www.dataloss.nl/ | Undernet:#clue

At 3:32 PM +0200 2002/09/06, Brad Knowles wrote:

...

Have a look, for example, at the reverses for 193.109.122.192/28 and let me know if you can find anything wrong with those.

The page you originally referenced says: The first three records are simply there to make BIND happy about loading the "zone" from the database file. (Would that it did not require them! But - alas! - it would complain were they not there.) Your content DNS server will serve those resource records up to the world (the "NS" resource records in the authority section of responses and the "SOA" resource record in "no such name" responses) but the world will ignore them, so this does not matter one iota. A correctly operating resolving proxy DNS server must discard them because their names are outside of your content DNS server's bailiwick. "in-addr.arpa." is not delegated to your content DNS server, only subdomains within it are. The key phrase is "A correctly operating resolving proxy DNS server must discard them ...". Do you have any idea whatsoever how many incredibly badly mis-configured and incorrectly operating caching nameservers there are in the world?!? My talk at LISA 2002 is going to cover (in part) how many badly mis-configured and incorrectly operating TLD nameservers there are in the world, and above all other servers of all other types (except the root servers themselves), these should be more correct and properly configured. And yet, there is an unbelievable number of these servers that are not correctly configured, and some of them are incredibly screwed-up. $DEITY!!! Even trying to conceive of the scale of the numbers of screwed-up caching nameservers just totally boggles the mind. I doubt that there is anyone in the world that could come up with an accurate estimate. Now, if you wanted to do separate zone files, and make sure that each zone file doesn't contain any out-of-zone data, that would be a different issue. But this is like handing people sticks of dynamite, flamethrowers, and encouraging them to ignite the explosives they're holding in their hands. If you really want to do this (and especially do it this way), all I can say is that, sooner or later, you *will* get what you deserve.

Bizarre. Truly bizarre. Somehow, I feel compelled to make some remark about "perverting the course of the DNS", or somesuch.

Now *this* is pretty cool: DNS Expert Detailed Report for 192.122.109.193.in-addr.arpa. 9/6/02, 4:05 PM, using the analysis setting "Everything" ====================================================================== Information ---------------------------------------------------------------------- Serial number: 1031317961 Primary name server: ns.dataloss.nl. Primary mail server: N/A Number of records: N/A Errors ---------------------------------------------------------------------- o The reverse zone contains one or more A records The reverse domain "192.122.109.193.in-addr.arpa." contains one or more A records. A records should only be placed in forward-mapping domains. Warnings ---------------------------------------------------------------------- o The name server "ns.dataloss.nl." does not permit zone transfers The name server "ns.dataloss.nl." has been configured to reject unauthorized zone transfers and the application will not be able to use data from this server while analyzing the zone. o The name server "ns3.dataloss.nl." does not permit zone transfers The name server "ns3.dataloss.nl." has been configured to reject unauthorized zone transfers and the application will not be able to use data from this server while analyzing the zone. o Zone transfer from authoritative servers not possible It was not possible to perform a zone transfer from any of the authoritative name servers for the zone. This will limit the range of tests performed for the zone. o The TTL field in the SOA record contains an unusually low value The value 2560 of the TTL field in the SOA record field is unusually low. The value for this field should be within the range 3600 - 172800. o The Minimum TTL field in the SOA record contains an unusually low value The value 2560 of the Minimum field in the SOA record is unusually low. The value for this field should be within the range 3600 - 172800. o The Serial number field in the SOA record contains an unusual value It appears that the Serial number field in the SOA record is based on a date value that is in the future. o The TTL value 259200, in the A record "ns.dataloss.nl." is rather high The TTL value 259200, used in the A record "ns.dataloss.nl.", is unusually high. The TTL value should be within the range 3600 - 172800. o The TTL value 259200, in the NS record "192.122.109.193.in-addr.arpa." is rather high The TTL value 259200, used in the NS record "192.122.109.193.in-addr.arpa.", is unusually high. The TTL value should be within the range 3600 - 172800. o All name servers for the zone are on the same subnet. All name servers for the zone are on the same subnet (193.109.122.*). If the connection to the network breaks, your domain will become inaccessible. ---------------------------------------------------------------------- end of report DNS Expert Detailed Report for 193.122.109.193.in-addr.arpa. 9/6/02, 4:05 PM, using the analysis setting "Everything" ====================================================================== Information ---------------------------------------------------------------------- Serial number: 1031317961 Primary name server: ns.dataloss.nl. Primary mail server: N/A Number of records: N/A Errors ---------------------------------------------------------------------- o The reverse zone contains one or more A records The reverse domain "193.122.109.193.in-addr.arpa." contains one or more A records. A records should only be placed in forward-mapping domains. Warnings ---------------------------------------------------------------------- o The name server "ns.dataloss.nl." does not permit zone transfers The name server "ns.dataloss.nl." has been configured to reject unauthorized zone transfers and the application will not be able to use data from this server while analyzing the zone. o The name server "ns3.dataloss.nl." does not permit zone transfers The name server "ns3.dataloss.nl." has been configured to reject unauthorized zone transfers and the application will not be able to use data from this server while analyzing the zone. o Zone transfer from authoritative servers not possible It was not possible to perform a zone transfer from any of the authoritative name servers for the zone. This will limit the range of tests performed for the zone. o The TTL field in the SOA record contains an unusually low value The value 2560 of the TTL field in the SOA record field is unusually low. The value for this field should be within the range 3600 - 172800. o The Minimum TTL field in the SOA record contains an unusually low value The value 2560 of the Minimum field in the SOA record is unusually low. The value for this field should be within the range 3600 - 172800. o The Serial number field in the SOA record contains an unusual value It appears that the Serial number field in the SOA record is based on a date value that is in the future. o The TTL value 259200, in the A record "ns.dataloss.nl." is rather high The TTL value 259200, used in the A record "ns.dataloss.nl.", is unusually high. The TTL value should be within the range 3600 - 172800. o The TTL value 259200, in the NS record "193.122.109.193.in-addr.arpa." is rather high The TTL value 259200, used in the NS record "193.122.109.193.in-addr.arpa.", is unusually high. The TTL value should be within the range 3600 - 172800. o All name servers for the zone are on the same subnet. All name servers for the zone are on the same subnet (193.109.122.*). If the connection to the network breaks, your domain will become inaccessible. ---------------------------------------------------------------------- end of report What about this? % dnswalk -ralF 122.109.193.in-addr.arpa. Checking 122.109.193.in-addr.arpa. Getting zone transfer of 122.109.193.in-addr.arpa. from ns2.bit.nl...done. SOA=ns.bit.nl contact=root.bit.nl WARN: 6.122.109.193.IN-ADDR.ARPA PTR proxypool-6.undernet.org: unknown host WARN: 7.122.109.193.IN-ADDR.ARPA PTR proxypool-7.undernet.org: unknown host WARN: 8.122.109.193.IN-ADDR.ARPA PTR proxypool-8.undernet.org: unknown host WARN: 9.122.109.193.IN-ADDR.ARPA PTR proxypool-9.undernet.org: unknown host WARN: 10.122.109.193.IN-ADDR.ARPA PTR proxypool-10.undernet.org: unknown host WARN: 11.122.109.193.IN-ADDR.ARPA PTR proxypool-11.undernet.org: unknown host WARN: 12.122.109.193.IN-ADDR.ARPA PTR proxypool-12.undernet.org: unknown host WARN: 13.122.109.193.IN-ADDR.ARPA PTR proxypool-13.undernet.org: unknown host WARN: 14.122.109.193.IN-ADDR.ARPA PTR proxypool-14.undernet.org: unknown host WARN: 15.122.109.193.IN-ADDR.ARPA PTR proxypool-15.undernet.org: unknown host WARN: 16.122.109.193.IN-ADDR.ARPA PTR proxypool-16.undernet.org: unknown host WARN: 17.122.109.193.IN-ADDR.ARPA PTR proxypool-17.undernet.org: unknown host WARN: 18.122.109.193.IN-ADDR.ARPA PTR proxypool-18.undernet.org: unknown host WARN: 20.122.109.193.IN-ADDR.ARPA PTR proxypool-20.undernet.org: unknown host WARN: 19.122.109.193.IN-ADDR.ARPA PTR proxypool-19.undernet.org: unknown host WARN: 21.122.109.193.IN-ADDR.ARPA PTR proxypool-21.undernet.org: unknown host WARN: 22.122.109.193.IN-ADDR.ARPA PTR proxypool-22.undernet.org: unknown host WARN: 23.122.109.193.IN-ADDR.ARPA PTR proxypool-23.undernet.org: unknown host WARN: 24.122.109.193.IN-ADDR.ARPA PTR proxypool-24.undernet.org: unknown host WARN: 25.122.109.193.IN-ADDR.ARPA PTR proxypool-25.undernet.org: unknown host WARN: 26.122.109.193.IN-ADDR.ARPA PTR proxypool-26.undernet.org: unknown host WARN: 27.122.109.193.IN-ADDR.ARPA PTR proxypool-27.undernet.org: unknown host WARN: 28.122.109.193.IN-ADDR.ARPA PTR proxypool-28.undernet.org: unknown host WARN: 30.122.109.193.IN-ADDR.ARPA PTR proxypool-30.undernet.org: unknown host WARN: 29.122.109.193.IN-ADDR.ARPA PTR proxypool-29.undernet.org: unknown host WARN: 31.122.109.193.IN-ADDR.ARPA PTR proxypool-31.undernet.org: unknown host WARN: 32.122.109.193.IN-ADDR.ARPA PTR proxypool-32.undernet.org: unknown host WARN: 33.122.109.193.IN-ADDR.ARPA PTR proxypool-33.undernet.org: unknown host WARN: 34.122.109.193.IN-ADDR.ARPA PTR proxypool-34.undernet.org: unknown host WARN: 35.122.109.193.IN-ADDR.ARPA PTR proxypool-35.undernet.org: unknown host WARN: 36.122.109.193.IN-ADDR.ARPA PTR proxypool-36.undernet.org: unknown host WARN: 210.122.109.193.IN-ADDR.ARPA PTR ns2.cluecentral.net: A record not found WARN: 37.122.109.193.IN-ADDR.ARPA PTR proxypool-37.undernet.org: unknown host WARN: 209.122.109.193.IN-ADDR.ARPA PTR shell.cluecentral.net: unknown host WARN: 38.122.109.193.IN-ADDR.ARPA PTR proxypool-38.undernet.org: unknown host WARN: 40.122.109.193.IN-ADDR.ARPA PTR proxypool-40.undernet.org: unknown host WARN: 39.122.109.193.IN-ADDR.ARPA PTR proxypool-39.undernet.org: unknown host WARN: 41.122.109.193.IN-ADDR.ARPA PTR proxypool-41.undernet.org: unknown host WARN: 42.122.109.193.IN-ADDR.ARPA PTR proxypool-42.undernet.org: unknown host WARN: 43.122.109.193.IN-ADDR.ARPA PTR proxypool-43.undernet.org: unknown host WARN: 44.122.109.193.IN-ADDR.ARPA PTR proxypool-44.undernet.org: unknown host WARN: 45.122.109.193.IN-ADDR.ARPA PTR proxypool-45.undernet.org: unknown host WARN: 46.122.109.193.IN-ADDR.ARPA PTR proxypool-46.undernet.org: unknown host WARN: 47.122.109.193.IN-ADDR.ARPA PTR proxypool-47.undernet.org: unknown host WARN: 48.122.109.193.IN-ADDR.ARPA PTR proxypool-48.undernet.org: unknown host WARN: 50.122.109.193.IN-ADDR.ARPA PTR proxypool-50.undernet.org: unknown host WARN: 49.122.109.193.IN-ADDR.ARPA PTR proxypool-49.undernet.org: unknown host WARN: 51.122.109.193.IN-ADDR.ARPA PTR proxypool-51.undernet.org: unknown host WARN: 52.122.109.193.IN-ADDR.ARPA PTR proxypool-52.undernet.org: unknown host WARN: 53.122.109.193.IN-ADDR.ARPA PTR proxypool-53.undernet.org: unknown host WARN: 54.122.109.193.IN-ADDR.ARPA PTR proxypool-54.undernet.org: unknown host WARN: 55.122.109.193.IN-ADDR.ARPA PTR proxypool-55.undernet.org: unknown host WARN: 56.122.109.193.IN-ADDR.ARPA PTR proxypool-56.undernet.org: unknown host WARN: 228.122.109.193.IN-ADDR.ARPA PTR vtun.dappekepatches.net: unknown host WARN: 57.122.109.193.IN-ADDR.ARPA PTR proxypool-57.undernet.org: unknown host WARN: 58.122.109.193.IN-ADDR.ARPA PTR proxypool-58.undernet.org: unknown host WARN: 60.122.109.193.IN-ADDR.ARPA PTR proxypool-60.undernet.org: unknown host WARN: 59.122.109.193.IN-ADDR.ARPA PTR proxypool-59.undernet.org: unknown host Checking 192.122.109.193.in-addr.arpa Getting zone transfer of 192.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 192.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 192.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 192.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 192.122.109.193.in-addr.arpa failed! Checking 193.122.109.193.in-addr.arpa Getting zone transfer of 193.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 193.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 193.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 193.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 193.122.109.193.in-addr.arpa failed! Checking 194.122.109.193.in-addr.arpa Getting zone transfer of 194.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 194.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 194.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 194.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 194.122.109.193.in-addr.arpa failed! Checking 195.122.109.193.in-addr.arpa Getting zone transfer of 195.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 195.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 195.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 195.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 195.122.109.193.in-addr.arpa failed! Checking 196.122.109.193.in-addr.arpa Getting zone transfer of 196.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 196.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 196.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 196.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 196.122.109.193.in-addr.arpa failed! Checking 197.122.109.193.in-addr.arpa Getting zone transfer of 197.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 197.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 197.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 197.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 197.122.109.193.in-addr.arpa failed! Checking 198.122.109.193.in-addr.arpa Getting zone transfer of 198.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 198.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 198.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 198.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 198.122.109.193.in-addr.arpa failed! Checking 199.122.109.193.in-addr.arpa Getting zone transfer of 199.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 199.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 199.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 199.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 199.122.109.193.in-addr.arpa failed! Checking 200.122.109.193.in-addr.arpa Getting zone transfer of 200.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 200.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 200.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 200.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 200.122.109.193.in-addr.arpa failed! Checking 201.122.109.193.in-addr.arpa Getting zone transfer of 201.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 201.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 201.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 201.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 201.122.109.193.in-addr.arpa failed! Checking 202.122.109.193.in-addr.arpa Getting zone transfer of 202.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 202.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 202.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 202.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 202.122.109.193.in-addr.arpa failed! Checking 203.122.109.193.in-addr.arpa Getting zone transfer of 203.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 203.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 203.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 203.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 203.122.109.193.in-addr.arpa failed! Checking 204.122.109.193.in-addr.arpa Getting zone transfer of 204.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 204.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 204.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 204.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 204.122.109.193.in-addr.arpa failed! Checking 205.122.109.193.in-addr.arpa Getting zone transfer of 205.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 205.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 205.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 205.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 205.122.109.193.in-addr.arpa failed! Checking 206.122.109.193.in-addr.arpa Getting zone transfer of 206.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 206.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 206.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 206.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 206.122.109.193.in-addr.arpa failed! Checking 207.122.109.193.in-addr.arpa Getting zone transfer of 207.122.109.193.in-addr.arpa from ns.dataloss.nl...failed FAIL: Zone transfer of 207.122.109.193.in-addr.arpa from ns.dataloss.nl failed: NOERROR Getting zone transfer of 207.122.109.193.in-addr.arpa from ns3.dataloss.nl...failed FAIL: Zone transfer of 207.122.109.193.in-addr.arpa from ns3.dataloss.nl failed: NOERROR BAD: All zone transfer attempts of 207.122.109.193.in-addr.arpa failed! 32 failures, 58 warnings, 16 errors. And this: DNS Expert Detailed Report for 122.109.193.in-addr.arpa. 9/6/02, 3:56 PM, using the analysis setting "Everything" ====================================================================== Information ---------------------------------------------------------------------- Serial number: 2002090401 Primary name server: ns.bit.nl. Primary mail server: N/A Number of records: 112 (34 NS, 0 MX, 0 A, 0 CNAME, 78 PTR, 0 Other) Errors ---------------------------------------------------------------------- o Lame delegation received from "ns.ansible.org." for "undernet.org." The server "ns.ansible.org." is listed as being authoritative for "undernet.org.", but "ns.ansible.org." does not contain authoritative data for the zone. o There is no A record for the host name "6.122.109.193.in-addr.arpa." The host "proxypool-6.undernet.org." (referred to by "6.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "7.122.109.193.in-addr.arpa." The host "proxypool-7.undernet.org." (referred to by "7.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "8.122.109.193.in-addr.arpa." The host "proxypool-8.undernet.org." (referred to by "8.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "9.122.109.193.in-addr.arpa." The host "proxypool-9.undernet.org." (referred to by "9.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "10.122.109.193.in-addr.arpa." The host "proxypool-10.undernet.org." (referred to by "10.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "11.122.109.193.in-addr.arpa." The host "proxypool-11.undernet.org." (referred to by "11.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "12.122.109.193.in-addr.arpa." The host "proxypool-12.undernet.org." (referred to by "12.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "13.122.109.193.in-addr.arpa." The host "proxypool-13.undernet.org." (referred to by "13.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "14.122.109.193.in-addr.arpa." The host "proxypool-14.undernet.org." (referred to by "14.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "15.122.109.193.in-addr.arpa." The host "proxypool-15.undernet.org." (referred to by "15.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "16.122.109.193.in-addr.arpa." The host "proxypool-16.undernet.org." (referred to by "16.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "17.122.109.193.in-addr.arpa." The host "proxypool-17.undernet.org." (referred to by "17.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "18.122.109.193.in-addr.arpa." The host "proxypool-18.undernet.org." (referred to by "18.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "20.122.109.193.in-addr.arpa." The host "proxypool-20.undernet.org." (referred to by "20.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "19.122.109.193.in-addr.arpa." The host "proxypool-19.undernet.org." (referred to by "19.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "21.122.109.193.in-addr.arpa." The host "proxypool-21.undernet.org." (referred to by "21.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "22.122.109.193.in-addr.arpa." The host "proxypool-22.undernet.org." (referred to by "22.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "23.122.109.193.in-addr.arpa." The host "proxypool-23.undernet.org." (referred to by "23.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "24.122.109.193.in-addr.arpa." The host "proxypool-24.undernet.org." (referred to by "24.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "25.122.109.193.in-addr.arpa." The host "proxypool-25.undernet.org." (referred to by "25.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "26.122.109.193.in-addr.arpa." The host "proxypool-26.undernet.org." (referred to by "26.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "27.122.109.193.in-addr.arpa." The host "proxypool-27.undernet.org." (referred to by "27.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "28.122.109.193.in-addr.arpa." The host "proxypool-28.undernet.org." (referred to by "28.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "30.122.109.193.in-addr.arpa." The host "proxypool-30.undernet.org." (referred to by "30.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "29.122.109.193.in-addr.arpa." The host "proxypool-29.undernet.org." (referred to by "29.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "31.122.109.193.in-addr.arpa." The host "proxypool-31.undernet.org." (referred to by "31.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "32.122.109.193.in-addr.arpa." The host "proxypool-32.undernet.org." (referred to by "32.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "33.122.109.193.in-addr.arpa." The host "proxypool-33.undernet.org." (referred to by "33.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "34.122.109.193.in-addr.arpa." The host "proxypool-34.undernet.org." (referred to by "34.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "35.122.109.193.in-addr.arpa." The host "proxypool-35.undernet.org." (referred to by "35.122.109.193.in-addr.arpa.") does not exist. o The host "ns2.cluecentral.net." referred to by "210.122.109.193.in-addr.arpa." does not have the IP address 193.109.122.210 The PTR record "210.122.109.193.in-addr.arpa." refers to the host "ns2.cluecentral.net.", but a query for "ns2.cluecentral.net." found a host with a different IP address than 193.109.122.210 o There is no A record for the host name "36.122.109.193.in-addr.arpa." The host "proxypool-36.undernet.org." (referred to by "36.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "209.122.109.193.in-addr.arpa." The host "shell.cluecentral.net." (referred to by "209.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "37.122.109.193.in-addr.arpa." The host "proxypool-37.undernet.org." (referred to by "37.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "40.122.109.193.in-addr.arpa." The host "proxypool-40.undernet.org." (referred to by "40.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "38.122.109.193.in-addr.arpa." The host "proxypool-38.undernet.org." (referred to by "38.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "41.122.109.193.in-addr.arpa." The host "proxypool-41.undernet.org." (referred to by "41.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "39.122.109.193.in-addr.arpa." The host "proxypool-39.undernet.org." (referred to by "39.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "42.122.109.193.in-addr.arpa." The host "proxypool-42.undernet.org." (referred to by "42.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "43.122.109.193.in-addr.arpa." The host "proxypool-43.undernet.org." (referred to by "43.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "44.122.109.193.in-addr.arpa." The host "proxypool-44.undernet.org." (referred to by "44.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "45.122.109.193.in-addr.arpa." The host "proxypool-45.undernet.org." (referred to by "45.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "46.122.109.193.in-addr.arpa." The host "proxypool-46.undernet.org." (referred to by "46.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "47.122.109.193.in-addr.arpa." The host "proxypool-47.undernet.org." (referred to by "47.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "50.122.109.193.in-addr.arpa." The host "proxypool-50.undernet.org." (referred to by "50.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "48.122.109.193.in-addr.arpa." The host "proxypool-48.undernet.org." (referred to by "48.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "51.122.109.193.in-addr.arpa." The host "proxypool-51.undernet.org." (referred to by "51.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "49.122.109.193.in-addr.arpa." The host "proxypool-49.undernet.org." (referred to by "49.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "52.122.109.193.in-addr.arpa." The host "proxypool-52.undernet.org." (referred to by "52.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "53.122.109.193.in-addr.arpa." The host "proxypool-53.undernet.org." (referred to by "53.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "54.122.109.193.in-addr.arpa." The host "proxypool-54.undernet.org." (referred to by "54.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "55.122.109.193.in-addr.arpa." The host "proxypool-55.undernet.org." (referred to by "55.122.109.193.in-addr.arpa.") does not exist. o The server "not-renewed.joker.com." did not reply The server "not-renewed.joker.com." did not reply when it was queried for the name "vtun.dappekepatches.net.". This indicates that the server is not running, or it is currently unreachable. o There is no A record for the host name "228.122.109.193.in-addr.arpa." The host "vtun.dappekepatches.net." (referred to by "228.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "56.122.109.193.in-addr.arpa." The host "proxypool-56.undernet.org." (referred to by "56.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "57.122.109.193.in-addr.arpa." The host "proxypool-57.undernet.org." (referred to by "57.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "60.122.109.193.in-addr.arpa." The host "proxypool-60.undernet.org." (referred to by "60.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "58.122.109.193.in-addr.arpa." The host "proxypool-58.undernet.org." (referred to by "58.122.109.193.in-addr.arpa.") does not exist. o There is no A record for the host name "59.122.109.193.in-addr.arpa." The host "proxypool-59.undernet.org." (referred to by "59.122.109.193.in-addr.arpa.") does not exist. Warnings ---------------------------------------------------------------------- o Server name in the SOA record differs from server name in an NS record The name server with the IP address 213.136.0.66 is identified by the name "ns.bit.nl." in the SOA record but the NS record uses the name "ns1.bit.nl." for the host. o There is more than one PTR record referring to "ns2.cluecentral.net." The zone contains more than one PTR record referring to the host "ns2.cluecentral.net." o All name servers for the zone are on the same subnet. All name servers for the zone are on the same subnet (213.136.0.*). If the connection to the network breaks, your domain will become inaccessible. ---------------------------------------------------------------------- end of report -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

At 4:40 PM +0200 2002/09/06, Peter van Dijk wrote:

I am doing separate zone files. Each IP delegated to me is a separate zone. Now, again, what is wrong with that?

Technically, nothing -- at least, with the absolute latest authoritative nameservers and the absolute latest recursive/caching nameservers, and it doesn't seem to give much problems to modern resolver libraries. Procedurally, everything is wrong with it -- in part, because of the profusion of mis-configured authoritative and recursive/caching nameservers that exist on the Internet today (not to mention resolving libraries), the fact that most vendors today still ship vulnerable authoritative & recursive/caching nameservers with their OSes (and *no one* ships an OS that uses modern resolver libraries), and the fact that 99.999999% of the people on the 'net will take the default garbage that the vendor ships to them simply because they don't know any better.

...

o The reverse zone contains one or more A records The reverse domain "192.122.109.193.in-addr.arpa." contains one or more A records. A records should only be placed in forward-mapping domains.

What A-records is it talking about? I am not seeing any.

They are the ones associated with your NS records. At a procedural level, PTR records are mutually exclusive with SOA & NS records.

Indeed, you found some things wrong with the /24 zone, but that was not the subject, and nothing you found wrong with the /24 is related to the /29.

See above. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

At 5:11 PM +0200 2002/09/06, Peter van Dijk wrote:

I am very willing to believe everything that you are saying, but *what part* of my configuration breaks those nameservers?

$DEITY-only-knows how older/less capable nameserver software will deal with the issue of having a zone that is also a PTR record.

But there are no A records in that zone. Again, what A-records?

The A RRs in the glue that goes along with the NS records that are a result of making this a zone.

I have, by the way, enabled AXFR to the world for my reverse zones (all 16), so feel free to have a look.

Will do. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

At 1:41 PM +0200 2002/09/09, Peter van Dijk wrote:

PTR is not special to nameserver software in any way. If it can handle an A record that is the name of the domain, it can handle a PTR.

Maybe not the nameserver software you've seen. Moreover, the real problem is not the nameserver software, but all the other incredibly broken applications out there that can't handle PTR co-existing with SOA & NS RRs. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

Oops, <SNIP>

Btw... another 'cool' DNS tool: www.

http://www.foobar.tm/dns/ "DNS Bajaj is a tool I made to help pinpoint errors when setting up nameservers for a domain. This is still a sort of "proof of concept" and the code is reflecting that. Someone asked what a "bajaj" is and how it should be pronounced . Think of DNS Bajaj as "D N S By Eye". I hope this explains the stupid name. " "DNS Bajaj - What it is DNS Bajaj is a tool mainly for checking the delegation of a domain. As the name implies (or at least I hope so) it does this by making a graph of the interrelationships beteween all the nameservers involved in the managment of the domain and marking the servers that does funny stuff in a way that makes it easy to pinpoint them by sight - by eye if you want to. " Greets, Jeroen

On Fri, Sep 06, 2002 at 11:04:36PM +0200, Brad Knowles wrote: [snip]

...

60.1.0.10.in-addr.arpa. CNAME bla-reverse.example.org. bla-reverse.example.org. PTR bla.example.org. bla.example.org. A 10.0.1.60

What's wrong with that? No RFC against it ;)

Are you sure about that? IIRC, the definitions of CNAME records and what they can point to are pretty strict.

If that is illegal, then so is RFC2317 :)

...

Cool, why does it work then? <grin>

Just because something hasn't actually been made officially illegal doesn't mean that it's not a really bad idea.

It seems to me RFC2317 is pushing the edge of standards more than my solution is. Greetz, Peter -- peter@dataloss.nl | http://www.dataloss.nl/ | Undernet:#clue

At 11:39 AM 9/5/2002 -0700, Etaoin Shrdlu wrote:

...

At least as importantly, why do 254 addresses get provided where the actual need might not warrant that quantity?

Because it's easier to do the reverse DNS? Sorry to contribute to the general noise, but that answer's close to the truth.

http://www.faqs.org/rfcs/rfc2317.html Easier maybe... But with classless delegation of IN-ADDR.ARPA this should not be an issue any longer.

-- ...some sort of steganographic chaffing and winnowing scheme already exists in practice right here: I frequently find myself having to sort through large numbers of idiotic posts to find the good ones. -- Rufus Faloofus

-- Christopher Schulte http://www.schulte.org/ Do not un-munge my @nospam.schulte.org email address. This address is valid.

On Thu, 5 Sep 2002, Tony Tauber wrote:

At least as importantly, why do 254 addresses get provided where the actual need might not warrant that quantity?

Being out here on the edge, I ask that question a lot. Customer calls and says "I need a static IP". I (actually our front line people) ask "WHY?". If they mutter something like "VPN" or "Mail Server" or similar we give one to them without much discussion. If they say "We need a block of 4 or 8" (/30 or /29) and they mutter something along the lines of "We're running our own firewall and want to put a couple of servers on the outside", then we give them to them after some discusson of "are you sure you need to do it this way?" and explain the glories of PNAT to them. If they want a /28 or larger, they better be ready with a real netorking plan, really have a clue, and really understand why they don't want to use NAT or why they need more than the 8 addresses. IP Purists will probably be quick to jump all over me with the evils of NAT, but for the average small business it works perfectly well and solves a lot of security-related issues. (NOTE: I am not saying that NAT and a Stateful Inspection Firewall or similar is the same thing). The average office needs 1 probably-dynamic IP. Period. Back to the original poster's question. We charge a buck-a-month-per-ip more as a "conservation tax" than for anything else. Typically if we feel the customer has packed services as tightly as is reasonable in the address space we waive the fee (good use of NAT and/or other address conservation technologies and/or really valid technical reasons). Customers giving us reasons like "I can't make my server do name-based (non SSL) virtual hosting so I need an IP for each domain I host" or "I think it would be cool to have a real publically visible address on each of my 100 computers in my Beowulf cluster of 486's" are the types of things we don't waive the fees for even though they are valid enough reasons to hand out a block of address space for. - Forrest W. Christian (forrestc@imach.com) AC7DE ---------------------------------------------------------------------- The Innovation Machine Ltd. P.O. Box 5749 http://www.imach.com/ Helena, MT 59604 Home of PacketFlux Technologies and BackupDNS.com (406)-442-6648 ---------------------------------------------------------------------- Protect your personal freedoms - visit http://www.lp.org/

On Thu, Sep 05, 2002 at 01:36:27PM -0400, Derek Samford wrote:

...

Shane, There is a practice on that (At least here.). Generally we provide a Class C to our customers at no additional charge, but we have

Why in this day and age, 9 years after the invention of CIDR, are we still refering to "class C"'s?

Probably for the same reason that people refer to 56K baud modems. It is easier to say, and most people don't care if it is accurate or not.

I think an important question would be what level of service are they buying. Including 255 address with a T3 would be very reasonable, less so with a T1, not very reasonable with DSL, and ridiculous with a dial-up account.

I must be missing something. Why would you expect need for IP addresses to correlate with bandwidth? I can see a company buying a DS3 for a single web/application server or load balancer. I can see an apartment building with 120 network jacks getting a T1. It may make business sense to bundle more 'free IPs' with packages that cost more money. But the actual allocation must be based upon demonstrated need. Read your agreement with ARIN. DS

On Sun, 8 Sep 2002 bdragon@gweep.net wrote:

...

Shane:

I think an important question would be what level of service are they buying. Including 255 address with a T3 would be very reasonable, less so with a T1, not very reasonable with DSL, and ridiculous with a dial-up account.

How is usage need in any way related to circuit size? This kind of allocation policy amazes me.

Hmm I dont know, its a guide if nothing else..

A dialup that can justify a /24 is no different than an OC3 customer who can't. Each customer should (only) get the space they can justify, and circuit size is not a justification.

Really? So a customer who claims to need a /24 on a dialup doesnt suggest to you that they're wrong or at least worthy of further investigation before you assign it? We expect certain requests from certain types of account and anything above that gets looked at. I believe this is a good position between wasting time on end user IP assignments and handing out a limited resource too freely. Steve

On Mon, 9 Sep 2002, cw wrote:

On Mon, 9 Sep 2002 10:06:29 +0100 (BST), Stephen J. Wilcox wrote:

...

Really? So a customer who claims to need a /24 on a dialup doesnt suggest to you that they're wrong or at least worthy of further investigation before you assign it?

The original sender said "justify" not "claim".

Misread that a little :) it is more aimed at the first poster then not the one I responded to! Well my point is that justify or claim I'd pay more attention to the seemingly ok /24 request on a dialup than I would to one for an OC3.