Note that is all Linux-specific behavior. BSD-derived stacks are generally different, e.g. FreeBSD and MacOS. They do not respond to addresses that aren’t explicitly assigned to an interface. You cannot bind an address not assigned to an interface.
On Sun, Jul 6, 2025 at 9:23 AM Grant Taylor via bind-users < bind-users@lists.isc.org> wrote: > New-Subject: host vs subnet routes > Old-Subject: BIND doesn't listen to other loopback addresses > > On 7/6/25 1:02 AM, Ondřej Surý wrote: > > The IPv4 loopback is actually quite weird in this regard that > > 127.0.0.1/8 is assigned by everything in 127/8 automagically works > > without explicit address assigned to the interface. > > This is a kernel default. But you can fairly easily change this > behavior for any interface / subnet you want to. > > The 127/8 that you mention is actually assigned as a route in the local > routing table. > > % ip -4 route show table local | grep 127 > local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 > local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 > broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 > > It's specifically the `local 127.0.0.0/8....` <http://127.0.0.0/8....> > route that is causing the > behavior that you're describing. > > N.B. It is the route type of "local" that causes this behavior. "local" > routes tell the kernel that everything that matches the route is > destined to the local system. It just happens to be that said local > route is located in the routing table named local. But local route can > go in other routing tables. > > You can change / remove that route to alter the behavior. > > More interestingly, you can add similar routes for other subnets / > interfaces if you would like the same behavior for other things. I've > got the following on a router to cause it to act like 127/8 but for > 192.0.2/8: > > % ip -4 route show table local | grep 192.0.2. > local 192.0.2.0/24 dev eth1 scope host metric 4 > local 192.0.2.1 dev eth1 proto kernel scope host src 192.0.2.1 > broadcast 192.0.2.255 dev eth1 proto kernel scope link src 192.0.2.1 > > Here are the related routes in the main routing table: > > % ip route show table main | grep 192.0.2. > 192.0.2.0/24 dev eth1 proto kernel scope link src 192.0.2.1 > 192.0.2.7 dev eth1 scope link metric 4 > 192.0.2.24 dev eth1 scope link metric 4 > > The 192.0.2.0/24 route in the main routing table is what is expected for > a locally attached subnet. > > The 192.0.2.7 and 192.0.2.24 host routes in the main routing table are > used to be a more specific match to override the less specific local > 192.0.2.0/24 route in the local routing table. > > The net result is that the system thinks that all IPs in the > 192.0.2.0/24 subnet are local to it with the two exceptions being > 192.0.2.7 and 192.0.2.24. > > This also works for the systems in the subnet, when they ARP for any IP > other than 192.0.2.7 or 192.0.2.24, the router replies to the ARP > request, thereby causing all other 192.0.2.0/24 traffic to go to it. > > Yes, 127/8 is weird. But it makes sense if you look at the routing > tables. It's also fun to apply the same behavior to other subnets / > interfaces. }:-) > > > > -- > Grant. . . . > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > >
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
