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

[Mark Andrews]

In message <CABSP1OcRAxWSRNgYAjef9VuCCsE5Jey9YRg7F-3j1aYKPDhrAg at mail.gmail.com>
, Damian Menscher writes:
> 
> 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

ISNIC's rules go a bit past the minimum required for a working delegation.

* 3c really has no external impact. All zeros work when the zone contents
  are being transfered by other means than axfr/ixfr.
* 4 consistent should not mean identical for the SOA.  The serial should be
  exempted.
* 7 while having PTR records is useful the test should be that the reverse
  lookup resolves.  NXDOMAIN shouls be a acceptable response.  If PTR records
  exist then the forward lookup for those should exist.  There should be
  no requirement that they match the registered name of the nameservers.

What is missing is:

All the nameservers listed must resolve to a A or AAAA record and
should resolve to both A and AAAA records.  The A and AAAA records
must be consistent with those registered with ISNIC.  The A record
must not be a RFC 1918 address.  The AAAA records must not be link
local addresses, site local address, ULA addresses or mapped IPv4
addresses.  The must not list is not exhaustive.  The A or AAAA
lookup must not resolve to NXDOMAIN, be REFUSED or return NOTIMP.
The resolution of the A and AAAA must not involve a CNAME or a
DNAME.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org