Dyndns update: immediately vs. interval

General questions
1

Dear vyos-experts,

the current 1.5 manual states “VyOS is able to update a remote DNS record when an interface gets a new IP address.”.

Thus I thought the dyndns update gets triggered when the interface ip changes or the interface comes up [again]. During a short test using disconnect interface pppoe0 followed by connect interface pppoe0 it seemed the dyndns update isn’t triggered immediately. Instead I had to wait until ddclient’s update interval triggered the update. (DNS internal update/propagation delay is nearly zero, some seconds after ddclient reports success, nslookup reports the new value, too).

Is this the intended behavior?

Thanks a lot!
Best regards,
vyozzy

2

I’m not going to be able to help, because I don’t use Dynamic DNS nor pppoe anymore, but to get the interest of someone who might be able to help it would really pay to include the actual dynamic dns config you’re using, and the build of Vyos.

show version
show configuration commands | strip-private  | match dynamic
3

You will have to dig some in this forum but I recall that this was changed to not get your dyndns account banned due to “too many updates” which can occur if you reboot your device a few times in a short period of time and such.

4

The version is 1.5-nightly, exactly:

Version:          VyOS 1.5-rolling-202409200006
Release train:    current
Release flavor:   generic

Built by:         autobuild@vyos.net
Built on:         Fri 20 Sep 2024 00:06 UTC
Build UUID:       a283ca9b-472e-4f4e-b9ad-cb48658a3bf0
Build commit ID:  8274a418944c4c

Architecture:     x86_64
Boot via:         installed image
System type:      KVM guest
Secure Boot:      n/a (BIOS)

Hardware vendor:  QEMU
Hardware model:   Standard PC (Q35 + ICH9, 2009)
Hardware S/N:
Hardware UUID:    xxx

Copyright:        VyOS maintainers and contributors

Although I don’t think the configuration matters here (as I said the update works, but not immediately), these are the ddclient related settings:

set service dns dynamic name up-v4 address interface 'pppoe0'
set service dns dynamic name up-v4 description 'up.domain.tld (IPv4)'
set service dns dynamic name up-v4 host-name xxxxxx
set service dns dynamic name up-v4 ip-version 'ipv4'
set service dns dynamic name up-v4 password xxxxxx
set service dns dynamic name up-v4 protocol 'dyndns2'
set service dns dynamic name up-v4 server 'dyndns.domain.tld'
set service dns dynamic name up-v4 username xxxxxx
5

@Apachez
Yes, flapping lines/links can result in a ban, but as these bans are always temporary they don’t harm:

  1. Periods of flapping lines/links are a seldom phenomena (can’t remember when this was the case over here). And if the line/link begins to flap …
  2. … during flapping periods, the uplink isn’t reachable reliably, therefore a dyndns ban doesn’t matter, as long as it gets unbanned after a short period of time, e.g. within 30 to 60 minutes, which is the case, at least here.

Thus I don’t think dyndns-update-bans should be prevented at the cost of delayed updates.

6

But how much is it delayed?

I think having a delay of a few seconds is a sane option to avoid having your entry banned and not pointing correctly for the next 60 minutes or so.

Also did you verified that the delay is caused by VyOS itself (like through a tcpdump on the WAN interface)?

Im thinking in case the dyndns themselves have added a delay?

7

Looking at vyos-1x/src/conf_mode/service_dns_dynamic.py at circinus · vyos/vyos-1x · GitHub and vyos-1x/data/templates/dns-dynamic/ddclient.conf.j2 at circinus · vyos/vyos-1x · GitHub there seems to be a min_interval=config.wait_time which I would expect is some kind of “delay”.

Digging further into the docs I find this:

https://docs.vyos.io/en/latest/configuration/service/dns.html#dynamic-dns

set service dns dynamic interval <60-3600>

Specify interval in seconds to wait between Dynamic DNS updates. The default is 300 seconds.
8

I know the interval setting. The interval was not the question. The question was regarding the documentation (see first post), which, at least in my eyes, implies that the update takes place immediately (which I was used to using *sense). If it would take place immediately, I would set the update interval to 30 or even 60 minutes - from my experiences with *sense there’s no need to run ddclient every minute.

A minute seems a relatively short period in time but: when you think in bytes that pass a [multi]-gigabit link even a second seems [too] much. :wink:

9

Since the default and lowest interval is 60 seconds I would assume that this would be the case you see where the ddclient dont update “immediately” but “after a while”.

However please try to capture that using tcpdump to find out if its the VyOS who delays the update of if its the dyndns service who doesnt accept it straight away?

10

As I also said before, there is no dns update/propagation delay:

Oct  5 10:00:31 rc1 pppd[75248]: local  IP address 54.x.y.z
Oct  5 10:00:31 rc1 pppd[75248]: remote IP address 12.x.y.z
Oct  5 10:00:31 rc1 pppd[75248]: primary   DNS address 21.x.y.z
Oct  5 10:00:31 rc1 pppd[75248]: secondary DNS address 21.x.z.y

When the IP changes, vyos doesn’t trigger an immediate dyndns-update. Instead ddclient just waits for the interval (currently setup to 300s) to pass:

Oct 05 10:01:45 rc1 ddclient[75690]: SUCCESS:  updating ddns.example.com: good: IPv4 address set to 54.x.y.z

The actual dns update succeeds within less than a second:

10:01:45.567195 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [S], seq 3687997315, win 65136, options [mss 1416,sackOK,TS val 2613082294 ecr 0,nop,wscale 7], length 0
10:01:45.595709 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [S.], seq 1702844058, ack 3687997316, win 14160, options [mss 1440,nop,wscale 0,sackOK,TS val 1545652832 ecr 2613082294], length 0
10:01:45.595774 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [.], ack 1, win 509, options [nop,nop,TS val 2613082323 ecr 1545652832], length 0
10:01:45.597002 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [P.], seq 1:518, ack 1, win 509, options [nop,nop,TS val 2613082324 ecr 1545652832], length 517
10:01:45.625420 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [.], ack 518, win 14677, options [nop,nop,TS val 1545652862 ecr 2613082324], length 0
10:01:45.635744 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [P.], seq 2809:3884, ack 518, win 14677, options [nop,nop,TS val 1545652868 ecr 2613082324], length 1075
10:01:45.635796 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [.], ack 1, win 509, options [nop,nop,TS val 2613082363 ecr 1545652862,nop,nop,sack 1 {2809:3884}], length 0
10:01:45.651184 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [.], seq 1:1401, ack 518, win 14677, options [nop,nop,TS val 1545652888 ecr 2613082324], length 1400
10:01:45.651245 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [.], ack 1401, win 499, options [nop,nop,TS val 2613082378 ecr 1545652888,nop,nop,sack 1 {2809:3884}], length 0
10:01:45.651184 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [.], seq 1401:2801, ack 518, win 14677, options [nop,nop,TS val 1545652888 ecr 2613082324], length 1400
10:01:45.651262 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [.], ack 2801, win 489, options [nop,nop,TS val 2613082378 ecr 1545652888,nop,nop,sack 1 {2809:3884}], length 0
10:01:45.651382 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [P.], seq 2801:3884, ack 518, win 14677, options [nop,nop,TS val 1545652888 ecr 2613082324], length 1083
10:01:45.651402 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [.], ack 3884, win 486, options [nop,nop,TS val 2613082378 ecr 1545652888,nop,nop,sack 1 {2809:3884}], length 0
10:01:45.652141 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [P.], seq 518:598, ack 3884, win 502, options [nop,nop,TS val 2613082379 ecr 1545652888], length 80
10:01:45.652206 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [P.], seq 598:859, ack 3884, win 502, options [nop,nop,TS val 2613082379 ecr 1545652888], length 261
10:01:45.680364 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [.], ack 859, win 15018, options [nop,nop,TS val 1545652917 ecr 2613082379], length 0
10:01:45.736250 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [P.], seq 3884:4145, ack 859, win 15018, options [nop,nop,TS val 1545652973 ecr 2613082379], length 261
10:01:45.736539 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [P.], seq 859:883, ack 4145, win 502, options [nop,nop,TS val 2613082463 ecr 1545652973], length 24
10:01:45.736932 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [F.], seq 883, ack 4145, win 502, options [nop,nop,TS val 2613082464 ecr 1545652973], length 0
10:01:45.764210 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [.], ack 883, win 15042, options [nop,nop,TS val 1545653001 ecr 2613082463], length 0
10:01:45.764210 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [F.], seq 4145, ack 883, win 15042, options [nop,nop,TS val 1545653001 ecr 2613082463], length 0
10:01:45.764231 IP6 2001:____:____:9a5::2.57154 > 2a01:____:____:202::51a9:90c0.443: Flags [.], ack 4146, win 502, options [nop,nop,TS val 2613082491 ecr 1545653001], length 0
10:01:45.764883 IP6 2a01:____:____:202::51a9:90c0.443 > 2001:____:____:9a5::2.57154: Flags [.], ack 884, win 15042, options [nop,nop,TS val 1545653002 ecr 2613082464], length 0
11

Why update each 300s ? I hope there is some logic to detect if WAN IP was altered, that’s the only condition that requires an update .
To minimize updates, you could even do DNS lookup first, to verify if current WAN-IP matches resolved hostname

12

I hoped so too. But vyos seems to rely on ddclient’s update interval only. :frowning:

BTW: Of course there is no update taking place every interval n seconds. In fact ddclient checks every n seconds whether the IP-address has changed. And only when the IP has changed ddclient sends an update request to the dns server. The problem is that the update isn’t triggered immediately after the IP address has changed, which leads to in my eyes unnecessary delays as the minimum ddclient update interval is 60 seconds. In my opinion the update interval should only be some kind of a safety net feature in case the triggered update has failed. I would set the interval to at least 30 minutes, because my ISP and my dyndns providers are very reliable.

13

Feel free to contribute and create a pull request

14

If your box is behind NAT comparing the current DNS-record with what you see on the interface will probably not help.

Some of the Dyndns services can update the record based on the srcip of the request.