Bind 9 - allow-query-on versus listen-on

I was just wondering about differences in behavior between Bind 9's allow-query-on and listen-on statements. They appear to perform similar functions. According to Chapter 6 of the ARM ("Bind 9 Configuration"):

The interfaces and ports that the server will answer queries from may be specified using the listen-on option.

The syntax given is:

listen-on [ port ip_port ] [ dscp ip_dscp ] { address_match_list } ;

Also in the same chapter:

allow-query-on: Specifies which local addresses can accept ordinary DNS questions.

The syntax given is:

allow-query-on { address_match_list } ;

From the syntax, it looks like allow-query-on does not allow port numbers to be specified. Are there other differences too?

They're not really similar functions. The listen-on statement is required for named to bind on a specific IP address and port. Without setting it, the default is to listen for DNS queries on port 53 of all interfaces on your server. If you have a server with multiple interfaces and you only want to provide DNS services on one of them, use listen-on to only listen on the one interface. Trying to do it the other way with allow-query-on only will leave BIND still listening on all interfaces. The best way is to use both, i.e. bind to only the interface(s) you need and then further restrict the type of queries you permit.

listen-on

listen-on is used to specify which address/port combinations that the named process should bind(3).
Ie, the address/port combinations for which named tells the operating system that it is the process which "listens" and thus wants to receive whatever is sent there.

There is no understanding of DNS on the socket API level, so there is no means of having any kind of fine-grained control here. You either listen or you don't, and if you do, then nothing else can listen on the same address/port (with implications on what else can run side-by-side on the same host).

allow-*-on

allow-*-on (and, with the opposite perspective the regular allow-* directives) are access control measures inside of BIND for different types of DNS messages (different categories of queries, updates, zone transfers, etc.) that it has received.

As this is functionality inside of BIND, it has interpreted the DNS data that it received and allows much more fine-grained access control (but it must have listened somewhere to receive the messages in the first place).