[dns-operations] Typo in fox.com and an Akamai squatter
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
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.
More information about the dns-operations