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

[Mark Andrews]

In message <20160202001658.GA31880 at mycre.ws>, Robert Edmonds writes:
> Mark Andrews wrote:
> > And if the TLD had followed the rules in RFC 1034 this would have
> > been caught.
> > 
> >   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.
> > 
> > Mistakes happen.  Cross checking for inconstistancies catches errors.
> > 
> > Every registry knew about this rule when taking on the registry
> > role.  All of them with the exception of IANA post date RFC 1034.
> 
> I was curious how RFC 1034 came to be binding on this particular
> registry, or even if it was binding at all, so I looked it up.  Here is
> the .com Registry Agreement:
> 
>     https://www.icann.org/resources/pages/com-2012-12-07-en

Where is the permission to waive this section if RFC 1034 granted
to ICANN?  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.

> Specifically, Appendix 7 to the agreement contains the "Functional and
> Performance Specifications":
> 
>     https://www.icann.org/resources/pages/com-2012-12-07-en
> 
> There are a number of RFCs that the agreement cites by number, including
> a series of EPP and DNS documents.  The "Nameserver functional
> specifications" section requires that:
> 
>     Nameserver operations for the Registry TLD shall comply with RFCs
>     1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966
>     published by the Internet Engineering Task Force ("IETF") and/or any
>     successor standards, versions, modifications or additions thereto.
> 
> The section on "Performance specifications" defines a nameserver as:
> 
>     "DNS Name Server" means the service complying with RFC 1034, 1035
>     and related RFCs made available on TCP/UDP port 53 on Registry
>     Operator's selected servers.
> 
> Read narrowly, the registry agreement doesn't make every single
> "Administrative consideration" from RFC 1034, 1035, etc. binding on the
> registry operator, only the normative parts defining the TCP/UDP port 53
> protocol.
> 
> Many other registries besides this one do not have binding agreements in
> place at all.
> 
> -- 
> 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