[ppml] Comments on ARIN's reverse DNS mapping policy
bmanning at vacation.karoshi.com
bmanning at vacation.karoshi.com
Wed Sep 12 21:51:51 EDT 2007
- Previous message: [ppml] Comments on ARIN's reverse DNS mapping policy
- Next message: [ppml] Comments on ARIN's reverse DNS mapping policy
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
there are some people who do this testing already ... we don't do the email's any more, since ARIN came into existance... but we still run the tests. --bill On Wed, Sep 12, 2007 at 11:58:32AM -0400, John Von Essen wrote: > I agree. > > I have no sympathy for the response of "testing all these in- > addr.arpa zones is too much work". Granted, we are only talking > about /24 prefixes. > > The entire process can be easily automated, and that includes the SOA > query testing to delegated DNS servers for an Org's address block, > updating an internal tracking database, and even the process of > emailing the Org's POC for DNS. The Org's that get emailed the > warning could even be given a link to click when they have resolved > the issue. That link would automatically re-check, and if SOA > response is valid, would automatically remove them from the database > of "delinquents". > > So for the Org's that fix things in a timely fashion following the > automatic email - ARIN staff will never even have to get involved. > Staff would only get involved with those Org's that dont respond to > the initial emails. > > -john > > > On Sep 12, 2007, at 11:24 AM, Brian Dickson wrote: > > >Randy Bush wrote: > >>arin delegates 42.666.in-addr.arpa to the member isp. the servers > >>properly respond for that delegation. this seems to be about as > >>far as > >>current policy goes; though there are reported gaps in > >>implementation. > >> > >>the op wants us to say that, if the delegatee further delegates > >>sub-zones, then the service for those sub-zones must not be lame. > >> > >>aside from issues of whether the community has the right to > >>descend into > >>the delegation, how would we text the sub-delegations? if they > >>are on > >>byte boundaries, we can probe for them. but goddesses help us if > >>they > >>use rfc 2317. and is it our prerogative to probe 256 sub- > >>delegations of > >>a /16? 64k of a /8? and how many of a /32 in ipv6 space? > >> > >The "probing" is in fact, an exercise in tree-walking. > > > >Writing a script to handle this should be within the capabilities of > >ARIN, given the scope of other > >tools they no doubt need to handle administration of address > >assignments. > > > >The basic tree-walking should be limited to following delegations of > >expected form (numeric subzones > >within the expected ranges, either 0-1 or 0-255). Those are the only > >sub-delegations "of interest", > >i.e. which would otherwise have been directly delegated by ARIN. > > > >Optimizations can be done, since the expectation is one of positive > >responses to SOA queries. > >Low timeouts may generate false negatives, but no false positives. > >Re-testing false negatives with > >longer timeouts, produces the true negatives. > > > >The *main* question is, since in rfc 2317 the distance from ARIN in > >delegations can be >2, > >what should be done? > > > >I think the classic "him or you" answer scales best. Arin requests the > >delegatee to fix the subordinate, > >or have their delegation pulled, with the recommendation that they use > >the same tactic. > > > >At the leaf, the broken delegatee must either fix the problem or > >get pruned. > >If the delegator does not prune a still-broken leaf, then *his* > >delegator must do the same, or face > >being pruned him/herself. Etc. > > > >The responsibility with ARIN rests only in running test scripts, and > >contacting direct delegatees. > >All further communication is between third parties, within some set > >time > >frame. > > > >I *think* this would be able to be codified in the NRPM, as well as > >passing the scaling, sanity, > >and legitimacy/legality tests. > > > >Thoughts? > > > >Brian Dickson > >_______________________________________________ > >PPML > >You are receiving this message because you are subscribed to the > >ARIN Public Policy > >Mailing List (PPML at arin.net). > >Unsubscribe or manage your mailing list subscription at: > >http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > >Member Services > >Help Desk at info at arin.net if you experience any issues. > > Thanks, > John Von Essen > (800) 248-1736 ext 100 > john at quonix.net > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues.
- Previous message: [ppml] Comments on ARIN's reverse DNS mapping policy
- Next message: [ppml] Comments on ARIN's reverse DNS mapping policy
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the PPML mailing list