Message List – Telnic Developer Site

Tools (#3) - how do you determine which tel hosting api url? (#110) - Message List

how do you determine which tel hosting api url?

Hi - I have 5 .tels that I purchased with different registrars. I have a simple tool to allow updating values but the problem I run up against is each registrar has a different url. Is there a way to query a .tel and determine the registrar url?

here's an example for cto.tel hosted by domainmonster

hosting platform url (https://telhosting.domainmonster.com/login/login.action)

and here's the results from query the dns for cto.tel... how do I tie the two together?

Tree View Flat View (newer first) Flat View (older first)

Message #270

just did some more research (thanks to Henri on another thread) and found correct thing to do was query _soap._nspapi.[YOUR-DOMAIN].tel instead of the domain

oddly enough _web._nspapi.[YOUR-DOMAIN].tel for the json api returns nothing

I've tried different permutations of this, but all return nothing. What's the correct dns query for the json api?

ssehdev

04/08/09 18:26:38
- Message #276
  
  There's no pure JSON API dns query. You get it by querying:
  
  _https._nsp._apps.[YOUR-DOMAIN].tel
  
  this gives you the url for your telhosting provider. (you can also do _http) Then append /g2/json and you've got your SOAP API entrypoint.
  
  There are essentially 2 areas of interest for autoprovisioning:
  
  _apps.[YOUR-DOMAIN].tel is the one where any application can enter URLs of interest to itself for autoprovisioning (assuming the owner lets it, or the owner does it himself, of course).
  
  _nspapi.[YOUR-DOMAIN].tel is the area for the canonical APIs for the Telhosting.
  
  At this time, the SOAP API is the only canonical API. The JSON API is a work in progress and hasn't been 100% 'blessed', which is why it's not in the _nspapi subdomain.
  
  henri
  
  04/12/09 11:10:35
- Message #287
  First, I also thought a query to _soap._nspapi.[YOUR-DOMAIN].tel would return nothing. But I mistakenly looked for an A-record (which is implicit done when not specifying in dig/nslookup).
  
  For what I understand, the information is stored in an NAPTR-Record. So try the following on the console an you’d be happier (instead of ANY you could also use NAPTR):
```
dig _soap._nspapi.cto.tel ANY
```
  @henri: If the above is true, there should perhaps also be a hint in the FAQ about that.
  richard.woeber
  
  04/15/09 14:23:11
  - Message #288
    
    We do have an entry in the FAQ about end-points; if you think more details need to be added, let me know.
    
    I'm also thinking of re-doing the developer guide a bit, adding the currently missing starting part and using the bits of Perl code as examples, not just Java BB code. If you have suggestions, you're most welcome.
    
    nadya
    
    04/15/09 14:30:59
    - Message #290
      We do have an entry in the FAQ about end-points; if you think more details need to be added, let me know.
      
      Yep. You do! You mean this one, right?:
      
      Use DIG/nslookup commands and query _soap._nspapi.yourTelDomain.tel. ...
      
      I saw 2-3 topics in the forum where people did not found an entry for that given subdomain-schema, and I assumed they did the same mistake that I did in the first place.
      
      The problem for me was that (at least) my dig- and nslookup-clients seem to implicitly give back only A-records. For what is my experience, not every developer knows about this. (Took me over an hour to find out).
      
      I think some people may interpret the FAQ-message to do just something like
      
      nslookup _soap._nspapi.xyz.tel
      which will, of course give an empty result.
      
      You know, your documentation is absolutely correct there, but I think it would help some people to give a small hint to do an explicit query for an NAPTR-record (or give a code sample).
      richard.woeber
      
      04/15/09 15:20:06
      - Message #291
        
        Point taken, I will add detail to the faq entry.
        
        nadya
        
        04/15/09 16:42:37
      - Message #524
        
        Oddly the nslookup does not work for me, but the dig does. I get the following error. ** server can't find _soap._nspapi.mharris.tel: NXDOMAIN
        
        These are the two commands I ran.
        
        nslookup _soap._nspapi.mharris.tel
        
        dig _soap._nspapi.mharris.tel naptr
        
        Having never used either command before, it would speed things up for newbies like myself if you could add examples of both to the site.
        
        thanks.
        
        martinh
        
        06/24/09 12:43:27
        
        Message #526
        
        Correct nslookup is
        
        ==== $ nslookup -type=naptr _soap._nspapi.mharris.tel Server: 192.15.1.10 Address: 192.15.1.10#53
        Non-authoritative answer:
        
        _soap._nspapi.mharris.tel naptr = 10 10 "u" "E2U+web:http" "!^.*$!http://telhosting.domainmonster.com/client!" . _soap._nspapi.mharris.tel naptr = 10 10 "u" "E2U+web:https" "!^.*$!https://telhosting.domainmonster.com/client!" .
        Authoritative answers can be found from:
        
        mharris.tel nameserver = N0.CTH.DNS.NIC.tel. mharris.tel nameserver = T0.CTH.DNS.NIC.tel. mharris.tel nameserver = S0.CTH.DNS.NIC.tel. mharris.tel nameserver = A0.CTH.DNS.NIC.tel. mharris.tel nameserver = D0.CTH.DNS.NIC.tel. D0.CTH.DNS.NIC.tel internet address = 195.253.47.64
        ====
        
        Please note that the exact nslookup command line options may differ depending on the version/OS. A more modern alternative to nslookup is host:
        
        ==== $ host -t naptr _soap._nspapi.mharris.tel _soap._nspapi.mharris.tel has NAPTR record 10 10 "u" "E2U+web:http" "!^.*$!http://telhosting.domainmonster.com/client!" . _soap._nspapi.mharris.tel has NAPTR record 10 10 "u" "E2U+web:https" "!^.*$!https://telhosting.domainmonster.com/client!" . ===
        
        nadya
        
        06/26/09 14:41:09
  - Message #289
    
    Don't ever use "ANY". ANY is not properly supported by most DNS servers. Depending on the DNS server you're hitting, you may or may not receive data, and you may or may not receive NAPTR or TXT or even LOC.
    
    Always exactly query the type you want.
    
    henri
    
    04/15/09 14:48:50

Tree View Flat View (newer first) Flat View (older first)