From ginny at arin.net Tue Jan 15 12:15:34 2002 From: ginny at arin.net (ginny listman) Date: Tue, 15 Jan 2002 12:15:34 -0500 (EST) Subject: Lame Delegations Message-ID: Please comment on the following: ARIN would like to remove lame delegations the IN-ADDR.ARPA zone file after 7 consecutive days during which queries return an invalid response for more than 50% of the network. PURPOSE: As the zone files continue to grow, additional queries put additional stress and strain on the servers, as well as generating additional Internet traffic. These "requeries" are fully defined in the Internet Draft . PROCEDURE: 1. ARIN will have a designated machine to query all name servers listed in the database for all networks. This will include name servers that are considered to be lame and/or invalid. Logs will be generated and retained for 30 days. 2. The database will keep track of when and how long name servers are lame. 3. Any name server that is lame for more than 7 days will be excluded from the zone files. 4. On the 7th consecutive day a name server is lame, an email will be sent to the network POC(s), stating the name server will not be included in the zone file. Since this is a courtesy email, those returned undeliverable will be ignored. 5. Any name server that is lame for more than 7 days, will be marked "LAME" in the network Whois display. 6. Lame delegations will be removed from the database after 180 days during which queries return an invalid response for more than 50% of the network. Ginny Listman Director of Engineering ARIN From rrobino at wavedivision.com Tue Jan 15 13:10:23 2002 From: rrobino at wavedivision.com (Rick Robino) Date: Tue, 15 Jan 2002 10:10:23 -0800 Subject: Lame Delegations In-Reply-To: ; from ginny@arin.net on Tue, Jan 15, 2002 at 12:15:34PM -0500 References: Message-ID: <20020115101023.A21174@wavedivision.com> Ginny, The draft never mentions which implementations exhibit the "unreasonable verification queries" noted in section 2.1. It also does not mention which "widely distributed name server implementation", nor was the investigation able discern which stub resolvers or client applications were choking on SERVFAIL, the other two major load factors described. This begs the question: which particular implementations (client and/or server) are now known to have problems? I think this is is feasible that changing some of the most common implementations may have such a dramatic effect on mitigating load that managing lame servers from the top may not be necessary (yet lame servers will be no less annoying to the rest of us). Truthfully, I'd also like to know if there are any vendors or implementations who are being unduly spared critical feedback. Cheers, Rick Robino > On Tue, Jan 15, 2002 at 12:15:34PM -0500, ginny listman wrote: > Please comment on the following: > > ARIN would like to remove lame delegations the IN-ADDR.ARPA zone file > after 7 consecutive days during which queries return an invalid response > for more than 50% of the network. > > PURPOSE: As the zone files continue to grow, additional queries put > additional stress and strain on the servers, as well as generating > additional Internet traffic. These "requeries" are fully defined in > the Internet Draft . > > PROCEDURE: > 1. ARIN will have a designated machine to query all name servers listed in > the database for all networks. This will include name servers that are > considered to be lame and/or invalid. Logs will be generated and > retained for 30 days. > 2. The database will keep track of when and how long name servers are > lame. > 3. Any name server that is lame for more than 7 days will be excluded from > the zone files. > 4. On the 7th consecutive day a name server is lame, an email will be sent > to the network POC(s), stating the name server will not be included in > the zone file. Since this is a courtesy email, those returned > undeliverable will be ignored. > 5. Any name server that is lame for more than 7 days, will be marked > "LAME" in the network Whois display. > 6. Lame delegations will be removed from the database after 180 days > during which queries return an invalid response for more than 50% of > the network. > > > Ginny Listman > Director of Engineering > ARIN -- Rick Robino v. (503) 891-9283 Internet Systems Architect f. (503) 439-8946 Wave Division Consulting @. wavedivision.com From bmanning at vacation.karoshi.com Tue Jan 15 22:56:19 2002 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 16 Jan 2002 03:56:19 +0000 (UCT) Subject: Lame Delegations In-Reply-To: from "ginny listman" at Jan 15, 2002 12:15:34 PM Message-ID: <200201160356.DAA15623@vacation.karoshi.com> find this uncomfortable for a couple of reasons: there are known problems with threading on some platforms which will exihibit this type of behaviour (which is why ther eis a "no-threads" option available in BIND but it is not the default). you get thsi behaviour with a mismatch between one-answer and many-answers. the Internet is increasingly abandoning the e2e model. what presumptions are you making that your monitoring machine will not be blocked by firewalls or that the prefix will even be carried to everywhere on the net? (this is the in-addr.arpa zone your are talking about, not just the data in the arin region) the stated purpose is to reduce stress on the servers and traffic overall. it would be useful to validate the assumption that there is stress and excess traffic. Can we see real numbers regarding query rates and what percentage of queries are these "requeries" More later. > > Please comment on the following: > > ARIN would like to remove lame delegations the IN-ADDR.ARPA zone file > after 7 consecutive days during which queries return an invalid response > for more than 50% of the network. > > PURPOSE: As the zone files continue to grow, additional queries put > additional stress and strain on the servers, as well as generating > additional Internet traffic. These "requeries" are fully defined in > the Internet Draft . > > PROCEDURE: > 1. ARIN will have a designated machine to query all name servers listed in > the database for all networks. This will include name servers that are > considered to be lame and/or invalid. Logs will be generated and > retained for 30 days. > 2. The database will keep track of when and how long name servers are > lame. > 3. Any name server that is lame for more than 7 days will be excluded from > the zone files. > 4. On the 7th consecutive day a name server is lame, an email will be sent > to the network POC(s), stating the name server will not be included in > the zone file. Since this is a courtesy email, those returned > undeliverable will be ignored. > 5. Any name server that is lame for more than 7 days, will be marked > "LAME" in the network Whois display. > 6. Lame delegations will be removed from the database after 180 days > during which queries return an invalid response for more than 50% of > the network. > > > Ginny Listman > Director of Engineering > ARIN > From bruce.campbell at ripe.net Wed Jan 16 05:57:27 2002 From: bruce.campbell at ripe.net (Bruce Campbell) Date: Wed, 16 Jan 2002 11:57:27 +0100 (CET) Subject: Lame Delegations In-Reply-To: <200201160356.DAA15623@vacation.karoshi.com> Message-ID: On Wed, 16 Jan 2002 bmanning at vacation.karoshi.com wrote: > find this uncomfortable for a couple of reasons: > > the Internet is increasingly abandoning the e2e model. what > presumptions are you making that your monitoring machine will > not be blocked by firewalls or that the prefix will even be > carried to everywhere on the net? (this is the in-addr.arpa > zone your are talking about, not just the data in the arin region) Hrm. I interpreted the proposal as only pertaining to data held by ARIN that is in the in-addr.arpa zone.. so ARIN would happily check the APNIC and RIPE nameservers for these non-ARIN RIR delegations, and would not proceed down that tree further. One would assume that if an infrastructure zone (in-addr.arpa) has a delegation to a given set of nameservers, that said nameservers would: *) Not be behind a firewall that blocks DNS queries to zones that it is authoritative for *) Be reachable from most places. On the first point, for an organisation to put its listed nameserver(s) behind a firewall that blocks ad-hoc DNS queries for the zone that has been delegated to it would imply that they do not know what they are doing. Hence, ARIN is proposing to notify said networks, at which point one hopes that the organisation in question will reconfigure their firewall. On the second point, some nameservers would undoubtedly be unreachable from a single point on the Internet. Based on observations when I ran through all the APNIC delegations many moons ago, such a state is not permanent ie, all nameservers that APNIC delegated to were reachable at various times over 3 days. ARIN may of course have a different experience (although I doubt it, as the Internet in Asia-Pacific is generally more flakey than the Internet in the ARIN region). Having suggested a project like this whilst @APNIC, I'm pleased to see that it is being undertaken by someone ;). Regards, -- Bruce Campbell RIPE ( Formerly Senior Systems ) NCC ( Administrator - APNIC ) Operations From jiml at mrtg.noc.adelphia.net Wed Jan 16 08:01:37 2002 From: jiml at mrtg.noc.adelphia.net (James W. Laferriere) Date: Wed, 16 Jan 2002 08:01:37 -0500 (Eastern Standard Time) Subject: Lame Delegations In-Reply-To: Message-ID: Hello All , On Wed, 16 Jan 2002, Bruce Campbell wrote: > On Wed, 16 Jan 2002 bmanning at vacation.karoshi.com wrote: > > find this uncomfortable for a couple of reasons: > > the Internet is increasingly abandoning the e2e model. what > > presumptions are you making that your monitoring machine will > > not be blocked by firewalls or that the prefix will even be > > carried to everywhere on the net? (this is the in-addr.arpa > > zone your are talking about, not just the data in the arin region) > Hrm. I interpreted the proposal as only pertaining to data held by ARIN > that is in the in-addr.arpa zone.. so ARIN would happily check the APNIC > and RIPE nameservers for these non-ARIN RIR delegations, and would not > proceed down that tree further. > One would assume that if an infrastructure zone (in-addr.arpa) has a > delegation to a given set of nameservers, that said nameservers would: > > *) Not be behind a firewall that blocks DNS queries to zones that > it is authoritative for > *) Be reachable from most places. There -is- clue to remember . And if my memory serves 'clue' is not a variable in the allocation/assinging process . Not that I disagree if the ORG is clueless enough to disregard or to not maintain the methods of communications for their POC ... The 7 day limit I (personally) find disgusting . It does not allow for smtp & dns hosts being in the same non-reachable in-addr.arpa. Then the smtp host will happily not accept its own mail . And what is the 'Courtesy email' all about . Try U.S. Postal to the address of the POC of record . Then if that fails a phone call should be tried -before- removing OR marking the alloc. LAME . After all these avenues have been addressed within a reasonable time limit (say 30 days) -then- insert a message something to the effect : "POC's of record have been attempted to be notified of this allocation being LAME at the IN-ADDR.arpa. If during a period not to exceed 180 days from $DATE the IN-ADDR.ARPA. for this entry is still LAME it will be removed from the ARIN IN-ADDR.ARPA. resolution services . This -WILL- result in some if not a complete disruption of services in this allocation ." THEN at 180 days of -continuosly- being LAME remove the entry from the IN-ADDR.ARPA. table . > On the first point, for an organisation to put its listed nameserver(s) > behind a firewall that blocks ad-hoc DNS queries for the zone that has > been delegated to it would imply that they do not know what they are > doing. Hence, ARIN is proposing to notify said networks, at which point > one hopes that the organisation in question will reconfigure their > firewall. Hmm , If they have filtered themselves into oblivion , when are they going to receive that (filtered?) email from ARIN ? Since according to the draft the in-addr.arpa. has been removed . > On the second point, some nameservers would undoubtedly be unreachable > from a single point on the Internet. Based on observations when I ran > through all the APNIC delegations many moons ago, such a state is not > permanent ie, all nameservers that APNIC delegated to were reachable at > various times over 3 days. ARIN may of course have a different experience > (although I doubt it, as the Internet in Asia-Pacific is generally more > flakey than the Internet in the ARIN region). I'm sorry I have seen (smaller) providers with allocations forced off net by the only provider in the area not having enough personnel to fix the circuits & the secondary goes stale ... Bad design I'll admit but still ... > Having suggested a project like this whilst @APNIC, I'm pleased to see > that it is being undertaken by someone ;). I agree that these steps are necessary . Just give the people a chance to get things straightened out & lines of communicatons fixed before blowing holes in their services . > Regards, > -- > Bruce Campbell RIPE > ( Formerly Senior Systems ) NCC > ( Administrator - APNIC ) Operations James W. Laferriere Research Engineer jlaferriere at adelphia.net 814.260.3697 Voice 814.260.3760 Fax From jfleming at anet.com Wed Jan 16 14:15:59 2002 From: jfleming at anet.com (Jim Fleming) Date: Wed, 16 Jan 2002 11:15:59 -0800 Subject: Lame Delegations References: Message-ID: <009201c19ec2$7ee47530$0100a8c0@repligate> In my opinion, the entire "ARIN task" and the "IANA task" could be easily automated by some PHP and MySQL programmers. It is a simple allocation and deallocation problem. More automation would encourage the "customers" to make sure they use their allocation, because they would realize that automated systems, with the source code viewable in public, have policies built in for auto-reclamation. A forum of open-source programmers could be adding to that code base. ARIN has millions of dollars in "cash reserves". The non-profit ARIN now out-sources the operation of the IN-ADDR.ARPA zone to for-profit companies. Has ARIN disclosed the details of those contracts ? Why does it take such large staffs to perform the "ARIN task" and the "IANA task" (ICANN) ? If ARIN and ICANN do not even operate any servers, what are all of the fees for ? Jim Fleming 2002:[IPv4]:000X:03DB http://www.IPv8.info ----- Original Message ----- From: "ginny listman" To: Sent: Tuesday, January 15, 2002 9:15 AM Subject: Lame Delegations > Please comment on the following: > > ARIN would like to remove lame delegations the IN-ADDR.ARPA zone file > after 7 consecutive days during which queries return an invalid response > for more than 50% of the network. > > PURPOSE: As the zone files continue to grow, additional queries put > additional stress and strain on the servers, as well as generating > additional Internet traffic. These "requeries" are fully defined in > the Internet Draft . > > PROCEDURE: > 1. ARIN will have a designated machine to query all name servers listed in > the database for all networks. This will include name servers that are > considered to be lame and/or invalid. Logs will be generated and > retained for 30 days. > 2. The database will keep track of when and how long name servers are > lame. > 3. Any name server that is lame for more than 7 days will be excluded from > the zone files. > 4. On the 7th consecutive day a name server is lame, an email will be sent > to the network POC(s), stating the name server will not be included in > the zone file. Since this is a courtesy email, those returned > undeliverable will be ignored. > 5. Any name server that is lame for more than 7 days, will be marked > "LAME" in the network Whois display. > 6. Lame delegations will be removed from the database after 180 days > during which queries return an invalid response for more than 50% of > the network. > > > Ginny Listman > Director of Engineering > ARIN > From ginny at arin.net Thu Jan 31 11:56:48 2002 From: ginny at arin.net (ginny listman) Date: Thu, 31 Jan 2002 11:56:48 -0500 (EST) Subject: Handle Generation Message-ID: As a feature of the new database, organizations will have full control over their network and AS names. Therefore, network and AS names no longer need to be unique. Also, it will be much easier for an organization to change the network and AS names. For these reasons, we want to get away from using the AS or network name to generate a unique handle. All future ASes will have a handle in the format of AS## where ## will be the autonomous system number. In the case of AS blocks, it will be the first in the block of autonomous system numbers. All future networks will have a handle of NET-##-##-##-##<-sequence> where ## represents each of the 4 octets for v4 networks or the 8 16-bit hexadecimal pieces for v6 networks, of the first IP address. For both v4 and v6 networks, the will be applied only in the case of duplicates, e.g., in the case of reassignments of the first portion of the network. To make the database more uniform and to completely disassociate handle usage from network and AS names, we would also like to replace existing handles with this new format. How many of you out there are attached to the existing handles? Will changing existing handles be a benefit or a hinderance? Ginny Listman Director of Engineering ARIN