[rpd] New Proposal: Lame delegations in AFRINIC reverse DNS

[Nishal Goburdhan]

On 14 Apr 2017, at 12:51, David Hilario wrote:

> Hi Daniel,
> Thanks for the reply.
>
> I do support the end goal of this policy proposal, I just want more
> information.

hi david,

of course;  as we said initially, we expect there to be an interesting 
thoughts on how to implement, and that’s why we produced a *sample* 
guideline [1].  but discussing implementation is not the same as 
discussing policy, and this list if for policy. so that’s why we’d 
prefer to not take up airspace here, discussing implementation.  (well, 
we’re guided by the PDPWG co-chairs in this, so if you’d prefer us 
to .. ??)

i don’t think it’s possible for afrinic to give you concrete 
implementation steps and 100% guarantees, without a ratified policy, so, 
while i think it’s reasonable to have you concerns about this taking 
up staff resources, might i suggest we let afrinic respond to that as 
part of the “staff assessment” part of the process, which, i guess, 
would come up closer to the meeting date.  i’m trusting that the 
afrinic team working on policy has taken your concerns to heart, and 
will respond accordingly.

on a personal level, i’d state support for what you wrote about 
automation;  i don’t believe this should be done manually, and i trust 
the afrinic team that implements this, are intelligent enough to do 
that, since the addition process is already automated  ;-)


> Let's say we have a policy proposal that demands that AFRINIC ltd 
> verifies
> all postal address provided in the AFRINIC Database, with no clear
> implementation guidelines and the policy gets approved.

in the interests of keeping this discussion on-topic, might i ask that 
we *not* introduce theoretical discussion around items that this policy 
does not try to introduce.  it’s very tempting to add analogies, and 
stories, but the risk is that they are often hyperbolic, or incorrect  
(there’s another thread running, that should help make my point :-))  
i think that we are all capable enough of discussing *what the text 
says*.
your example is interesting, and might be text for a future policy :-)  
but spending cycles talking about that, and not the *one single goal* 
(see the problem statement) that we have tried to focus on here, is not 
our intent.


>> How would the historical information be provided?
> A bit more guidelines would be good here as well.
> This leaves AFRINIC staff open to criticism in case people do not like 
> the
> final implementation.
>
> I anyway do not even really see a need for that info to be provided.
> If name servers are removed but the domain object is still present,
> historical info is available via whois queries as long as the object 
> is not
> deleted from the Database.

nishal at jnb:~$ whois -t domain whois.afrinic.net
[snip]
domain:         [mandatory]  [single]     [primary/lookup key]
descr:          [optional]   [multiple]   [ ]
org:            [optional]   [multiple]   [inverse key]
admin-c:        [mandatory]  [multiple]   [inverse key]
tech-c:         [mandatory]  [multiple]   [inverse key]
zone-c:         [mandatory]  [multiple]   [inverse key]
nserver:        [mandatory]  [multiple]   [inverse key]
[snip]

domain objects can’t exist without nserver field, as the nserver field 
is mandatory, so the domain object would have to be deleted.


> If the full object is removed, the maintainer etc, should had received 
> a
> notification from the automated system with a copy of the object from 
> the
> hopefully automated notification system prior to the deletion.
> And should again receive some form of notification from the database 
> with a
> copy of the object once it is deleted.

my understanding is that writes in/out of a database can be tracked, so 
there’s already means to track this information.
i think your suggestion is a good one;  this is what the suggested 
implementation plan reads :

    +----------+------------+-------------------------------------------+
    | Timeline |   Event    |                  Actions                  
|
    +----------+------------+-------------------------------------------+
    |  Day 0   |    Lame    |  Lame delegation is recorded. Nameserver  
|
    |          | delegation |  is re-tested for lame delegation every 3 
|
    |          |  is first  |                   days.                   
|
    |          | detected.  |                                           
|
    |  Day 15  | Delegation |   A remark is added in the domain object  
|
    |          |  is still  |      for the lame nameservers. Email      
|
    |          |  detected  |   notification is sent every 5 days for   
|
    |          |  as lame   |    another 15 days (3 notifications) to   
|
    |          |  (after 5  |      "Admin-C", "Tech-C" and "Zone-C"     
|
    |          | additional |  contacts. Lameness checks are still run  
|
    |          |  checks).  | every 3 days. If a nameserver is not lame 
|
    |          |            |    anymore, the corresponding remark is   
|
    |          |            |                  removed.                 
|
    |  Day 30  | Delegation |  The "nserver" record is removed from all 
|
    |          |  is still  |    "domain" objects containing it. Any    
|
    |          |   lame.    |     "domain" object that thus has zero    
|
    |          |            |   "nserver" records, is removed from the  
|
    |          |            |   WHOIS database. "Admin-C" and "Tech-C"  
|
    |          |            |  contacts are notified of all changes. In 
|
    |          |            |    all instances the original "domain"    
|
    |          |            |            object is archived.            
|
    +----------+------------+-------------------------------------------+

2.3.3.  Object Archival

    All nameserver records and domain objects removed from the visible
    WHOIS database should be viewable on the MyAFRINIC portal for a
    period of 90 days.  After 90 days, the archived version will be
    discarded permanently.


is this something that you think should be in the actual policy text?
if not, we’d happily accept a pull request to the implementation plan 
text.

as a reminder, the sample implementation plan is how we *think* this 
could be done, and this is a *hint* to the afrinic team in how/what to 
implement.

—n.

[1]  
https://raw.githubusercontent.com/techdad/afpub-2017-lame-dns/master/sample-implementation/afpub-2017-lame-dns-sample-ops-manual-draft-00.txt