Unable to resolve domain IP but still tries to update records about dness HOT 4 CLOSED

As of right now those warnings are working correctly as I want dness to be resilient against stale configuration. For instance my own config contains a subdomain or two that I've deleted from my DNS records but forgot to update in dness. If these warnings had caused a premature exit then legitimate domains would not be updated.

Can you explain your use case further, as it may be worth introducing a --paranoid flag to exit with an error whenever a missing record is encountered.

from dness.

Huh, it should fail. I tried replicating the issue on a box of mine:

ufw deny out 53

And got the following error:

[ERROR dness] could not successfully resolve IP
        caused by: dns lookup
        caused by: could not resolve via dns
        caused by: proto error: io error: Operation not permitted (os error 1)

Is there something more to it?

from dness.

Hi Nick

I looked back on my journalctl -u dness.service I can see the previous logs which show the error

Jan 05 23:00:57 dness systemd[1]: Starting A dynamic DNS client...
Jan 05 23:01:00 dness dness[7178]: [INFO dness] resolved address to 161.8.226.redacted in 2585ms
Jan 05 23:01:30 dness dness[7178]: [WARN dness::namecheap] resolving namecheap record (@) encountered an error: could not resolve via dns
Jan 05 23:02:00 dness dness[7178]: [WARN dness::namecheap] resolving namecheap record (*) encountered an error: could not resolve via dns
Jan 05 23:02:30 dness dness[7178]: [WARN dness::namecheap] resolving namecheap record (www) encountered an error: could not resolve via dns
Jan 05 23:02:30 dness dness[7178]: [INFO dness] processed redacted.com (namecheap): (updated: 0, already current: 0, missing: 3) in 90025ms
Jan 05 23:02:30 dness dness[7178]: [INFO dness] processed all: (updated: 0, already current: 0, missing: 3) in 92617ms
Jan 05 23:02:30 dness systemd[1]: dness.service: Succeeded.
Jan 05 23:02:30 dness systemd[1]: Finished A dynamic DNS client.

Maybe it's not the blocked port that caused it, but as you can see it still proceeded with an error. Hope this log helps

from dness.

In that case it isn't a bug so closing this ticket 🙂 thank you for following up

Not in my use case, I encounted this by accident and it's no longer an issue for me

from dness.