These guidelines are our advice and recommendations on how to handle various issues involved in client development to ensure that the client does not violate our policies.
System Startup and DHCP Leases
Clients should store the IP in some form of permanent storage, so that restarting the system (for software clients) or power cycling the device (for hardware clients) does not cause the client to update unless the IP is changed. Since IPs rarely change on DHCP lease renewals, clients must not update every time a DHCP lease is renewed. Instead they must check the new IP and determine if it differs from the old IP before updating.
Clients should not perform DNS queries to determine whether it is necessary to update. The danger is that the ISP’s DNS server will be caching the old IP for a few minutes, leading the client to conclude the update failed and causing a loop.
The HTTP headers returned may be status 200 (OK), 401 (Authorization Required) or 500 (Internal Server Error). The response body should be parsed for return codes no matter what this status is; a 911 return code will most likely have a HTTP status 500. The HTTP status will not indicate any particular message. Rely on the return codes instead.
Users need to enter a username and password, each up to 24 characters long. They will also enter a list of hostnames to be updated. It is important that the single hostname field is long enough (100-200 characters).
As noted on the update syntax page, updates for Webhop hosts are ignored.