[dns-operations] registry/registrar/registrant delegation checks for fun and profit

[Einar Lönn]

On 02 Mar 2016, at 03:27, Randy Bush <randy at psg.com> wrote:

>> Running counter to this, and purely for information, It was reported some
>> while ago that CNNIC employed a few thousand students over a summer holiday
>> to contact every domain-name holder in the .CN covered namespace and
>> perform basic ID checks with them.
>> 
>> If a registrar "can't do this for commercial/profit reasons" then maybe the
>> contract for provision of service needs a review?
> 
> a one-time spot check is great, but does not approach the problem of
> continuous monitoring.
> 
> randy

We track changes in our zones (.SE and .NU), run our tool DNSCheck on every zone that change in between zone updates (frequency 2 hours), and store this data. At the end of each day we look at these results, compile summarized lists / registrar with domains *that still have problems at level ERROR or above*, and send these to the Registrars *who want them* (absolutely not opt-out, spamming and threatening gets you nowhere as many have said before; it’s hard to find the person that *actually* controls the zones).

We’ve been running this for a few years now and (we think / hope) the combination of opt-in with the fact that we quite often notice things the DNS-operators and/or Registrars cant catch themselves is a great help to the quality of our zone. It’s continous (all changes are tracked as we own the zonefile), non-invasive (opt-in) and doesnt try to threaten anyone.

I also know we try and “clean” database data in a similar, but slightly less ambitious, way that CNNIC did. In the end it might be worth it to have close-to-correct data in your systems (clean out the worst at least).


	/Regards, Einar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160302/24db90e1/attachment.sig>