[dns-operations] The strange case of fox.com

[Damian Menscher]

On Wed, Mar 2, 2016 at 8:00 AM, <marius at isgate.is> wrote:

>
> > There is a whole lot of unwarranted fear about what would happen
> > if registries actually started enforcing delegation consistency.
> > We have lived through the DNS going from being a niche skill to
> > being a commodity product.  It is tainting our level of fear.
> >
> > Yes, people will complain about registries doing this, but ultimately
> > this is for the zone owners own good.  People will end up defending
> > registries that do this and a new better base level of practice
> > will be established.
>
> We have been enforcing delegation requirements on our registrants for
> over 25 years (from the beginning of the .is registry - modelled after
> .fr at the time) and have observed considerable improvement. Although
> we are a very small registry we do believe our methods would
> scale easily to larger registries.
>
> After delegation all domains are checked once a month and with
> the current setup we are checking about 1 domain per second
> (thus could scale to ~2M domains with the same setup.) If the domain
> no longer satisfies the .is requirements, it is tested weekly
> for eight weeks and progressively more of the domain's contacts
> informed of the problem (starting with the domain's zone contact
> which is assumed to be the operator of the domain's master nameserver).
> If the problem persists for over 8 weeks, the delegation is removed.
>
> We have found that over the years, more and more of our registrants
> (or their zone contacts) are grateful for the notification
> (as opposed to annoyed) and most have no problem fixing the faults
> with their authoritative NS setup or moving their DNS hosting services
> elsewhere.
>

Some constructive feedback on this: some (larger) providers make regular
updates to their zone files, and therefore the serial numbers are in
constant flux.  As changes are deployed, their different NS IPs will
occasionally be seen advertising different serials.  And while this is all
works perfectly well, it's a bit disconcerting to receive occasional
threats from ISNIC about removing their delegations.  The false positive
originates because ISNIC is detecting that the serials differ for a while
(a week?), not that one is actually failing to receive updates.  A simple
improvement (that doesn't require recording all serial numbers) would be to
remember what the two (different) serials were when the discrepancy was
first detected, then only flagging it as a problem if they continue to
differ a week later, *and* one of them is still stuck at the old value.  If
they differ, but have both changed, then it's likely working as intended,
and you're just getting unlucky by probing them during a routine update.

Damian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160306/c5602dc2/attachment.html>