DNS-database unable to add a root zone

[JPMfg]

Hi,

For some reasons we would like to be able to have a FortiGate built-in DNS server to send negative answers (NXDOMAIN) for all queries.

The easiest way to do that on any bind/windows DNS server is to have a master zone for the root zone (".")  without any records.

The Fortigate config however does not allow me to create a zone with the otherwise perfectly valid Domainname "." (IETF Internet Standard STD0013 and RFC-1034/1035)

The Error is "domain name is not a valid dns name" and "node_check_object fail! for domain ." for >>set domain"."<< in a dns-dabase entry.

Is this a bug? do we need to open a support ticket?

There are about 1500 TLDs currently assigned by IANA, it would not be feasible to create dns database entries for each of them individually, we must be able to configure the root zone directly!

[emnoc]

Why? Would we should be doing some sort of  negative-cache, or using a dns-forwarder.

IMHO the root-dnsserver should be the actual root   dns-server not a manipulation of such.

So if someone ask for nosuch_mydomain.nosuch_tld  we cache a negative response

Ken

[JPMfg]

The reason is actually pretty simple:

1.) The fortigate is the only device on site (apart from dumb layer 2 switches).

2.) We need an authoritative DNS server that MUST responds with NXDOMAIN negative answers and not just timeouts or servfail errors (as would be the case with no or incorrect forwarders configured on the fortigate)

3.) it is simple in Fortios to configure an authoritative empty zone for toplevel domains (.com, .net etc.), but the IANA decided to open up the bloody root for everyone with money, so we now have 1600 top level domains.

The config parser however refuses to accept the root zone itself. This is probably not a limitation of the name server itself because every other resolver software supports having an authoritative root zone configured.

4.) The Fortigate VDOM in question must not be able to resolve via any forwarder or recursively.

Currently the workaround would be to configure 1600 top level zones.

[emnoc]

Currently the workaround would be to configure 1600 top level zones.

You know that will not work out in the end , I believe dot.com has like 100+ millon zone and that 1600 for TLD your quoted   is well over 5k.

Why can't the fortigate just answer with nothing ? or the std NXDOMAIN?   if do a lookup of  mydomainisnotreallycorrect.notld  and the dns server response with what response?

trying to chase  tld is going to be fruitless ;)

YMMV

[JPMfg]

emnoc wrote:
 

You know that will not work out in the end , I believe dot.com has like 100+ millon zone and that 1600 for TLD your quoted   is well over 5k.

No, the point is we need an empty zone. This is the only way to make a DNS server respond with NXDOMAIN (negative answer, or "this domain name does not exist!" in plain english).

emnoc wrote:

Why can't the fortigate just answer with nothing ? or the std NXDOMAIN?   if do a lookup of  mydomainisnotreallycorrect.notld  and the dns server response with what response?

trying to chase  tld is going to be fruitless ;)

YMMV

In DNS protocol "NXDOMAIN" is the Answer "nothing here, move along!".

If you just block the request, you get a Timeout after 10 to 30 seconds, and THAT is absolutely unacceptable.

On any standard DNS software (ISC BIND, Unbound, Microsoft Active Directory DNS service etc.) the normal way to archive this is to define an authoritative root zone for the Domain name "." instead of using the well known forwarder hints. This zone does not have any records! It is not desired to be able to resolve IANA name space, the point is to create a Non-IANA name space that does not contain any public names.