Detecting the IP Change

To determine whether a client should update, it must have a reliable method to determine what its current IP address is so it can compare the current address to the last updated address. There are two methods.

Internal Method

A client may determine, automatically or through the input of the user, that it is directly connected to the Internet. The device would have a publicly addressable IP address. In this case, the optimal method is to obtain the IP address from the operating system’s network stack.

Web IP Detection (CheckIP)

A client may determine, automatically or through the input of the user, that it is not directly connected to the Internet. The client is on a machine with a private IP, usually on RFC 1918 space (10/8, 172.16/12, 192.168/16). In this case, the optimal method is to use web IP detection.

Dyn.rs operates a CheckIP service which may be used with clients that work with DynDNS.

Update Requests

After a change in IP address has been detected or a user alters any of their settings, the client should perform an update. All updates are sent using a well-formed HTTP request. The system will pass back a return code in the response body that the client needs to parse.

The HTTP Request

Hostname: dyn.rs
URI: /nic/update
Methods: GET, POST
HTTP Ports: 80, 8245
HTTPS Port: 443

Updates can be performed over HTTP or SSL/TLS-encrypted HTTPS (preferred).

All requests should be sent to hostname dyn.rs. Hard coding the IP address is not acceptable as the IP address may change.

The update interface listens on ports 80 and 8245 for HTTP, and 443 for HTTPS. Port 8245 may be used to bypass transparent HTTP proxies. It is not necessary to open any incoming ports (or allow incoming ICMP) for updating.

Examples

These examples are provided only as samples, for better understanding of the process.


Authentication in URL

For web-browsers or utility programs (fetch, curl, lwp-request) that can parse authentication section in URL.

https://{username}:{password}@dyn.rs/nic/update?hostname={hostname}&myip={IP Address}

Curl command-line example

curl -ks -u {username}:{password} "https://dyn.rs/nic/update/?hostname={hostname}&myip={IP Address}"

Raw HTTP GET Request

Actual HTTP request should look like following fragment. Note that there is the bare minimum set of headers. Request should be followed by sending an empty line.

Fragment base-64-authorization should be represented by Base 64 encoded username:password string.

GET /nic/update?hostname=yourhostname&myip=ipaddress HTTP/1.0
Host: dyn.rs
Authorization: Basic base-64-authorization
User-Agent: Company - Device - Version Number

Please note that both GET and POST requests are permitted and will be processed.


Update Parameters

Field Description Additional Info
hostname A hostname (with or without the domain part) to be updated. This is a required field. The hostname specified will be updated with the IP information, and the final return code will be returned.

For example, if your username is johndoe, your primary hostname will be johndoe.dyn.rs. Let's say you have already created an additional hostname in the control panel: home.johndoe.dyn.rs.
Beside specifying the full hostnames, you can also use only 4th level host names. If you'd like to update your default hostname johndoe.dyn.rs, which is a most common case, you can specify an empty string or just - as a hostname. Example:

   hostname=johndoe.dyn.rs
   hostname=-
or hostname=
To update the hostname of the 4th level, you can specify it in one of the following ways:
   hostname=home.johndoe.dyn.rs
or hostname=home
myip IPv4 or IPv6 address to set for the update. If this parameter is not specified, the best IP address the server can determine will be used (some proxy configurations pass the IP in a header, and that is detected by the server). If the IP address passed to the system is not properly formed, it will be ignored and the system’s best guess will be used.

Return Codes

When updating a hostname, the response to the update request will be one of the short return codes described below, followed by one space or tab character, and the appropriate message (everything after the first blank character to the end of the line). If there is an error, clients should communicate to the user a brief description of the problem that the return code indicates. All the return codes are given in the response body, with appropriate HTTP codes that indicate success (2xx), client error (4xx), or server error (5xx).

Update Types

SUCCESS: Successful update
INFO: Less important error, for example when trying to make an update with the same IP as last time.
ERROR: An error that should probably be shown or mailed to the user, for instance on failed authorization, suspended account, etc.