Testing Procedure
The test procedure is designed to simulate the types of situations that DynDNS clients are likely to encounter in the field in order to ensure that your client will behave well in the most unusual of conditions. This testing guide is only intended as a supplement to the documentation found in the DNS Update API.
DynDNS uses manual and automatic mechanisms to perform testing. While automatic testing is challenging because of the reliance on the user interface, DynDNS recommends QA Cafe's CDRouter Testsuite.
For a client to become DynDNS Certified, it must pass a number of tests, and meet the following requirements:
Basic Requirements
- Client must have a unique user agent, identifying their company, product, and software build revision (eg "$company $product $softwarerev").
- Client must be off by default.
- Client must be able to be turned on and off.
- Client must not update on reboot unless necessary.
- Client must check that all user input is valid before sending.
- Client must ONLY update when the WAN IP address changes or if a setting has changed (mx, backmx, wildcard...).
- Client must not use a DNS query to check a hostname under testing.
- Client must not query CheckIP more than once every 10 minutes.
- Client should not limit hostname size to anything less than 255 characters.
Optional Functionality
- backmx - Support for backmx option. Non-supporting clients must send NOCHG.
- mx - Support for mx option. Non-supporting clients must send NOCHG.
- wildcard - Support for wildcard option. Non-supporting clients must send NOCHG.
- offline - Support for offline option. Non-supporting clients must send nothing.
Response Handling
Clients must parse response codes, handle any errors, and notify users of the results. See the return codes for details.