Skip to main content

How can we help you?

Search

help Knowledge Base
forum Community
checklist Release Notes
event Events

Unable to update DDNS after IP address change and DNS cache runs out

Jacob Bushnell

Hello, I have a site that has issues with Starlink CGNAT service changing  the public IP on a regular basis. We are using the DUC client for NO-IP.com was unable to update the IP because DNSFilter was blocking it. I think this is because I was using the new option with a unique credentials for each host. and the update URL is: all.ddnskey.com instead of the classic NOIp.com domain.

Could you please update your default filter settings to allow the DDNS queries to ddnskey.com (which is owned by no-ip.com) to go though so the client site can update with the new public IP? In order to get the client back online I have to access the router, then change the DNS to Google's 8.8.8.8 and immediately the DDNS client could update with the correct IP address. ddnskey.com is not blocked in my policy so it can continue to update as long as my IP address does not changed. But that defeats the purpose of having DDNS!

Thank you,
Jacob Bushnell

Comments

2 comments

Date Votes
  • Official comment
    Minetta Gould Community Team DNSFilter Staff

    Thanks again to Jacob for working with us on this one.

    Our engineers were able to review the external IP address provided in the support ticket and identify the FQDN being used by the DDNS client. That domain has now been added to our known list of DDNS providers, which resolves the issue going forward.

    For anyone who runs into a similar situation with DDNS updates being blocked, the fastest way for us to investigate is to open a support ticket and include:

    • The DDNS FQDN being used
    • The external IP address at the time of the issue
    • A timeframe when the update attempt occurred

    With those details, our team can trace the DNS queries internally and quickly identify whether a new DDNS endpoint needs to be recognized.

  • Minetta Gould Community Team DNSFilter Staff

    Thanks for flagging this, Jacob Bushnell—I’m going to open a support ticket on your behalf so we can take a closer look.

    Our engineers reviewed the FQDN you shared and everything appears to be configured correctly on our end. That leads us to suspect there may be another FQDN in play that hasn’t been identified yet.

    To help isolate this, could you share the external IP address you had at the time the issue occurred in the ticket? With that, we can search internally to see which DNS queries arrived from that IP before your DDNS update completed and confirm exactly which FQDN was being used.

    Keep an eye out for the support ticket notification shortly—once we have that IP information, we should be able to narrow this down quickly!

    0

Please sign in to leave a comment.

New post

Featured posts