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

Fri Apr 14 17:55:13 UTC 2017

Hi David,

The staff analysis shall provide us more insight on how many domain are fully broken or have only one working NS record.

Although, a previous study [1,2] doesn’t provide you the exact detail, it gives some amount of details.

Regards,
Amreesh

[1] http://afrinic.net/blog/165-how-lame-are-our-reverse-delegations
[2] https://afrinic.net/en/library/news/afrinic-publications/2029-dns-lame-delegation

> On 14 Apr 2017, at 17:58, David Hilario <d.hilario at laruscloudservice.net> wrote:
> 
> Hi Nishal,
> 
> It all sounds good :)
> Automation is the way to go for these thing.
> 
> But sometimes people choose the hard road for whatever reason, usually because it is easier at first.
> I just want to make sure we don't later hear that SLC is breached due to too much time spent on this policy once implemented.
> 
> Just out of curiosity:
> 
> A:
> How many domain objects are fully broken?
> 
> B:
> How many have only one working Nserver?
> 
> Best regards,
> David
> 
> 
> On Apr 14, 2017 2:41 PM, "Nishal Goburdhan" <nishal at controlfreak.co.za> wrote:
> 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
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd