[Kea-users] Kea DDNS issues

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

[Kea-users] Kea DDNS issues

Ben Monroe
Hi. I am trying to Dockerize DNS, Kea DHCP, Kea DDNS servers. Everything is working except Kea DDNS.
Let me first describe the network. It has three VLANs:
VLAN 10: 10.10.10.0 /24
VLAN 20: 10.10.10.0 /24
VLAN 40: 10.10.40.0 /24
The Docker server is 10.10.40.50 and is on VLAN 40. DHCP relay is enabled on the Cisco router.

Now for the docker containers.
Bind server #1:
-LAN static: 10.10.40.200
-Container static IP: 172.16.100.1
-53/UDP is mapped
Bind server #2:
-LAN static: 10.10.40.201
-Container static IP: 172.16.100.2
-53/UDP is mapped
Kea DHCP (DHCP4):
-LAN static IP: 10.10.40.203
-Container static IP: 172.16.100.3
-67/UDP is mapped
Kea DDNS:
-LAN static IP: <none since it only needs to be accessed from the container network>
-Container static IP: 172.16.100.4
-No ports are mapped since only access required is from within the container network.

Note that all four containers are running on the same container network: 172.16.100.0 /24, with 172.16.100.254 gateway.
Also, DHCP relay is running on the router between VLANs to Kea DHCP (10.10.40.203).
VLAN 40 (where Kea and other containers are locked) is for servers with static IPs and does not need DHCP services, so it is not a problem that L2 broadcasts are not received.
(Additional information: I originally tried running only the Kea container using network_mode host to ensure it received L2 broadcasts, but this will remove it from the DNS container network, potentially harming DDNS updates. Also, with DHCP relay it does not seem to be necessary.)

In Bind named.conf, I have the following:

acl localnet {
10.10.0.0/16;
172.16.100.0/24;
};

acl dns-slaves {
    172.16.100.2; // ns2
};

key "rndc-key" {
        algorithm hmac-sha256;
        secret "<secret>";
};

options {
    directory "/var/bind";
    pid-file "/var/run/named/named.pid";

    forwarders { 8.8.8.8; 8.8.4.4; };

    listen-on { any; };
    listen-on-v6 { none; };

    allow-query { localnet; };
    allow-query-cache { localnet; };
    allow-recursion { localnet; };

    // Allow transfers only to DNS slaves.
    allow-transfer { dns-slaves; };

    notify yes;

    version none;
    hostname none;
    server-id none;
};

zone "dono.local" IN {
    type master;
    file "/etc/bind/db.dono.local";
    allow-update { key rndc-key; };
};

zone "10.10.10.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.10.10.10";
    allow-update { key rndc-key; };
};

zone "20.10.10.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.20.10.10";
    allow-update { key rndc-key; };
};

zone "40.10.10.in-addr.arpa" IN {
    type master;
    file "/etc/bind/db.40.10.10";
    allow-update { key rndc-key; };
};

logging {
    channel stdout {
      stderr;
      severity info;
      print-category no;
      print-severity no;
      print-time yes;
    };

    category security { stdout; };
    category queries  { stdout; };
    category dnssec   { stdout; };
    category xfer-in  { stdout; };
    category xfer-out { stdout; };
    category default  { stdout; };
};

In kea-dhcp4.conf I have:

{
"Dhcp4": {
    "interfaces-config": {
        "interfaces": [ "eth0" ]
    },
    "control-socket": {
        "socket-type": "unix",
        "socket-name": "/tmp/kea-dhcp4-ctrl.sock"
    },
    "lease-database": {
        "type": "memfile",
        "lfc-interval": 3600
    },
    "expired-leases-processing": {
        "reclaim-timer-wait-time": 10,
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "unwarned-reclaim-cycles": 5
    },
    "renew-timer": 900,
    "rebind-timer": 1800,
    "valid-lifetime": 3600,
    "dhcp-ddns": {
      "enable-updates": true,
      "qualifying-suffix": "dono.local.",
      "server-ip": "172.16.100.4"
    },
    "option-data": [
        {
            "name": "domain-name-servers",
            "data": "10.10.40.200, 10.10.40.201"
        },
        {
            "name": "domain-name",
            "data": "dono.local"
        },
        {
            "name": "domain-search",
            "data": "dono.local"
        },
        {
            "name": "time-servers",
            "data": "10.10.40.10"
        }
    ],
    "subnet4": [
        {
            "subnet": "10.10.10.0/24",
            "pools": [ { "pool": "10.10.10.50 - 10.10.10.150" } ],
            "option-data": [
                {
                    "name": "routers",
                    "data": "10.10.10.254"
                }
            ]
        },
{
"subnet": "10.10.20.0/24",
"pools": [ { "pool": "10.10.20.50 - 10.10.20.150" } ],
"option-data": [
{
"name": "routers",
"data": "10.10.20.254"
}
]
}
    ],
    "loggers": [
        {
          "name": "kea-dhcp4",
          "output_options": [
              {
                  "output": "/etc/kea/kea-dhcp4.log",
                  "flush": true,
                  "maxsize": 1048576,
                  "maxver": 3
              }
          ],
          "severity": "DEBUG",
          "debuglevel": 99
        },
        {
          "name": "kea-dhcp-ddns",
          "output_options": [
              {
                  "output": "/etc/kea/kea-ddns.log",
                  "flush": true,
                  "maxsize": 1048576,
                  "maxver": 3
              }
          ],
          "severity": "DEBUG",
          "debuglevel": 99
        }
    ]
}
}

And in kea-dhcp-ddns.conf I have:
{
"DhcpDdns":
{
  "ip-address": "127.0.0.1",
  "port": 53001,
  "control-socket": {
      "socket-type": "unix",
      "socket-name": "/tmp/kea-dhcp-ddns-ctrl.sock"
  },
  "tsig-keys": [
    {
      "name": "rndc-key",
      "algorithm": "hmac-sha256",
      "secret": "<secret>"
    }
  ],
  "forward-ddns": {
    "ddns-domains": [
      {
        "name": "dono.local.",
        "key-name": "rndc-key",
        "dns-servers": [
          { "ip-address": "172.16.100.1" },
          { "ip-address": "172.16.100.2" }
        ]
      }
    ]
  },
  "reverse-ddns": {
    "ddns-domains": [
      {
        "name": "10.10.10.in-addr.arpa.",
        "key-name": "rndc-key",
        "dns-servers": [
          { "ip-address": "172.16.100.1" },
          { "ip-address": "172.16.100.2" }
        ]
      },
      {
        "name": "20.10.10.in-addr.arpa.",
        "key-name": "rndc-key",
        "dns-servers": [
          { "ip-address": "172.16.100.1" },
          { "ip-address": "172.16.100.2" }
        ]
      }
    ]
  },
  "loggers": [
    {
        "name": "kea-dhcp-ddns",
        "output_options": [
            {
                "output": "/etc/kea/kea-ddns.log",
                "flush": true,
                "maxsize": 1048576,
                "maxver": 3
            }
        ],
        "severity": "DEBUG",
        "debuglevel": 99
    }
  ]
}
}

The version of Kea (both kea-dhcp4 and kea-dhcp-ddns) is 1.6.2.

Following a DHCP request, in the kea-dhcp4.log I see the following:

2020-04-30 02:57:22.354 DEBUG [kea-dhcp4.packets/1] DHCP4_BUFFER_RECEIVED received buffer from 10.10.20.254:67 to 172.16.100.3:67 over interface eth0
2020-04-30 02:57:22.354 DEBUG [kea-dhcp4.options/1] DHCP4_BUFFER_UNPACK parsing buffer received from 10.10.20.254 to 172.16.100.3 over interface eth0
2020-04-30 02:57:22.355 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_RECEIVED [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: DHCPREQUEST (type 3) received from 10.10.20.254 to 172.16.100.3 on interface eth0
2020-04-30 02:57:22.355 DEBUG [kea-dhcp4.packets/1] DHCP4_QUERY_DATA [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00, packet details: local_address=172.16.100.3:67, remote_address=10.10.20.254:67, msg_type=DHCPREQUEST (3), transid=0x92ac8b00,
options:
  type=012, len=024: "android-ec3f0728072dc9f3" (string)
  type=050, len=004: 10.10.20.52 (ipv4-address)
  type=053, len=001: 3 (uint8)
  type=055, len=009: 1(uint8) 33(uint8) 3(uint8) 6(uint8) 15(uint8) 28(uint8) 51(uint8) 58(uint8) 59(uint8)
  type=057, len=002: 1500 (uint16)
  type=060, len=012: "dhcpcd-5.5.6" (string)
  type=061, len=007: 01:d8:c4:6a:91:cf:de
2020-04-30 02:57:22.356 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_CFGMGR_SUBNET4_ADDR selected subnet 10.10.20.0/24 for packet received by matching address 10.10.20.254
2020-04-30 02:57:22.356 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_SELECTED [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: the subnet with ID 3 was selected for client assignments
2020-04-30 02:57:22.356 DEBUG [kea-dhcp4.packets/1] DHCP4_SUBNET_DATA [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: the selected subnet details: 10.10.20.0/24
2020-04-30 02:57:22.356 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 3, identified by hwaddr=D8C46A91CFDE
2020-04-30 02:57:22.357 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: hwaddr=D8C46A91CFDE
2020-04-30 02:57:22.357 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier hwaddr=D8C46A91CFDE, found 0 host(s)
2020-04-30 02:57:22.357 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 3 and identifier hwaddr=D8C46A91CFDE
2020-04-30 02:57:22.357 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER get one host with IPv4 reservation for subnet id 3, identified by client-id=01D8C46A91CFDE
2020-04-30 02:57:22.357 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ALL_IDENTIFIER get all hosts with reservations using identifier: client-id=01D8C46A91CFDE
2020-04-30 02:57:22.358 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ALL_IDENTIFIER_COUNT using identifier client-id=01D8C46A91CFDE, found 0 host(s)
2020-04-30 02:57:22.358 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ONE_SUBNET_ID_IDENTIFIER_NULL host not found using subnet id 3 and identifier client-id=01D8C46A91CFDE
2020-04-30 02:57:22.358 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: client packet has been assigned to the following class(es): UNKNOWN
2020-04-30 02:57:22.358 DEBUG [kea-dhcp4.dhcp4/1] DHCP4_CLASS_ASSIGNED [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: client packet has been assigned to the following class(es): ALL, VENDOR_CLASS_dhcpcd-5.5.6, UNKNOWN
2020-04-30 02:57:22.359 DEBUG [kea-dhcp4.ddns/1] DHCP4_CLIENT_HOSTNAME_PROCESS [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: processing client's Hostname option
2020-04-30 02:57:22.359 DEBUG [kea-dhcp4.ddns/1] DHCP4_CLIENT_HOSTNAME_DATA [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: client sent Hostname option: android-ec3f0728072dc9f3
2020-04-30 02:57:22.359 DEBUG [kea-dhcp4.ddns/1] DHCP4_CLIENT_HOSTNAME_DATA [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: client sent Hostname option: android-ec3f0728072dc9f3
2020-04-30 02:57:22.359 DEBUG [kea-dhcp4.ddns/1] DHCP4_RESPONSE_HOSTNAME_DATA [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: including Hostname option in the server's response: android-ec3f0728072dc9f3.dono.local
2020-04-30 02:57:22.360 INFO  [kea-dhcp4.leases/1] DHCP4_INIT_REBOOT [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: client is in INIT-REBOOT state and requests address 10.10.20.52
2020-04-30 02:57:22.360 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:d8:c4:6a:91:cf:de
2020-04-30 02:57:22.360 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_CLIENTID obtaining IPv4 leases for client ID 01:d8:c4:6a:91:cf:de
2020-04-30 02:57:22.360 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 3 and IPv4 address 10.10.20.52
2020-04-30 02:57:22.360 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.10.20.52
2020-04-30 02:57:22.361 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.10.20.52, found 0 host(s)
2020-04-30 02:57:22.361 DEBUG [kea-dhcp4.hosts/1] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 3 and address 10.10.20.52
2020-04-30 02:57:22.361 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_GET_ADDR4 obtaining IPv4 lease for address 10.10.20.52
2020-04-30 02:57:22.362 DEBUG [kea-dhcp4.alloc-engine/1] ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: extending lifetime of the lease for address 10.10.20.52
2020-04-30 02:57:22.362 DEBUG [kea-dhcp4.dhcpsrv/1] DHCPSRV_MEMFILE_UPDATE_ADDR4 updating IPv4 lease for address 10.10.20.52
2020-04-30 02:57:22.362 INFO  [kea-dhcp4.leases/1] DHCP4_LEASE_ALLOC [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: lease 10.10.20.52 has been allocated for 3600 seconds
2020-04-30 02:57:22.363 DEBUG [kea-dhcp4.ddns/1] DHCP4_NCR_CREATE [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: DDNS updates enabled, therefore sending name change requests
2020-04-30 02:57:22.363 DEBUG [kea-dhcp4.options/1] DHCP4_PACKET_PACK [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: preparing on-wire format of the packet to be sent
2020-04-30 02:57:22.363 DEBUG [kea-dhcp4.packets/1] DHCP4_PACKET_SEND [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: trying to send packet DHCPACK (type 5) from 172.16.100.3:67 to 10.10.20.254:67 on interface eth0
2020-04-30 02:57:22.364 DEBUG [kea-dhcp4.packets/1] DHCP4_RESPONSE_DATA [hwtype=1 d8:c4:6a:91:cf:de], cid=[01:d8:c4:6a:91:cf:de], tid=0x92ac8b00: responding with packet DHCPACK (type 5), packet details: local_address=172.16.100.3:67, remote_address=10.10.20.254:67, msg_type=DHCPACK (5), transid=0x92ac8b00,
options:
  type=001, len=004: 4294967040 (uint32)
  type=003, len=004: 10.10.20.254
  type=006, len=008: 10.10.40.200 10.10.40.201
  type=012, len=035: "android-ec3f0728072dc9f3.dono.local" (string)
  type=015, len=010: "dono.local" (string)
  type=051, len=004: 3600 (uint32)
  type=053, len=001: 5 (uint8)
  type=054, len=004: 172.16.100.3
  type=058, len=004: 900 (uint32)
  type=059, len=004: 1800 (uint32)
  type=061, len=007: 01:d8:c4:6a:91:cf:de

The logs seem to indicate that it tries to notify DDNS.
However, except for the startup logs, the kea-dhcp-ddns logs are completely empty.
I even did a tcpdump capture on all interfaces, but do not see any packets going to kea-dhcp-ddns (172.16.100.4).

Note that manually running nsupdate against Bind (10.10.40.200) does work. But I would really like to get this working after a host gets DHCP details.

I'd appreciate some help in tracking down the problem.
Thank you.
Ben Monroe


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

Re: [Kea-users] Kea DDNS issues

Joshua Schaeffer
You are sending to 172.16.100.4 from the DHCP4 server, but listening on localhost on the DDNS server:

On 4/29/20 9:45 PM, Ben Monroe wrote:
    "dhcp-ddns": {
      "enable-updates": true,
      "qualifying-suffix": "dono.local.",
      "server-ip": "172.16.100.4"

And in kea-dhcp-ddns.conf I have:
{
"DhcpDdns":
{
  "ip-address": "127.0.0.1",
  "port": 53001,
You need to listen on your global IP address. Use ss or netstat (if you have them available in your container) to confirm which interface D2 is actually listening on.
-- 
Thanks,
Joshua Schaeffer

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

Re: [Kea-users] Kea DDNS issues

Ben Monroe
Hi Joshua,

Thank you for the response.
I may be wrong, but I would expect that listening on 127.0.0.1 should work as it is the server itself.
In fact, the documentation includes a warning for any other configuration:
In any case, I changed it to the static Docker network IP 172.16.100.4 and restarted it.
I note that upon startup now the following warning appears:
2020-04-30 07:35:29.317 INFO  [kea-dhcp-ddns.dctl/1] DCTL_CONFIG_COMPLETE server has completed configuration: listening on 172.16.100.4, port 53001, using UDP
2020-04-30 07:35:29.319 WARN  [kea-dhcp-ddns.dhcpddns/1] DHCP_DDNS_NOT_ON_LOOPBACK the DHCP-DDNS server has been configured to listen on 172.16.100.4 which is not the local loopback.  This is an insecure configuration supported for testing purposes only

Following your suggesting I installed ss (iproute2). Oddly enough, it does not seem to be listening to any ports.
root@ a987aac4aa8b:/# ss
Netid             State             Recv-Q             Send-Q                         Local Address:Port                         Peer Address:Port

One may wonder if kea-dhcp-ddns is really running.
I don't have ps available in the container, but if I try to run it again manually I naturally get the following:
root@a987aac4aa8b:/# /usr/sbin/kea-dhcp-ddns -c /etc/kea/kea-dhcp-ddns.conf
2020-04-30 07:34:00.521 FATAL [kea-dhcp-ddns.dctl/14] DCTL_ALREADY_RUNNING kea-dhcp-ddns already running? Daemon::createPIDFile: PID: 1 exists, PID file: /var/run/kea/kea-dhcp-ddns.kea-dhcp-ddns.pid
Service failed: Launch Failed: Daemon::createPIDFile: PID: 1 exists, PID file: /var/run/kea/kea-dhcp-ddns.kea-dhcp-ddns.pid
root@a987aac4aa8b:/#

Any idea why it is not listening for connections?
For reference, here are the debug logs:
2020-04-30 07:35:29.313 DEBUG [kea-dhcp-ddns.dhcpddns/1] DHCP_DDNS_CONFIGURE configuration update received: { "control-socket": { "socket-name": "/tmp/kea-dhcp-ddns-ctrl.sock", "socket-type": "unix" }, "forward-ddns": { "ddns-domains": [ { "dns-servers": [ { "ip-address": "172.16.100.1" }, { "ip-address": "172.16.100.2" } ], "key-name": "rndc-key", "name": "dono.local." } ] }, "ip-address": "172.16.100.4", "loggers": [ { "debuglevel": 99, "name": "kea-dhcp-ddns", "output_options": [ { "flush": true, "maxsize": 1048576, "maxver": 3, "output": "/etc/kea/kea-ddns.log" } ], "severity": "DEBUG" } ], "port": 53001, "reverse-ddns": { "ddns-domains": [ { "dns-servers": [ { "ip-address": "172.16.100.1" }, { "ip-address": "172.16.100.2" } ], "key-name": "rndc-key", "name": "10.10.10.in-addr.arpa." }, { "dns-servers": [ { "ip-address": "172.16.100.1" }, { "ip-address": "172.16.100.2" } ], "key-name": "rndc-key", "name": "20.10.10.in-addr.arpa." }, { "dns-servers": [ { "ip-address": "172.16.100.1" }, { "ip-address": "172.16.100.2" } ], "key-name": "rndc-key", "name": "40.10.10.in-addr.arpa." } ] }, "tsig-keys": [ { "algorithm": "hmac-sha256", "name": "rndc-key", "secret": "<secret>" } ] }
2020-04-30 07:35:29.313 DEBUG [kea-dhcp-ddns.dctl/1] DCTL_CONFIG_START parsing new configuration: { "control-socket": { "socket-name": "/tmp/kea-dhcp-ddns-ctrl.sock", "socket-type": "unix" }, "forward-ddns": { "ddns-domains": [ { "dns-servers": [ { "ip-address": "172.16.100.1" }, { "ip-address": "172.16.100.2" } ], "key-name": "rndc-key", "name": "dono.local." } ] }, "ip-address": "172.16.100.4", "loggers": [ { "debuglevel": 99, "name": "kea-dhcp-ddns", "output_options": [ { "flush": true, "maxsize": 1048576, "maxver": 3, "output": "/etc/kea/kea-ddns.log" } ], "severity": "DEBUG" } ], "port": 53001, "reverse-ddns": { "ddns-domains": [ { "dns-servers": [ { "ip-address": "172.16.100.1" }, { "ip-address": "172.16.100.2" } ], "key-name": "rndc-key", "name": "10.10.10.in-addr.arpa." }, { "dns-servers": [ { "ip-address": "172.16.100.1" }, { "ip-address": "172.16.100.2" } ], "key-name": "rndc-key", "name": "20.10.10.in-addr.arpa." }, { "dns-servers": [ { "ip-address": "172.16.100.1" }, { "ip-address": "172.16.100.2" } ], "key-name": "rndc-key", "name": "40.10.10.in-addr.arpa." } ] }, "tsig-keys": [ { "algorithm": "hmac-sha256", "name": "rndc-key", "secret": "<secret>" } ] }
2020-04-30 07:35:29.315 INFO  [kea-dhcp-ddns.commands/1] COMMAND_ACCEPTOR_START Starting to accept connections via unix domain socket bound to /tmp/kea-dhcp-ddns-ctrl.sock
2020-04-30 07:35:29.317 INFO  [kea-dhcp-ddns.dctl/1] DCTL_CONFIG_COMPLETE server has completed configuration: listening on 172.16.100.4, port 53001, using UDP
2020-04-30 07:35:29.317 DEBUG [kea-dhcp-ddns.dctl/1] DCTL_RUN_PROCESS DhcpDdns starting application event loop
2020-04-30 07:35:29.318 INFO  [kea-dhcp-ddns.dhcpddns/1] DHCP_DDNS_STARTED Kea DHCP-DDNS server version 1.6.2 started
2020-04-30 07:35:29.318 DEBUG [kea-dhcp-ddns.commands/1] COMMAND_REGISTERED Command build-report registered
2020-04-30 07:35:29.318 DEBUG [kea-dhcp-ddns.commands/1] COMMAND_REGISTERED Command config-get registered
2020-04-30 07:35:29.318 DEBUG [kea-dhcp-ddns.commands/1] COMMAND_REGISTERED Command config-reload registered
2020-04-30 07:35:29.318 DEBUG [kea-dhcp-ddns.commands/1] COMMAND_REGISTERED Command config-set registered
2020-04-30 07:35:29.318 DEBUG [kea-dhcp-ddns.commands/1] COMMAND_REGISTERED Command config-test registered
2020-04-30 07:35:29.318 DEBUG [kea-dhcp-ddns.commands/1] COMMAND_REGISTERED Command config-write registered
2020-04-30 07:35:29.318 DEBUG [kea-dhcp-ddns.commands/1] COMMAND_REGISTERED Command shutdown registered
2020-04-30 07:35:29.318 DEBUG [kea-dhcp-ddns.commands/1] COMMAND_REGISTERED Command version-get registered
2020-04-30 07:35:29.318 DEBUG [kea-dhcp-ddns.dhcpddns/1] DHCP_DDNS_QUEUE_MGR_RECONFIGURING application is reconfiguring the queue manager
2020-04-30 07:35:29.319 WARN  [kea-dhcp-ddns.dhcpddns/1] DHCP_DDNS_NOT_ON_LOOPBACK the DHCP-DDNS server has been configured to listen on 172.16.100.4 which is not the local loopback.  This is an insecure configuration supported for testing purposes only
2020-04-30 07:35:29.319 DEBUG [kea-dhcp-ddns.dhcpddns/1] DHCP_DDNS_QUEUE_MGR_STARTED application's queue manager has begun listening for requests.

And here are interface details from within the container:
root@a987aac4aa8b:/# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
287: eth0@if288: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:10:64:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 172.16.100.4/24 brd 172.16.100.255 scope global eth0
       valid_lft forever preferred_lft forever

Regards,
Ben Monroe

On Thu, Apr 30, 2020 at 2:30 PM Joshua Schaeffer <[hidden email]> wrote:
You are sending to 172.16.100.4 from the DHCP4 server, but listening on localhost on the DDNS server:

On 4/29/20 9:45 PM, Ben Monroe wrote:
    "dhcp-ddns": {
      "enable-updates": true,
      "qualifying-suffix": "dono.local.",
      "server-ip": "172.16.100.4"

And in kea-dhcp-ddns.conf I have:
{
"DhcpDdns":
{
  "ip-address": "127.0.0.1",
  "port": 53001,
You need to listen on your global IP address. Use ss or netstat (if you have them available in your container) to confirm which interface D2 is actually listening on.
-- 
Thanks,
Joshua Schaeffer

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

Re: [Kea-users] Kea DDNS issues

Joshua Schaeffer


On 4/30/20 1:57 AM, Ben Monroe wrote:
I may be wrong, but I would expect that listening on 127.0.0.1 should work as it is the server itself.

I have more experience with LXD containers then docker containers so I could be wrong here, but I would assume that each container has its own network namespace therefore D2's containers' loopback is not the same as DHCP4's containers' loopback (and both would be different then the host's loopback). In either case you would have to send requests to loopback in order for that to work and you are sending them to a global address. The IP addresses must match between the two configurations. See the note below the warning in the documentation link you posted.

Perhaps someone with more knowledge about docker knows if it is possible to expose the loopback address from one container to another or share the host's. I would assume there are security concerns if this is true.

In fact, the documentation includes a warning for any other configuration:

Yes it is a security concern to run D2 on a global address. What this means is that it is recommended to always run it on the same machine (in your case container) as the DHCP4 and/or DHCP6 server(s). Again there may be some neat way in docker to avoid all this, but if not just make sure you secure that address as much as possible to avoid spoofed DNS change requests.

Following your suggesting I installed ss (iproute2). Oddly enough, it does not seem to be listening to any ports.
root@ a987aac4aa8b:/# ss
Netid             State             Recv-Q             Send-Q                         Local Address:Port                         Peer Address:Port

Does running `ss -tupnl | grep 53001` return anything? If not try that command on the docker host. It's unclear if you actually tested a change request after restarting D2? Can you try submitting one. You can also sniff the wire again to see if traffic is being received this time.
-- 
Thanks,
Joshua Schaeffer

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

Re: [Kea-users] Kea DDNS issues

Ben Monroe
Hi Joshua,

Thank you for the follow up.
Indeed, as you suggested I can see the listening socket in ss.

# ss -tupnl | grep 53001
udp     UNCONN   0        0           172.16.100.4:53001          0.0.0.0:*      users:(("kea-dhcp-ddns",pid=1,fd=13))
#

Also as you indicated, this is clearly listening on the internal Docker network IP rather than the loopback.
Not as I expected, but I am convinced. I also appreciate the additional comments on security.
After a complete restart of all relevant containers I have begun to see DDNS updates.

Much appreciated,
Ben Monroe

On Fri, May 1, 2020 at 4:23 AM Joshua Schaeffer <[hidden email]> wrote:


On 4/30/20 1:57 AM, Ben Monroe wrote:
I may be wrong, but I would expect that listening on 127.0.0.1 should work as it is the server itself.

I have more experience with LXD containers then docker containers so I could be wrong here, but I would assume that each container has its own network namespace therefore D2's containers' loopback is not the same as DHCP4's containers' loopback (and both would be different then the host's loopback). In either case you would have to send requests to loopback in order for that to work and you are sending them to a global address. The IP addresses must match between the two configurations. See the note below the warning in the documentation link you posted.

Perhaps someone with more knowledge about docker knows if it is possible to expose the loopback address from one container to another or share the host's. I would assume there are security concerns if this is true.

In fact, the documentation includes a warning for any other configuration:

Yes it is a security concern to run D2 on a global address. What this means is that it is recommended to always run it on the same machine (in your case container) as the DHCP4 and/or DHCP6 server(s). Again there may be some neat way in docker to avoid all this, but if not just make sure you secure that address as much as possible to avoid spoofed DNS change requests.

Following your suggesting I installed ss (iproute2). Oddly enough, it does not seem to be listening to any ports.
root@ a987aac4aa8b:/# ss
Netid             State             Recv-Q             Send-Q                         Local Address:Port                         Peer Address:Port

Does running `ss -tupnl | grep 53001` return anything? If not try that command on the docker host. It's unclear if you actually tested a change request after restarting D2? Can you try submitting one. You can also sniff the wire again to see if traffic is being received this time.
-- 
Thanks,
Joshua Schaeffer

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