[ppml] Comments on ARIN's reverse DNS mapping policy

[John Von Essen]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070912/1f66f847/attachment.htm>