Custom Dynamic DNS



  • There are hundreds of services which require an always updated IP Address that use a custom php script (or similar) that users have to call to have their IP updated.
    Although many of them can and have been added to the dynamic dns section in the services tab, there will always be many that are not there.  
    Is there any way a "Custom DDNS" service can be added?  
    ie. Call this URL with this parameter set to the new IP Address, and log output unless it is the following.
    Should be pretty simple to implement but would allow many other Dynamic IP Services.

    Thanks for the great project,
    Matt



  • Patches accepted.



  • Yes i would like the same thing, I use EveryDNS as a service (http://www.everydns.com/) and would like pfsense to do the updating…

    thanks


  • Rebel Alliance Developer Netgate

    If they publish an API or some kind of spec on doing remote updates, it might be possible.

    I added support for namecheap.com's DynDNS a week or two ago and it didn't take much, but they used a different API than any other DynDNS provider we had.

    Given the vast differences in how providers update, I doubt any generic method would be feasible and reliable.

    EDIT: Looks like everydns wouldn't be too hard to add, based on http://www.everydns.com/eDNS.pl - someone could probably work similar code into our dyndns.class without too much effort.



  • Yes, you are correct that there are vast differences in how providers update, however they all follow a fairly common set of rules.
    Usually something like send a request to URL "http://provider/update.php?username=un&password=Pa$$Key&ip=" then simply add the ip to the end and call fetch or php's http_get.  The results shouldn't be too hard to generate rules for.  Usually something very constant with maybe a date, or IP. 
    It really shouldn't be that hard to code, I might try to write something this weekend if I have time.


  • Rebel Alliance Developer Netgate

    Some do, yes. But their return codes vary wildly not only in text but also how they are delivered, and part of properly functioning dyndns updates is being able to detect successful updates and error conditions.

    So it might be doable, but it would require a bit of work to make sure it worked properly. :-)



  • @jimp:

    Some do, yes. But their return codes vary wildly not only in text but also how they are delivered, and part of properly functioning dyndns updates is being able to detect successful updates and error conditions.

    So it might be doable, but it would require a bit of work to make sure it worked properly. :-)

    Absolutely, but limited support is better than none.  
    I see nothing wrong with simply making the user enter a string like "IP Updated to: %IP" and check that the output exactly matches that string and the return code is 200, other wise assume a problem, log it and try again in a couple of minutes.



  • The way I see it there are two easy ways to implement support for Custom DNS:
    1. Write it into the current Dyndns scripts in pfSense.
    2. Use a prebuild dyndns program like http://www.inatech.eu/inadyn/: The one used by DD-WRT Firmwares to include custom dns.

    Although I think option 1 is a much better option, option 2 might allow for better support.  Some (few) DDNS Providers support DD-WRT and have instructions on how to add it, and using the same program would guarantee that the same configuration will work.
    I wouldn't mind doing option 1, but it might take me a while to get around to it.


  • Rebel Alliance Developer Netgate

    Doing it in pfSense may not be that hard - the code for dyndns isn't that hard to get around, it's easy to copy/paste and adjust.

    Adding some GUI bits for a "custom" option wouldn't be too difficult for someone who knows PHP, HTML and JavaScript.



  • @jimp:

    Doing it in pfSense may not be that hard - the code for dyndns isn't that hard to get around, it's easy to copy/paste and adjust.

    Adding some GUI bits for a "custom" option wouldn't be too difficult for someone who knows PHP, HTML and JavaScript.

    In that case, I'll go ahead and start working on it, though I might not have much time in the next week, so it might be a while before I can get around to finishing it.


  • Rebel Alliance Developer Netgate

    Sure. Most of the code you'd need to look at is in /etc/inc/dyndns.class and /usr/local/www/services_dyndns.php



  • The attached patches work, although the GUI could be done a bit nicer. 
    Just```
    patch -R /usr/local/www/services_dyndns.php < services_dyndns.php.txt
    patch -R /usr/local/www/services_dyndns_edit.php < services_dyndns_edit.php.txt
    patch -R /etc/inc/dyndns.class < dyndns.class.txt
    patch -R /etc/inc/services.inc < services.inc.txt

    Notes:
    Currently, the cache file used is {$g['conf_path']}/dyndns_{$dyndns['interface']}{$dyndns['type']}.cache, which will result in a shared cache file for any two DDNS settings on the same provider, this might cause problems for people with multiple Custom Entries. 
    
    The GUI of the current version states that freeDNS does not require a username, but the script currently requires it.  Can someone with experience with freeDNS comment as to whether or not freeDNS requires a username. 
    
    dyndns.class does not currently check that the server returned a sensible HTTP Status, only that the match string is equal. 
    Also, it would be nice to eventually allow multiple match strings. 
    
    [dyndns.class.txt](/public/_imported_attachments_/1/dyndns.class.txt)
    [services.inc.txt](/public/_imported_attachments_/1/services.inc.txt)
    [services_dyndns.php.txt](/public/_imported_attachments_/1/services_dyndns.php.txt)
    [services_dyndns_edit.php.txt](/public/_imported_attachments_/1/services_dyndns_edit.php.txt)


  • Version 2:
    Much better GUI, and multiple match strings. 
    Patches now go the right direction, so just install the patches with```
    patch /usr/local/www/services_dyndns.php < services_dyndns.php.txt
    patch /usr/local/www/services_dyndns_edit.php < services_dyndns_edit.php.txt
    patch /etc/inc/dyndns.class < dyndns.class.txt
    patch /etc/inc/services.inc < services.inc.txt

    
    Tested to work with tunnelbroker.net on the latest snapshot. 
    
    Notes:
    Currently, the cache file used is {$g['conf_path']}/dyndns_{$dyndns['interface']}{$dyndns['type']}.cache, which will result in a shared cache file for any two DDNS settings on the same provider, this might cause problems for people with multiple Custom Entries. 
    
    The GUI of the current version states that freeDNS does not require a username, but the script currently requires it.  Can someone with experience with freeDNS comment as to whether or not freeDNS requires a username. 
    
    dyndns.class does not currently check that the server returned a sensible HTTP Status, only that the match string is equal. 
    
    [dyndns.class.txt](/public/_imported_attachments_/1/dyndns.class.txt)
    [services.inc.txt](/public/_imported_attachments_/1/services.inc.txt)
    [services_dyndns.php.txt](/public/_imported_attachments_/1/services_dyndns.php.txt)
    [services_dyndns_edit.php.txt](/public/_imported_attachments_/1/services_dyndns_edit.php.txt)

  • Rebel Alliance Developer Netgate

    I haven't had a chance to test this (been a busy day) but it looks promising.

    You could get the ID of the dyndns instance and append that to the name after the dyndns type perhaps, to make it more precise.



  • Version 3:
    Allows for custom script execution on update failure,
    Allows for requests to originate from an interface other than the one monitored (useful to call LAN scripts on update),
    Uses a unique id in cache and debug files.

    Once again patch with```
    patch /usr/local/www/services_dyndns.php < services_dyndns.php.txt
    patch /usr/local/www/services_dyndns_edit.php < services_dyndns_edit.php.txt
    patch /etc/inc/dyndns.class < dyndns.class.txt
    patch /etc/inc/services.inc < services.inc.txt

    
    Issues:
    The GUI of the current version states that freeDNS does not require a username, but the script currently requires it.  Can someone with experience with freeDNS comment as to whether or not freeDNS requires a username. 
    
    dyndns.class does not currently check that the server returned a sensible HTTP Status, only that the match string is equal.
    
    When an entry is deleted, the script rechecks all interfaces and removes all cache files, it should gracefully move all cache files to the appropriate new ID number.
    
    [dyndns.class.txt](/public/_imported_attachments_/1/dyndns.class.txt)
    [services_dyndns.php.txt](/public/_imported_attachments_/1/services_dyndns.php.txt)
    [services.inc.txt](/public/_imported_attachments_/1/services.inc.txt)
    [services_dyndns_edit.php.txt](/public/_imported_attachments_/1/services_dyndns_edit.php.txt)


  • Please clarify the license of this(mostly if they can be committed to the repo).
    I do not agree totally with this patches and will make some modifications of them:



  • Have fun do what you want - I do not claim any copyright to the above patches.



  • Hi!
    While you are modifying the DDNS behavior, is it possible to add OpenVPN as an interface? I am using OpenVPN as a Client, and I am routing all my traffic through a public VPN provider. I am solving the DDNS issue now by using the DynDNS client on a server connected to the LAN, but of course, the ideal thing is to use pfSense for this.

    Thanks!


  • Rebel Alliance Developer Netgate

    Zappca,

    Have you tried assigning your openvpn instance as an OPT interface? (assign it, enable it, select "none" for the IP type)

    It may do what you want then.



  • Unfortunatly it does not. I tried assigning the interface to the ovpnc1 port, but the DNS client was not able to retrieve the IP adress that OpenVPN was connected to. The adress reported back was 0.0.0.0.


  • Rebel Alliance Developer Netgate

    Then it may be covered by the changes I've suggested here: http://redmine.pfsense.org/issues/904

    May not happen for 2.0 though.



  • I've updated the patches to fix a couple bugs I've been seeing on the previous patches.
    1.  Because of the lines```
    if (!empty($int))
    break;

    in services.inc, only one dyndns provider will be updated per interface if services_dyndns_configure is called with an interface (it usually is), this is a bug in pfSense, and is unrelated to my particular patch, but effects all users of multiple dyndns providers on one interface (or should as far as I can tell).  
    
    2\. One of my providers automatically pings my IP Address to make sure it is up before allowing updating (tunnelbroker.net) thus /etc/inc/interfaces.inc had to be changed to allow filter_configure to happen before serivces_dyndns_configure.  I added a sleep(1) to make sure the reload is done.  
    
    All other previous issues still apply.  
    
    Zappza:  I don't use OpenVPN on my installation, so I don't know how pfSense handles the interfaces of it.  If you could send an output of ifconfig -a (or at least the relevant parts) and the list of interfaces according to the webUI, I'll try to add it if I have time.
    
    New Patches are attached and can be applied through```
    patch /usr/local/www/services_dyndns.php < services_dyndns.php.txt
    patch /usr/local/www/services_dyndns_edit.php < services_dyndns_edit.php.txt
    patch /etc/inc/dyndns.class < dyndns.class.txt
    patch /etc/inc/services.inc < services.inc.txt
    patch /etc/inc/interfaces.inc < interfaces.inc.txt
    
    

    Again, I claim no copyright on the above patches, or anything posted previously.

    interfaces.inc.txt
    services.inc.txt
    services_dyndns.php.txt
    services_dyndns_edit.php.txt
    dyndns.class.txt



  • I'm sorry, my last post not fully tested.

    In addition to the modification of interfaces.inc, rc.newwanip had to be updated in order to make sure that the filter is reloaded before dyndns is updated.  (I'm only really assuming that interfaces.inc needs modification, I've only tested the updates through disconnect/connect on the webui, but it is called by several other functions in interfaces, so to be safe I'm going to leave it modified.)
    So with rc.newwanip, use```
    patch /usr/local/www/services_dyndns.php < services_dyndns.php.txt
    patch /usr/local/www/services_dyndns_edit.php < services_dyndns_edit.php.txt
    patch /etc/inc/dyndns.class < dyndns.class.txt
    patch /etc/inc/services.inc < services.inc.txt
    patch /etc/inc/interfaces.inc < interfaces.inc.txt
    patch /etc/rc.newwanip < rc.newwanip.txt

    
    This time I tested the patches against the latest snapshot and they work.
    
    As always, I claim no copyright to any of the above. 
    
    [rc.newwanip.txt](/public/_imported_attachments_/1/rc.newwanip.txt)
    [interfaces.inc.txt](/public/_imported_attachments_/1/interfaces.inc.txt)
    [services.inc.txt](/public/_imported_attachments_/1/services.inc.txt)
    [services_dyndns.php.txt](/public/_imported_attachments_/1/services_dyndns.php.txt)
    [services_dyndns_edit.php.txt](/public/_imported_attachments_/1/services_dyndns_edit.php.txt)
    [dyndns.class.txt](/public/_imported_attachments_/1/dyndns.class.txt)


  • Is there a chance this will make it into 2.0, or is there anything that needs changed before possible inclusion, or has this just fallen under bug fixes get first priority and there is a lot left to do?

    Thanks for the great project.


  • Rebel Alliance Developer Netgate

    If ermal gets a chance to look them over and offer feedback/fixes, they may make 2.0.

    If it doesn't, it should be easy enough to whip up a package to add in the patches, but that couldn't really happen 100% until 2.0 is out since files are moving targets until then.



  • One more bug in the existing code: line 587 in /etc/inc/services.inc should be return, not continue.
    This can cause an error when a DynDNS Service is disabled.



  • @BlueMatt:

    One more bug in the existing code: line 587 in /etc/inc/services.inc should be return, not continue.
    This can cause an error when a DynDNS Service is disabled.

    This bug causes the following error on a page which reconnects an interface:

    Fatal error: Cannot break/continue 1 level in /etc/inc/services.inc on line 587
    


  • Hello!
    Here is a pastebin of ifconfig -a.

    I did get it to report the correct IP when listening to the LAN interface, but it didn't appear to update the entry properly.

    Thanks!

    http://pastebin.com/cnsXXRHg



  • One option I can think of as well is to be able to update http://www.dnsomatic.com/ from pfSense, which will in turn update many other dynamic IP services. Maybe the existing system will work with it, I think they use a similar API to existing providers to make it easy to use them as a drop-in replacement. But I'm not a dynamic DNS API expert, just a suggestion.



  • Its a great idea, and I do use dnsomatic from time to time, however the site (including the list of supported services) hasn't been touched in years, and I needed several other services (including one custom designed one) to be automatically updated.


Log in to reply