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

Robert Edmonds edmonds at mycre.ws
Tue Feb 2 00:16:58 UTC 2016

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:


Specifically, Appendix 7 to the agreement contains the "Functional and
Performance Specifications":


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

Many other registries besides this one do not have binding agreements in
place at all.

Robert Edmonds

More information about the dns-operations mailing list