Serwer Kea DHCP oparty jest na BIND 10 i zbudowany przez stosując architekturę modułową, co oznacza podział funkcjonalności na różne procesy procesorowe. Produkt zawiera w pełni funkcjonalną implementację serwera z obsługą protokołów DHCPv4 i DHCPv6, zdolną zastąpić ISC DHCP. Kea posiada wbudowane narzędzia do dynamicznej aktualizacji stref DNS (Dynamic DNS), obsługuje mechanizmy wykrywania serwerów, przydzielania adresów, aktualizacji i ponownego łączenia, obsługi żądań informacji, rezerwowania adresów dla hostów i uruchamiania PXE. Implementacja DHCPv6 dodatkowo zapewnia możliwość delegowania prefiksów. Do interakcji z aplikacjami zewnętrznymi udostępniono specjalne API. Możliwa jest aktualizacja konfiguracji na bieżąco, bez konieczności ponownego uruchamiania serwera.
Informacje o przydzielonych adresach i parametrach klienta można przechowywać w różnych typach pamięci - obecnie dostępne są backendy do przechowywania w plikach CSV, MySQL DBMS, Apache Cassandra i PostgreSQL. Parametry rezerwacji hosta można określić w pliku konfiguracyjnym w formacie JSON lub w postaci tabeli w MySQL i PostgreSQL. Zawiera narzędzie perfdhcp do pomiaru wydajności serwera DHCP oraz komponenty do gromadzenia statystyk. Kea wykazuje dobrą wydajność, na przykład podczas korzystania z backendu MySQL serwer może wykonać 1000 przypisań adresów na sekundę (około 4000 pakietów na sekundę), a podczas korzystania z backendu plików memowych wydajność osiąga 7500 przypisań na sekundę.
Zaimplementowano backend konfiguracyjny (CB, Configuration Backend), pozwalający na centralne zarządzanie ustawieniami kilku serwerów DHCPv4 i DHCPv6. Zaplecza można używać do przechowywania większości ustawień Kea, w tym ustawień globalnych, sieci współdzielonych, podsieci, opcji, pul i definicji opcji. Zamiast przechowywać wszystkie te ustawienia w lokalnym pliku konfiguracyjnym, można je teraz umieścić w zewnętrznej bazie danych. W takim przypadku możliwe jest określenie nie wszystkich, ale części ustawień poprzez CB, nakładając parametry z zewnętrznej bazy danych i lokalnych plików konfiguracyjnych (np. ustawienia interfejsu sieciowego można pozostawić w plikach lokalnych).
Spośród systemów DBMS do przechowywania konfiguracji obecnie obsługiwany jest tylko MySQL (MySQL, PostgreSQL i Cassandra mogą być używane do przechowywania baz danych przypisań adresów (dzierżawy), a MySQL i PostgreSQL mogą być używane do rezerwowania hostów). Konfigurację w bazie danych można zmieniać albo poprzez bezpośredni dostęp do SZBD, albo poprzez specjalnie przygotowane biblioteki warstwowe, które udostępniają standardowy zestaw poleceń do zarządzania konfiguracją, takich jak dodawanie i usuwanie parametrów, powiązań, opcji DHCP i podsieci;
Dodano nową klasę obsługi „DROP” (wszystkie pakiety powiązane z klasą DROP są natychmiast usuwane), która może zostać wykorzystana do odrzucania niechcianego ruchu, na przykład niektórych typów wiadomości DHCP;
Dodano nowe parametry max-lease-time i min-lease-time, które pozwalają określić czas życia adresu wiążącego się z klientem (dzierżawą) nie w formie zakodowanej na stałe wartości, ale w formie akceptowalna ranga;
Poprawiona kompatybilność z urządzeniami, które nie są w pełni zgodne ze standardami DHCP. Aby obejść te problemy, Kea wysyła teraz informacje o typie komunikatu DHCPv4 na samym początku listy opcji, obsługuje różne reprezentacje nazw hostów, rozpoznaje transmisję pustej nazwy hosta i umożliwia zdefiniowanie kodów podopcji od 0 do 255;
Dla demona DDNS dodano osobne gniazdo sterujące, za pośrednictwem którego można bezpośrednio wysyłać polecenia i dokonywać zmian konfiguracyjnych. Obsługiwane są następujące polecenia: build-report, config-get, config-reload, config-set, config-test, config-write, list-commands, Shutdown i Version-get;
Wyłączony luki w zabezpieczeniach (CVE-2019-6472, CVE-2019-6473, CVE-2019-6474), które można wykorzystać do spowodowania odmowy usługi (powodującej awarię procedur obsługi serwerów DHCPv4 i DHCPv6) poprzez wysyłanie żądań z nieprawidłowymi opcjami i wartościami. Największym niebezpieczeństwem jest problem CVE-2019-6474, co w przypadku wykorzystania pamięci plikowej do powiązań uniemożliwia samodzielne ponowne uruchomienie procesu serwera, dlatego w celu przywrócenia działania wymagana jest ręczna interwencja administratora (czyszczenie bazy danych powiązań).