Make changes stick?

[linuxfrag]

These scripts work great but changes do not stick. Even without a reboot sometime( maybe an hour or hours later) the UDM Pro revmoes all these entries back to default. I can verify the changes work before this happens since I'm using NextDNS and seeing these new host entries take effect.

Anyway to make these settings stick?

[evaneaston]

This is similar to #4. Evidently, there are a lot of scenarios where the udm removes entries. I've been running a separate DNS server and so I haven't yet tried to chase down (a) what events trigger the removals (b) a great way to ensure they persist. I've also had others report the same problem on social media.

Sooo.... I'm sensing I'll take another look this week at trying a new iteration.

[evaneaston]

@linuxfrag FYI, after some experimentation, it seems that a bunch of actions unrelated to DNS result in the dnsForwarder hostRecords being rebuilt to only include setup.ui.com, unifi.<domainname> for each network domain name and .` for each non guest network domain name. This behavior is consistent with the developers setting/overwriting these hosts instead of merging with any other custom entries.

The only think I can see doing is to build a local db/file containing custom entries, monitor for changes to /var/run/dnsmasq.conf.d/dns.conf or /config/ubios-udapi-server/ubios-udapi-server.state and reregister the custom entries when they disappear. I'm looking into how to do this now.

[Syam]

Hello there,

2 feedbacks :

• Got the same issue : Entries were removed after a while (Did not play with threat management settings)
• Later, i updated UDM firmware, and entries were gone on reboot.

[pgeremia]

I wanted to check if there is any update on this. The script works great, I just have to apply it every time there is a change, upgrade, reboot etc.. I submitted a feature request with them, but dont expect them to act on that. Any idea how to automate the process?

[frenchc]

While I don't like my solution I fixed this problem using boot scripts. First I created a script that adds all DNS entries at boot time. which is quite easy to do using https://github.com/boostchicken-dev/udm-utilities/tree/master/on-boot-script. Additionally I added another script that adds a cron job at boot time that checks every minute if my DNS entries are still available, and if not, adds them again.

The solutions works during configuration changes, and should also work for updates. Did not have the chance to test that yet, but should work.

[msavazzi]

While I don't like my solution I fixed this problem using boot scripts. First I created a script that adds all DNS entries at boot time. which is quite easy to do using https://github.com/boostchicken-dev/udm-utilities/tree/master/on-boot-script. Additionally I added another script that adds a cron job at boot time that checks every minute if my DNS entries are still available, and if not, adds them again.

The solutions works during configuration changes, and should also work for updates. Did not have the chance to test that yet, but should work.

Can you be so kind to share those scripts? it would be a great workaround

[frenchc]

Since it's just a quick hack yet no full scripts here.

The "workaround":

A. Add all hosts at startup using on-boot-script ( https://github.com/boostchicken-dev/udm-utilities/tree/master/on-boot-script) B. Create a cron entry that checks if all hosts / one host are still there, and if not, add them again. The cron entry has to be recreated during every startup to make it 'static'. We simply add our hosts once they get lost during config change.

What I did (all files/scriptes are owned by root):

1. Installed your scripts in /mnt/data/udm-host-records
2. Installed on-boot-script from https://github.com/boostchicken-dev/udm-utilities/tree/master/on-boot-script
3. Created an executable script in /mnt/data/udm-host-records (e.g. add-static-hosts.sh) that adds all my host records for A & B. Simplified version:

#!/bin/sh 

/mnt/data/udm-host-records/add-host-record.sh host-a ip-address-a 
/mnt/data/udm-host-records/add-host-record.sh host-b ip-address-b
...

4. Created an executable startup script in /mnt/data/on_boot.d for A (e.g. 10-add-static-hosts.sh) that executes the script from 3. We now have our hosts after startup.

#!/bin/sh

/mnt/data/udm-host-records-/add-static-hosts.sh

5. Created an executable script in /mnt/data/udm-host-records that checks if one or all hosts are still there, and if not execute the script from 3 (e.g. add-static-hosts-if-needed.sh). Replace YOURHOSTNAME, redirect output to some other location if needed.

#!/bin/sh

if [ `/mnt/data/udm-host-records/list-host-records.sh | grep YOURHOSTNAME | wc -l`  -eq 0 ]
then
 /mnt/data/udm-host-records/add-static-hosts.sh > /dev/null
fi

6. Created a cron config file for a cron job that executes as often as needed for B in /mnt/data/udm-host-records (e.g. host_check) with 0644 permissions. This one is executed every minute.

* * * * * /mnt/data/udm-host-records/add-static-hosts-if-needed.sh

7. Created an executable startup script in /mnt/data/on_boot.d for B (e.g. 11-enable-cron-host-check.sh) that copies the cron config and ensures cron is using it .

#!/bin/sh

cp -f /mnt/data/udm-host-records/host_check /etc/cron.d/host_check
# optionally chmod 0644 /etc/cron.d/host_check
/etc/init.d/crond restart

8. Reboot

[simma101]

@frenchc solution also works fine if you just run '/mnt/data/udm-host-records-/add-static-hosts.sh' in your cron job and skip the check if hosts are still listed step. Feels about the same level of brute force.

[frenchc]

That works, too;). Unifi internals are still a black box to me, so my workaround is as less invasive as possible (based on my limited knowledge).

[evaneaston]

I don't have an answer, but because the criteria for updating hostRecords isn't clear, this repo can't offer to solve the DNS via UDM problem. I'm deprecating the repo.