DNS-Spoofing with multiple interfaces

[Williams, Gareth]

Hi,

It was a false alarm!

I'm running Unbound on Open-WRT.  This has an option to configure it
using the Open-WRT GUI (Luci).  When the Unbound startup script is
ran, it attempts to configure Unbound for me and it seems it fails.

Fortunately, there's an option to use manual config. When I choose
that option and create a simple unbound.conf things work as expected.

This issue should be raised as an Open-WRT bug.

Kind regards,

Gareth

On Wed, 10 Jul 2019 at 20:33, Gareth Williams
<gareth at garethwilliams.me.uk> wrote:
>
> Hi,
>
> I'm running Unbound (for the very first time - so please bear with me)
> on a router with three interfaces.
>
> The 1st interface is PPP to my ADSL modem and has an Internet IP
> address 51.x.y.z.  I have global DNS pointing 'nimbus.my.domain.uk' to
> this address.
>
> The 2nd interfac is WiFi with a private IP address of 192.168.1.1
>
> The 3rd interface is an Ethernet connection to my office and has
> another private IP address of 172.28.1.1.  Routing is configured to
> send 172.28.0.0/16 through this interface, and have a few services in
> this network, including a service which I want to be accessible from
> both internal and the Internet.
>
> I'm trying to get the Unbound to provide a private IP address to a
> global Internet DNS name with:
>
>   local-data: "nimbus.my.domain.uk. IN A 172.28.4.30"
>
> When I use 'dig', I get confusing results.
>
> For all interfaces other than the 3rd:
>
>   dig @<interface IP> -p 1053 nimbus.my.domain.uk
>
> returns 172.28.4.30
>
> However, for the 3rd interface, it returns the Internet IP 51.x.y.z
> which is being resolved by the global Internet DNS.  Why?  I can't see
> any configuration option that would cause this.  I can't see this being
> an RFC1918 issue as 192.168.1.1 works, while the other RFC1918 address
> fails.  At the same time the 51.x.y.z Internet address also works -
> there doesn't seem to be a pattern!
>
> Note that I'm using a port of 1053 only while I'm testing.
>
> While I'm sure I couls point all resolvers at 192.168.1.1 as a
> workaround, the fact that I can't figure this out means I'm missing
> something.  I'd rather get to the bottom of this before I continue.
>
> Thanks,
>
> Gareth
>