Lame Delegations

[James W. Laferriere]

	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<URL:to explanation> 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<URL:to explanation>
	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