If that happens the IP address is usually from the RFC1918 range and in that case an external server is asked for the public IP address.

If you configure it that way, this is in my opinion not wrong to happen. Asking DNS is okay. If you manipulate the DNS response on the way, how should that be detected? I think asking random public name servers is not an option.

- of course the IP address is in the RFC1918 range
- i think this is a quite common setup that the DNS resolves to a local address internally, but to the external address when resolving it externally. it is not really manipulating DNS
- i was not talking about querying random public DNS servers but the one specified for red if the internal lookup is in the RFC1918 range. this does in my opinion not happen when ddns checks if the ip for the host is valid.

here is the corresponding code block (/var/ipfire/general-functions.pl)

where does this function ask an external server if gethostbyname returns an IP address from the RFC1918 range?

sub DyndnsServiceSync ($;$;$) {

    my ($ip,$hostName,$domain) = @_;
    my @addresses;

    #fix me no ip GROUP, what is the name ?
    $hostName =~ s/$General::noipprefix//;
    if ($hostName) { #may be empty
        $hostName = "$hostName.$domain";
        @addresses = gethostbyname($hostName);
    }

    if ($addresses[0] eq '') {                  # nothing returned ?
        $hostName = $domain;                    # try resolving with domain only
        @addresses = gethostbyname($hostName);
    }

    if ($addresses[0] ne '') {                  # got something ?
        #&General::log("name:$addresses[0], alias:$addresses[1]");                          
        # Build clear text list of IP
        @addresses = map ( &Socket::inet_ntoa($_), @addresses[4..$#addresses]);
        if (grep (/$ip/, @addresses)) {
            return 1;
        }
    }
    return 0;
}

That is actually right here: http://git.ipfire.org/?p=ddns.git;a=blob;f=src/ddns/system.py;h=0d90ce66ee38e6d604420449aa2cfabdecb7ffc8;hb=HEAD#l272

The perl code is not used to perform the actual update. It is just used to show the entries in the table green or red, depending on the IP and hostname matching or not.

(In reply to hadfl from comment #2)
> - i was not talking about querying random public DNS servers but the one
> specified for red if the internal lookup is in the RFC1918 range. this does
> in my opinion not happen when ddns checks if the ip for the host is valid.

That would overwrite many settings including the "DNS Forwarding" which can lead to other unwanted problems.

ok so the problem is here:

http://git.ipfire.org/?p=ddns.git;a=blob;f=src/ddns/providers.py#l266

ip_address_changed will always return true if the host resolves to an RFC1918 IP locally since addresses will contain the local IP and current_address the external IP...

just to make it clear. ddns works perfectly the issue is that it will be updated every run although the IP didn't change.

what about storing the last IP in the database instead of resolving it and checking against that?

(In reply to hadfl from comment #6)
> just to make it clear. ddns works perfectly the issue is that it will be
> updated every run although the IP didn't change.

Why is that?

> what about storing the last IP in the database instead of resolving it and
> checking against that?

The idea here is to detect if something else changed the IP address. Local storage would just not work for that.

> Why is that?

thats what i am trying to explain in Comment #6

current_address will contain the "guessed" external ip address if it resolves to a local address (get_address method)

whereas addresses will only contain the local address (self.core.system.resolve method)

this causes ddns to update every run (i.e. 5 minutes) because addresses does not contain current_address

ip_address_changed(self, protos) should be fixed in a way similar to what get_address does, so that addresses will contain the external ip address, too.

I am going to close this. Although this is a valid bug, there isn't an easy fix in perl here and since only an incorrect colour is being shown, this should not harm anyone.