hostmask on an ip address can affect jail DNS

I encountered, and later solved, a DNS issue on a FreeBSD jail. The jail is my web proxy, of sorts. I have one public IP address, which is dynamic (not relevant, but mentioned only in passing) so all incoming web traffic goes to a single internal RFC-1918 IP address. From there, nginx does reverse proxies out to the various hosts:

devgit.freshports.org
dev.freshports.org
test.freshports.org
stage.freshports.org

There are more, but you get the idea. Each of those websites are on a different internal jail. This is why serpico exists, to redirect the incoming web queries to the correct location.

Yesterday I noticed an issue with DNS, it looked like this:

[dan@serpico:~] $ host google.ca
Host google.ca not found: 3(NXDOMAIN)
[dan@serpico:~] $ host serpico
serpico.int.example.org has address 10.0.0.24
[dan@serpico:~] $ host serpico.int.example.org
serpico.int.example.org has address 10.0.0.24
[dan@serpico:~] $ grep serpico /etc/hosts
[dan@serpico:~] $ host bast
bast.int.example.org has address 10.0.0.1
bast.int.example.org has IPv6 address 2001:470:[redacted]::
[dan@serpico:~] $ cat /etc/resolv.conf 
# Generated by resolvconf
search unixathome.org int.unixathome.org
nameserver 10.0.0.53
nameserver 10.0.0.153

[dan@serpico:~] $ host google.com
Host google.com not found: 3(NXDOMAIN)

I was able to resolve internal hosts but not external hosts.

I went to 10.0.0.53 and tailed the logs:

[dan@slocum:/var/log/named] $ tail -F queries.log | grep google.ca
16-Aug-2020 15:04:34.864 client @0x814e72168 172.16.12.2#63543 (google.ca): query: google.ca IN A + (10.0.0.73)
16-Aug-2020 15:04:34.864 client @0x8153b4b68 172.16.12.2#18295 (google.ca.unixathome.org): query: google.ca.unixathome.org IN A + (10.0.0.73)
16-Aug-2020 15:04:34.864 client @0x815259168 172.16.12.2#39580 (google.ca.int.unixathome.org): query: google.ca.int.unixathome.org IN A + (10.0.0.73)

Ahh, the incoming queries are from a 172.16 address! This was unexpected.

These servers specifically permits recursion for only specific subnets:

allow-recursion { 10.0.0.0/24; [redacted]/24; [redacted]/32; [redacted]/32; [redacted]/24; };

172.16 is not specified in that list.

This is a recent issue. This worked fine for years. The 172.16 address was added only recently.

This was the ifconfig output in the jail for the primary interface.

[dan@serpico:~] $ ifconfig ix2
ix2: flags=8843 metric 0 mtu 1500
options=e53fbb
	ether 00:1b:21:39:a9:c5
	inet 172.16.12.2 netmask 0xffffffff broadcast 172.16.12.2
	inet 10.0.0.24 netmask 0xffffffff broadcast 10.0.0.24
	inet 10.0.0.8 netmask 0xffffffff broadcast 10.0.0.8
	inet6 2001:470:[redacted] prefixlen 64
	inet6 2001:470:[redacted] prefixlen 64
	media: Ethernet autoselect (10Gbase-SR )
	status: active
	nd6 options=23

I noted the 172.16 address was listed first. It reminded me of this still open PR raised in 2015 regarding order of IPs in jails depends on order on host. I do not believe the two issues are related.

Let’s look at the declaration for the jail on the host:

[dan@slocum:~] $ iocage get ip4_addr serpico
10.0.0.24/32,10.0.0.8/32,172.16.12.2

I saw the lack of a /24 on the 172.16.12.2 address. Let’s add that in:

[dan@slocum:~] $ sudo iocage set ip4_addr="10.0.0.24/32,10.0.0.8/32,172.16.12.2/32" serpico
ip4_addr: 10.0.0.24/32,10.0.0.8/32,172.16.12.2 -> 10 10.0.0.24/32,10.0.0.8/32,172.16.12.2/32

And I restarted that jail: sudo iocage restart serpico

Logging back into the jail I saw:

[dan@serpico:~] $ ifconfig ix2
ix2: flags=8843 metric 0 mtu 1500
options=e53fbb
	ether 00:1b:21:39:a9:c5
	inet6 2001:470:[redacted] prefixlen 64
	inet6 2001:470:[redacted] prefixlen 64
	inet 10.0.0.24 netmask 0xffffffff broadcast 10.0.0.24
	inet 10.0.0.8 netmask 0xffffffff broadcast 10.0.0.8
	inet 172.16.12.2 netmask 0xffffffff broadcast 172.16.12.2
	media: Ethernet autoselect (10Gbase-SR )
	status: active
	nd6 options=23
[dan@serpico:~] $

Now the “primary” IP address is 10.0.0.24. Let’s try the DNS queries again:

[dan@serpico:~] $ host google.ca
google.ca has address 172.217.3.99
google.ca has IPv6 address 2607:f8b0:4006:818::2003
google.ca mail is handled by 30 alt2.aspmx.l.google.com.
google.ca mail is handled by 10 aspmx.l.google.com.
google.ca mail is handled by 40 alt3.aspmx.l.google.com.
google.ca mail is handled by 50 alt4.aspmx.l.google.com.
google.ca mail is handled by 20 alt1.aspmx.l.google.com.
[dan@serpico:~] $

The named logs show:

16-Aug-2020 15:06:25.919 client @0x8142d2168 10.0.0.24#46394 (google.ca): query: google.ca IN A + (10.0.0.73)
16-Aug-2020 15:06:25.939 client @0x815ab0768 10.0.0.24#16649 (google.ca): query: google.ca IN AAAA + (10.0.0.73)
16-Aug-2020 15:06:25.939 client @0x815579168 10.0.0.24#53603 (google.ca): query: google.ca IN MX + (10.0.0.73)

I’ll wait and see what happens after a reboot. This issue sounds familiar though.

For now, it’s fixed.

Leave a Comment Cancel Reply