Possibly you have a dhcp relay/dhcp helper configured somewhere in the network, which is pointing to the "disabled" dhcp server. The request will contain the ip address of the relaying device and when this is not matching with the dhcp subnet then a NACK will be issued.The details you can find out by doing some packet tracing.
Ples see here: https://documentation.meraki.com/zGeneral_Administration/Tools_and_Troubleshooting/DHCP_NAK
A DHCP NAK is a negative acknowledgment from the DHCP server. The
server will send a DHCP NAK in the following scenarios:
Requested address from possibly the same subnet but not in the address pool of the server. This can be the failover scenario in
which 2 DHCP servers are serving the same subnet so that when one
goes down, the other should not NAK to clients which got an IP from
the first server.
Requested address is on a different subnet.
Requested address is already in use by another client.
To your other questions:
So, why is the router giving a NACK, while it's supposed to be turned off ? What role exactly does the directive 'authoritive' from the dhcpd.conf play here ?
It seems the dhcp server is not really turned off.
Quote from https://linux.die.net/man/5/dhcpd.conf :
The authoritative statement
authoritative;
not authoritative;
The DHCP server will normally assume that the configuration
information about a given network segment is not known to be correct
and is not authoritative. This is so that if a naive user installs a
DHCP server not fully understanding how to configure it, it does not
send spurious DHCPNAK messages to clients that have obtained addresses
from a legitimate DHCP server on the network.
Network administrators setting up authoritative DHCP servers for their
networks should always write authoritative; at the top of their
configuration file to indicate that the DHCP server should send
DHCPNAK messages to misconfigured clients. If this is not done,
clients will be unable to get a correct IP address after changing
subnets until their old lease has expired, which could take quite a
long time.
Usually, writing authoritative; at the top level of the file should be
sufficient. However, if a DHCP server is to be set up so that it is
aware of some networks for which it is authoritative and some networks
for which it is not, it may be more appropriate to declare authority
on a per-network-segment basis.
Note that the most specific scope for which the concept of authority
makes any sense is the physical network segment - either a
shared-network statement or a subnet statement that is not contained
within a shared-network statement. It is not meaningful to specify
that the server is authoritative for some subnets within a shared
network, but not authoritative for others, nor is it meaningful to
specify that the server is authoritative for some host declarations
and not others.
So my most important question, how can I troubleshoot this ?
Answer is packet tracing.
https://www-01.ibm.com/support/docview.wss?uid=swg21175744