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

[David Hilario]

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-dn
s/master/sample-implementation/afpub-2017-lame-dns-sample-
ops-manual-draft-00.txt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170414/293da73d/attachment-0001.html>