Inklings: a tumblelog

I’m not revealing anything terribly top secret by posting this explanation up here, and if you’re not involved in writing domain management systems, this will all be pure waffle to you, but if you are and you’ve the pleasure of dealing with VeriSign’s EPP backend for .com, .net, &c., and are being driven demented by some of their documentation, this may help you understand what’s going on.

The key thing to remember is that VeriSign’s domain management system is not unified; rather they have a single EPP endpoint, and a mechanism for routing requests towards their various domain management systems. This mechanism is the Name Store. Now, nowhere is the explicitly stated in the documentation for VeriSign’s EPP implementation, absolutely nowhere.

Thus, you can’t just create host and domain objects as you normally would with other registries; you need to treat every zone like its own registry.

So to register a .com domain, you must do this:

<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
     xmlns:namestoreExt="http://www.verisign-grs.com/epp/namestoreExt-1.1">
<command>
  <create>
    <domain:create>
      <domain:name>EXAMPLE.COM</domain:name>
      <domain:period unit="y">1</domain:period>
      <domain:ns>
        <domain:hostObj>NS1.EXAMPLE.COM</domain:hostObj>
        <domain:hostObj>NS2.EXAMPLE.COM</domain:hostObj>
      </domain:ns>
      <domain:authInfo>
        <domain:pw>my-auth-code1</domain:pw>
      </domain:authInfo>
    </domain:create>
  </create>
  <extension>
    <namestoreExt:namestoreExt>
      <namestoreExt:subProduct>dotCOM</namestoreExt:subProduct>
    </namestoreExt:namestoreExt>
  </extension>
  <clTRID>ABC-12345-XYZ</clTRID>
</command>
</epp>

And if you want to check the availability of a bunch of .com and .net domains, you have to split them into two separate lists, one for .com and the other for .net and use the appropriate subproduct in the Name Store extension. Yep, this is an enormous pain in the behind, but it’s necessary.

You must also do the same when checking for host objects or creating them - if you’re checking creating the host objects for use with a .com domain, you need to specify the dotCOM subproduct, and so on. The actual host objects themselves are totally immaterial.

I can’t fathom why VeriSign decided to expose this extra complexity - it most definitely doesn’t help those of us who have to talk to their systems.