[dns-operations] The strange case of fox.com
marka at isc.org
Mon Feb 29 22:40:53 UTC 2016
In message <22228.27038.63890.832875 at tale.kendall.corp.akamai.com>, David C Law
> Mark Andrews writes:
> > Note: this should have been caught by the registry when it is
> > checking the delegation as per RFC 1034. Registries have two sets
> > of customers and failing to perform the checks is doing a disservice
> > to *both* sets of customers.
> I don't see an expectation in 1034 that a registry will perform
> continuous monitoring of delegations. Have I overlooked a relevant
Note the words "and remain so". You cannot do that without continious
RFC 1034 4.2.2. Administrative considerations
"As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone. The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so."
> When the zone in question was first established over 15 years ago I
> presume that it had a working apex NS set. It also did when its
> delegation was subsequently updated to point to its current
> nameservers, what looks like happened half a decade ago. The change
> to the broken apex NS RRset happened a couple of months ago (and was
> detected, and was reported to the customer).
> Verisign as the .com registry should have detected the change? What
> should they have done when they discovered it was broken?
Contact the zone owners to inform them that the delegation is not
consistent and to request that they update the approptiate records.
This is what they signed up to do when they took over the management
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> dns-jobs mailing list
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the dns-operations