inconsistent ddns behaviour

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

inconsistent ddns behaviour

Rick Dicaire
Hi folks, ISC dhcpd 4.3.4, named 9.11.0-P3.
I have a ddns configuration that works fine.
Then I added a new subnet declaration (192.168.18.0) to the conf file, and this subnet conf sent ddns updates as well though I didn't define dns zones to update.

Is this expected behaviour?

Here's full dhcpd.conf

# dhcpd.conf
#
# Configuration file for ISC dhcpd (see 'man dhcpd.conf')
#
log-facility local6;
ddns-update-style interim;
ddns-ttl 1800;

ddns-hostname = pick (option fqdn.hostname, option host-name, concat ("ddns-", binary-to-ascii (10, 8, "-", leased-address)));

option host-name = config-option server.ddns-hostname;

include "/var/named/etc/Kgw-ddns.+157+20451.private";

shared-network DA {

subnet 192.168.15.0 netmask 255.255.255.0 {}

subnet 192.168.17.0 netmask 255.255.255.0 {
  interface eth1;
  authoritative;
  deny bootp;
  pool {
        range 192.168.17.100 192.168.17.200;
        option broadcast-address 192.168.17.255;
        default-lease-time 86400;
        option domain-name "dhcp.ldev";
        option domain-search "dhcp.ldev","ldev";
        option domain-name-servers 192.168.15.1,192.168.15.13;
        option ntp-servers 192.168.15.1;
        option routers 192.168.17.1;
                ddns-domainname "dhcp.ldev.";
                ddns-rev-domainname "in-addr.arpa.";
        allow unknown-clients;
        zone 17.168.192.in-addr.arpa {
          primary dns1.ldev;
                  key gw-ddns;
        }

        zone dhcp.ldev {
          primary dns1.ldev;
                  key gw-ddns;
        }
       }
    } 
}

subnet 192.168.18.0 netmask 255.255.255.0 {
  interface wlan0;
  authoritative;
  deny bootp;
  pool {
        range 192.168.18.100 192.168.18.200;
        option broadcast-address 192.168.18.255;
        default-lease-time 86400;
        option domain-name "dhcp.ldev";
        option domain-search "dhcp.ldev","ldev";
        option domain-name-servers 192.168.15.1,192.168.15.13;
        option ntp-servers 192.168.15.1;
        option routers 192.168.18.1;
        allow unknown-clients;
        }
}

From syslog:

March 26th 2017, 14:33:39.000 Mar 26 14:33:39 dns1 dhcpd: DHCPOFFER on 192.168.18.100 to f0:db:f8:46:50:2e (Richards-iPad) via wlan0
March 26th 2017, 14:33:40.000 Mar 26 14:33:40 dns1 dhcpd: DHCPREQUEST for 192.168.18.100 (192.168.18.1) from f0:db:f8:46:50:2e (Richards-iPad) via wlan0
March 26th 2017, 14:33:40.000 Mar 26 14:33:40 dns1 dhcpd: DHCPACK on 192.168.18.100 to f0:db:f8:46:50:2e (Richards-iPad) via wlan0
Mar 26 14:33:40 dns1 named[1423]: client @0x7f56c816a8e0 192.168.15.1#43225/key gw-ddns: signer "gw-ddns" approved
Mar 26 14:33:40 dns1 named[1423]: client @0x7f56c816a8e0 192.168.15.1#43225/key gw-ddns: updating zone 'dhcp.ldev/IN': adding an RR at 'Richards-iPad.dhcp.ldev' A 192.168.18.100
Mar 26 14:33:40 dns1 named[1423]: client @0x7f56c816a8e0 192.168.15.1#43225/key gw-ddns: updating zone 'dhcp.ldev/IN': adding an RR at 'Richards-iPad.dhcp.ldev' TXT "311db3af593e1db80ce9679a0248b51c64"
Mar 26 14:33:40 dns1 dhcpd: Added new forward map from Richards-iPad.dhcp.ldev to 192.168.18.100


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent ddns behaviour

Simon Hobson
Rick Dicaire <[hidden email]> wrote:

> Hi folks, ISC dhcpd 4.3.4, named 9.11.0-P3.
> I have a ddns configuration that works fine.
> Then I added a new subnet declaration (192.168.18.0) to the conf file, and this subnet conf sent ddns updates as well though I didn't define dns zones to update.
>
> Is this expected behaviour?

Yes.
The default is to lookup the SOA record for the appropriate zones to find the master DNS server, and send updates (unsigned) to that. Thus with a correctly configured DNS, updates will be generated automagically without any admin intervention.
However, using unsigned updates is considered insecure - and so you should be specifying DNS zones - not to indicate the master DNS, but to specify the signing key.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent ddns behaviour

Rick Dicaire
There is no zone directive in the subnet declaration. Why are ddns updates being sent for that subnet?

On Sun, Mar 26, 2017 at 5:59 PM, Simon Hobson <[hidden email]> wrote:
Rick Dicaire <[hidden email]> wrote:

> Hi folks, ISC dhcpd 4.3.4, named 9.11.0-P3.
> I have a ddns configuration that works fine.
> Then I added a new subnet declaration (192.168.18.0) to the conf file, and this subnet conf sent ddns updates as well though I didn't define dns zones to update.
>
> Is this expected behaviour?

Yes.
The default is to lookup the SOA record for the appropriate zones to find the master DNS server, and send updates (unsigned) to that. Thus with a correctly configured DNS, updates will be generated automagically without any admin intervention.
However, using unsigned updates is considered insecure - and so you should be specifying DNS zones - not to indicate the master DNS, but to specify the signing key.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users



--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent ddns behaviour

Simon Hobson
Rick Dicaire <[hidden email]> wrote:

> There is no zone directive in the subnet declaration. Why are ddns updates being sent for that subnet?

Did you read what I wrote - a zone declaration is NOT required other than to specify the key to be used :

> > Is this expected behaviour?
>
> Yes.
> The default is to lookup the SOA record for the appropriate zones to find the master DNS server, and send updates (unsigned) to that. Thus with a correctly configured DNS, updates will be generated automagically without any admin intervention.
> However, using unsigned updates is considered insecure - and so you should be specifying DNS zones - not to indicate the master DNS, but to specify the signing key.

If you want no DDNS updates then you have to specify that you don't want them, with (IIRC) a ddns-update-<something> declaration (either globally or in a particular subnet).

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent ddns behaviour

glenn.satchell
ddns-update-style none; turns ddns updates off globally, probably not what
you want. ddns-update-style is a global setting, so you can't do different
styles for different hosts or subnets.

You can add ddns-updates off; in a subnet to disable ddns for that subnet.

See dhcpd.conf man page for details.

regards,
-glenn

On Mon, March 27, 2017 5:56 pm, Simon Hobson wrote:

> Rick Dicaire <[hidden email]> wrote:
>
>> There is no zone directive in the subnet declaration. Why are ddns
>> updates being sent for that subnet?
>
> Did you read what I wrote - a zone declaration is NOT required other than
> to specify the key to be used :
>
>> > Is this expected behaviour?
>>
>> Yes.
>> The default is to lookup the SOA record for the appropriate zones to
>> find the master DNS server, and send updates (unsigned) to that. Thus
>> with a correctly configured DNS, updates will be generated automagically
>> without any admin intervention.
>> However, using unsigned updates is considered insecure - and so you
>> should be specifying DNS zones - not to indicate the master DNS, but to
>> specify the signing key.
>
> If you want no DDNS updates then you have to specify that you don't want
> them, with (IIRC) a ddns-update-<something> declaration (either globally
> or in a particular subnet).
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent ddns behaviour

Rick Dicaire
Removing option domain-name "dhcp.ldev"; from the subnet declaration stopped ddns updates for this subnet.

Are directives in each subnet declaration global in effect, or particular only to the subnet declaration? My expectation was they'd only apply to that subnet declaration, so I'm unclear.

Thanks for your responses.

On Mon, Mar 27, 2017 at 3:04 AM, Glenn Satchell <[hidden email]> wrote:
ddns-update-style none; turns ddns updates off globally, probably not what
you want. ddns-update-style is a global setting, so you can't do different
styles for different hosts or subnets.

You can add ddns-updates off; in a subnet to disable ddns for that subnet.

See dhcpd.conf man page for details.

regards,
-glenn

On Mon, March 27, 2017 5:56 pm, Simon Hobson wrote:
> Rick Dicaire <[hidden email]> wrote:
>
>> There is no zone directive in the subnet declaration. Why are ddns
>> updates being sent for that subnet?
>
> Did you read what I wrote - a zone declaration is NOT required other than
> to specify the key to be used :
>
>> > Is this expected behaviour?
>>
>> Yes.
>> The default is to lookup the SOA record for the appropriate zones to
>> find the master DNS server, and send updates (unsigned) to that. Thus
>> with a correctly configured DNS, updates will be generated automagically
>> without any admin intervention.
>> However, using unsigned updates is considered insecure - and so you
>> should be specifying DNS zones - not to indicate the master DNS, but to
>> specify the signing key.
>
> If you want no DDNS updates then you have to specify that you don't want
> them, with (IIRC) a ddns-update-<something> declaration (either globally
> or in a particular subnet).
>
> _______________________________________________
> dhcp-users mailing list
> [hidden email]
> https://lists.isc.org/mailman/listinfo/dhcp-users
>


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users



--

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent ddns behaviour

Simon Hobson
Rick Dicaire <[hidden email]> wrote:

> Are directives in each subnet declaration global in effect, or particular only to the subnet declaration? My expectation was they'd only apply to that subnet declaration, so I'm unclear.

In general they are local in scope - so you have global options, over-ridden by shared-subnet options, overridden by subnet options (there are also scopes for group and class but I'll leave them out for now).

BUT - some statements are global in scope wherever they are defined. Class and host declarations are in this list - but because of inheritance, you can get some really strange effects where (for example) you can have a class or host statement that matches a client, causing a client to inherit options from the subnet where the class or host is defined, even though the host is in another subnet altogether !
Hence you may have seen in the archives advice to never define hosts or classes anywhere but in the global scope.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: inconsistent ddns behaviour

Philippe Clérié
In reply to this post by Simon Hobson
On 03/26/2017 05:59 PM, Simon Hobson wrote:
>  - and so you should be specifying DNS zones - not to indicate the master DNS, but to specify the signing key.

Holy cows! I've read a fair number of tutorials on setting up ddns and
that was _never_ mentioned.

Thanks for that bit.

:-D

--
Philippe

------
The trouble with common sense it that it is so uncommon.
<Anonymous>
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users