[dns-operations] Typo in fox.com and an Akamai squatter

[Mark Andrews]

In message <20160202030910.GA5642 at mycre.ws>, Robert Edmonds writes:
> Mark Andrews wrote:
> > Where is the permission to waive this section if RFC 1034 granted
> > to ICANN?
> 
> This is a strange question.  ICANN's "Memorandum of Understanding
> (MOU)/Joint Project Agreement (JPA)" with the U.S. Department of
> Commerce doesn't appear to mention any individual RFCs at all.  The
> closest thing I can find dealing with ICANN's authority over technical
> requirements is the following, from the second amendment to that
> document:
> 
>      ICANN agrees to perform the following activities and provide the
>      following resources in support of the DNS Project and further
>      agrees to undertake the following activities pursuant to its
>      procedures as set forth in Attachment B (Articles of Incorporation)
>      and Attachment C (By-Laws), as they may be revised from time to
>      time in conformity with the DNS Project:
> 
>         [...]
> 
>         7. ICANN will continue the process of implementing new TLDs
>         including proceeding with a proof of concept or testbed period
>         and continuing design, development, and testing to determine
>         future policy and action, continuing to consider:
> 
>             [...]
> 
>             b. The creation and implementation of minimum criteria for
>             new and existing TLD registries.
> 
>             [...]
> 
>         [...]
> 
>     (https://www.icann.org/resources/unthemed-pages/amend2-jpamou-2000-09-07-
> en)
>     (https://www.ntia.doc.gov/page/2000/icann-ammendment-2)
> 
> Note that I didn't say that any particular section of 1034 is waived in
> ICANN's "Functional and Performance Specifications".  I only observe
> that a recommendation like "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" appearing in a section called "Administrative
> considerations" probably cannot be elevated into the kind of RFC
> conformance violation that would trigger contractual non-compliance.
> 
> > RFC 1034 was binding on registries well before ICANN took over this
> > role and the communities expectation was that all of RFC 1034 would
> > apply.  This sounds like ICANN botched the registry agreement.
> 
> Can you explain how any RFCs were made binding on registries in the
> pre-ICANN period (especially for TLDs like .com that pre-date 1034)?
> Everything I've read about this period indicates that there were few
> formal agreements, especially with ccTLD registries.

The RFC series provided instructions for everyone on how to administer
the DNS.  This included SRI in their registry role for COM, NET and
ORG.  RFC were expected to be followed.

Note: RFC973 also contains the requirement that the records be
consistent and this pre-dates the IETF.

         The child zone and the parent zone have identical NS RRs for
         the ISI.EDU domain.  This guarantees that no matter which
         server is asked about the ISI.EDU domain, the same set of name
         servers is returned.

> The only thing related to this topic that I've been able to find is this
> rather unspecific text in RFC 1591:
> 
>     In cases when there are persistent problems with the proper
>     operation of a domain, the delegation may be revoked, and possibly
>     delegated to another designated manager.
> 
> (Though, I don't think ignoring a "should", when DNS resolution
> otherwise works fine, amounts to a "persistent problem" requiring the
> penalty of undelegation.)
> 
> -- 
> Robert Edmonds
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org