14.5. DNS configuration

14.5. DNS configuration
	Chapter 14. System Services

The DNS service provides name resolution service to other tasks within the app software, and can act as a relay for requests received from client machines. DNS typically means converting a name, like www.firebrick.co.uk to one or more IP addresses, but it can also be used for reverse DNS finding the name of an IP address. DNS service is normally provided by your ISP.

The DNS service on the FB9000 simply relays requests to external DNS servers and caches replies. You can configure a list of external DNS servers using the resolvers attribute. However, DNS resolvers are also learned automatically via various systems such as DHCP and PPPoE. In most cases you do not need to set the resolvers.

14.5.1. Auto DHCP DNS

The FB9000 can also look for specific matching names and IP addresses for forward and reverse DNS that match machines on your LAN. This is done by telling the FireBrick the domain for your local network. Any name that is within that domain which matches a client name of a DHCP allocation that the FireBrick has made will return the IP address assigned by DHCP. This is applied in reverse for reverse DNS mapping an IP address back to a name. You can enable this using the auto-dhcp attribute.

In addition, the DHCP server records the IP of the latest new automatically allocated address on any interface, and you can set auto-dns-new as a name (e.g. new) to be used for this IP address. This is ideal for finding the IP of a newly added device, and is particularly useful when adding new IoT devices one at a time so they can be configured via a web interface, for example. This is only set for a new dynamic IP allocation, not a renewed, or reused IP for same device previously using the IP.

Note

It is assumed that the domain used is either within your control or has been designated for local use and therefore that any additional record types (e.g. SVR records) for those hosts are within your control. If they do exist then these will be assumed to be intentional and thus the recursive lookup and caching process will occur as normal. If this is not desirable then Blocking DNS names can be used to hide the remainder of the zone.

14.5.2. Local DNS responses

Instead of blocking names, you can also make some names return pre-defined responses. This is usually only used for special cases, and there is a default for my.firebrick.uk which returns the FireBrick's own IP. Faking DNS responses will not always work, and new security measures such as DNSSEC will mean these faked responses will not be accepted.

This mechanism will respond to A, AAAA, PTR or ANY type requests. Those of other types will blocked rather than sent upstream to avoid conflicting results from the override and the wider zone.

Note

You can leave the IP unset, and this will return the FireBrick's own IP (as used for my.firebrick.uk), but this can also return an IP based on the request if the match is for a *. name in the right format. For example 192-168-0-1.my.firebrick.uk returns A record 192.168.0.1.

14.5.3. Blocking DNS names

You can configure names such that the FB9000 issues an NXDOMAIN response making it appear that the domain does not exist. This can be done using a wildcard, e.g. you could block *.xxx.

Note

The blocking rules are applied after local and automatic DNS have been taken into account. As a result they will not block those explicitly overridden domains, but can be used to hide other record types for an auto DHCP DNS domain if needed.

Tip

You can also restrict responses to certain IP addresses on your LAN, making it that some devices get different responses. You can also control when responses are given using a profile, e.g. time of day.


14.4. Telnet Server configuration		14.6. NTP configuration