DynDNS

  • Hi Nuxwin,


    there's an dyndns-service running on my server. Using a secured connection, a zone-update is done by using bind's nsupdate - it's so to say an injection into the zone. Now the thing is that <domainname>.jnl is created after doing such an injection. Critical about this file is that the corresponding zone-file can be changed but the changes won't be propagated unless .jnl exists. So it's necessary to delete .jnl on order to allow propagation. So I'm thinking about on how to design a named listener to address this problem.


    Possible solutions
    1) A named-listener that looks up and stores the ip that was previously injected, deletes .jnl und re-injects the IP finally.


    2) Creating a custom-dns-entry in imscp. Updates won't be propagated through nsupdate anymore - instead I'd change the IP-address of the given entry directly in imscp's database. But for me the question is: what do I havo to call to tell imscp, that the zone needs an update?


    I'd prefer #2 because #1 is pretty dirty.
    But maybe you've got other ideas/hints/whatever.


    Please note this ddns-service is completely custom - it's nothing an user can activate/deactivate in any way.

  • there's an dyndns-service running on my server. Using a secured connection, a zone-update is done by using bind's nsupdate -

    What is the dyndns service that you use exactly? if I understand well, there is a client which receive IP change notification and that make a call to nsupdate(8) to update the IP in the domain zone file, right?


    What client did you use exactly?



    Now the thing is that <domainname>.jnl is created after doing such an injection.

    Normally, the zone for the domain name should pre-exists. You are really talking about dyndns service or you're making attempt to do slave provisionning? Please, clarify a bit because I'm not sure to understand the workflow ;)

    2) Creating a custom-dns-entry in imscp. Updates won't be propagated through nsupdate anymore - instead I'd change the IP-address of the given entry directly in imscp's database. But for me the question is: what do I havo to call to tell imscp, that the zone needs an update?


    I'd prefer #2 because #1 is pretty dirty.
    But maybe you've got other ideas/hints/whatever.


    I would take that road too but things are not so simple ;) When adding or updating a custom DNS record, there are specific events which must be triggered (PHP side). The question here is from which side you want add/update the DNS record? PHP (best choice if you do not want break API), simple perl script (problem with that approach is that events triggered at frontend level won't ;)


    So ?


    Note also that the DynDNS plugin is on the road so, if you have specific specification for implementation, I could integrate them.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • I packed the client/server into a file and attached it. Source: don't know - found anywhere in the web round about a decade ago. It's nothing fancy - just straight forward :-)


    Ok, let me outline this a little bit:
    Guess there's a domain "domain.de" which I want to provide a dyndns-service for. For example dynip.domain.de. Now domain.de was set up in imscp but without telling imscp anything about the subdomain dynip. So the domain/zonefile is under imscp's control.


    On client side, there's a pretty small perl-script running (ddnsclient), that sends messages to the server using sslcat. On server-side, there's stunnel, that calls "dns-server.pl". There's a user file "hosts", that looks a bit like smbpasswd-file - all valid clients/users a listed there with a crypted pwd following. So after checking if the client sent a correct user/password-combination, "dnsupdate.pl" is called. It uses nsupdate to "inject" the client-ip into the zone managed by imscp/named. As I described previously: this injection leads to creation of domain.de.db.jnl. This in turn is so to say critical, because it makes bind ignoring any changes in the zonefile unless jnl exists.


    So everything is perl-based so far. But in the end I don't care if it's perl or php :-)
    I'd really appreciate some further information on what exactly has to be triggered.

    Files

    • ddns.zip

      (3.93 kB, downloaded 7 times, last: )
  • Ok, let me outline this a little bit:
    Guess there's a domain "domain.de" which I want to provide a dyndns-service for. For example dynip.domain.de. Now domain.de was set up in imscp but without telling imscp anything about the subdomain dynip. So the domain/zonefile is under imscp's control.

    Basically, you are using nsupdate(8) to add/remove DNS records dynamically, out of i-MSCP and of course, those DNS records are not known by i-MSCP.

    So after checking if the client sent a correct user/password-combination, "dnsupdate.pl" is called. It uses nsupdate to "inject" the client-ip into the zone managed by imscp/named. As I described previously: this injection leads to creation of domain.de.db.jnl. This in turn is so to say critical, because it makes bind ignoring any changes in the zonefile unless jnl exists.

    The domain.de.db.jnl journal for the domain.de zone should be synced too. You're running Bind9 >= 9.9, right (from xenial) ? If yes, why you don't also call rndc sync --clean domain.de from your dnsupdate.pl, after the nsupdate call? This should flush the journal and put changes back to the domain.de.db zone file.


    Quote from rndc(8)


    sync [-clean] [zone [class [view]]]
    Sync changes in the journal file for a dynamic zone to the master file. If the "-clean" option is specified, the journal file is also removed. If no zone is specified, then all zones are synced.


    However the problem with that approach is that if you add/change a DNS record through i-MSCP or simply update or reconfigure i-MSCP, DNS records which were added dynamically will be lost. So yes, nsupdate(8) here is not really suitable. Best would be to replace call to dnsupdate.pl script by a call to your own script. To resume:


    Client side: Call to ddnsclient (no change here)
    Server side: dns-server: Instead of invoking the dnsupdate.pl script, you should invoke a PHP script which workflow should be as follow:


    Depending on context (DNS record is being added or updated)

    • Trigger the Events::onBeforeAddCustomDNSrecord event with appropriate parameters
    • Add the DNS record into the database
    • Trigger the Events::afterBeforeAddCustomDNSrecord event with appropriate parameters
    • Send a backend request

    OR

    • Trigger the Events::onBeforeEditCustomDNSrecord event with appropriate parameters
    • Update the DNS record into the database
    • Trigger the Events::onAfterEditCustomDNSrecord event with appropriate parameters
    • Send backend request

    If you need help for writting that script, tell me.


    See also: https://github.com/i-MSCP/imsc…/client/dns_edit.php#L771

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206

  • Tested - works really fine.
    Thanks for your support. Nuxwin!

    You're welcome ;)


    Thread closed.

    badge.php?id=1239063037&bid=2518&key=1747635596&format=png&z=547451206