DNS Setup

[tescophil]

Apologies in advance for this post, but I'm getting tired of explaining the same thing again and again, and it being ignored again and again...

I understand that you've made your life more difficult by using PiHole. That's not the issue here.

I'm not using PiHole, the issue is you trying to second guess my motivations and constantly dodging the question by providing irillevent tangential answers on what you 'think' I should be doing.

The issue is a confluence of events, Untangle cannot be authoritative for a domain it doesn't own. No DNS server can, much less limited ones based on DNSMasq. And even if you hack it up until it thinks it is, your devices and every other device on the planet will defer to DuckDNS. Which means, those wildcard names all work.

Another great example of my first point here, this is totally irrelevant to my querstion, and shows you don't understand my config, or my issue

Given your configuration, I no longer feel this is even possible to accomplish. So I'm back to wondering why you care so much about wildcard resolution. If you care that much about that, then you should simply not use DuckDNS, there are other providers.

Again, another example of you not reading what I've already written. I dont want non existant hosts on my network to resolve to my public IP because this looks like DNS hijacking to systems that are looking for it.

From what I can see, if you simply have your forwards working publicly, it works regardless of DNS name used. That's rather the point of wildcard DNS.

Again wrong and irrelevant

But the crux of the issue, is the simple fact that there is no DNS implementation I'm aware of that can pull an IP address off a NIC, and use that in its records. They must be statically defined. Which means you're stuck manually updating that A record with your real public address every time it changes.

Wrong again, in my very first post I setout the man mage for the option that says it does EXACTLY this, which you have again chosen to ignore.

--interface-name=<name>,<interface>[/4|/6]
Return DNS records associating the name with the address(es) of the given interface. This flag specifies an A or AAAA record for the given name in the same way as an /etc/hosts line, except that the address is not constant, but taken from the given interface. The interface may be followed by "/4" or "/6" to specify that only IPv4 or IPv6 addresses of the interface should be used. If the interface is down, not configured or non-existent, an empty record is returned. The matching PTR record is also created, mapping the interface address to the name. More than one name may be associated with an interface address by repeating the flag; in that case the first instance is used for the reverse address-to-name mapping. Note that a name used in --interface-name may not appear in /etc/hosts.

Again, sorry for this, but again I'm not confuesd, or silly, or making things difficult for myself, I'm simply trying to increase the security of my network by preventing a behaviour that looks like DNS hijacking

[tescophil]

Jim,

Thanks for all the info, and I'll see if I can track this down another way. I still think the interface-name directive does exactly what I want, but is probably executing before my WAN interface gets its public IP.

I already use OpenVPN as well BTW.., this is more of an academic exercise to prove what should be possible. The nice thing is using this method, mobile devices can roam on and off the network and still use the secure DNS server I've setup without changing config on the phone / start/stop a VPN connection.

[sky-knight]

Well he's not wrong...

I just stuffed:

interface-name=test.dnsrequest.local,eth0

Into config -> networking -> advanced -> DNS & DHCP

And then when I ran an nslookup against test.dnsrequest.local, I got the primary IP address assigned to ETH0.

I change to eth1, and the internal primary IP address pops up. To be clear, both of those interfaces have two aliases, so it's not grabbing those, it's grabbing the main address for each defined interface. This might mean it's not compatible with PPPoE interfaces...

Presumably the OP did the same thing and it's not resolving? Or... perhaps this feature isn't compatible with the 2nd directive of attempting to localize the queries.

I utterly misinterpreted that directive's functionality, I was assuming that was how DNSMasq chose different ingress interfaces for different lookups. IE, the ability to have it respond contextually. So you can pass out public addresses to the public, and private ones to private queries. That's not the case.

Anyway, is this WAN PPPoE? If so, ssh into Untangle and do an ifconfig, you need to use the PPPoE interface name flag, not the eth one, that might clear it up.

[Jim.Alles]

Thanks for all the info, and I'll see if I can track this down another way. I still think the interface-name directive does exactly what I want, but is probably executing before my WAN interface gets its public IP.

What version of NGFW are you running?

FYI, v15.1 is running version 2.80 dnsmasq.

/var/log/daemon.log:Aug 10 11:11:33 untangle-u25xw dnsmasq[83273]: started, version 2.80 cachesize 3000

I believe v15.0 had 2.76, and something was fixed in 2.77 dnsmasq:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2017q1/011201.html

Simon says, and I quote:

I looked at this, and the man page LIES. --interface-name returns all
the addresses associated with an interface.

Question: is openWRT associating the same name with more than one
interface (which would be the only way that localise-queries would
make sense, if you believed the man page.)

ie

interface-name=myrouter,eth0
interface-name=myrouter,eth1
localise-queries

and expecting to get the address of eth0 or eth1, depending on where
the query was sent to.

If it is, then it's probably working by accident, but I have to make
sure that doesn't break;

Cheers,

Simon.

...I don't think he 'fixed' the man page.

[sky-knight]

Yes, that's another fair thing, I was testing on UT v15.1. Older releases will have older DNSMasqs which have all sorts of wonderfully fun annoying little niggly things wrong with them. Like DHCP Relays... yuck don't even try!

[Jim.Alles]

You will need to understand what is going on in your logs at /var/log/syslog

And I just came to the understanding that dnmasq deposits log entries in more than one place.

Use this

grep -ir --exclude-dir=dist-upgrade dnsmasq /var/log/

From:
https://www.linux.com/topic/networking/advanced-dnsmasq-tips-and-tricks/

[Jim.Alles]

Yes, that's another fair thing, I was testing on UT v15.1. Older releases will have older DNSMasqs which have all sorts of wonderfully fun annoying little niggly things wrong with them. Like DHCP Relays... yuck don't even try!

Debian 10 (Buster) is such a relief!

Thanks, Untangle!

[tescophil]

Anyway, is this WAN PPPoE? If so, ssh into Untangle and do an ifconfig, you need to use the PPPoE interface name flag, not the eth one, that might clear it up.

Genius, that was it

interface-name=myhouse.duckdns.org,ppp0
local=/myhouse.duckdns.org/

This now works as expected, the base DNS name returns the public IP on ppp0 (WAN PPPoE / eth1), and unknown hosts on this domain are not forwarded to upstream servers, hurray !

Apologies again for venting in a previous post (just getting frustrated..), and thank you.

[sky-knight]

Score!

And don't worry about venting on me, I don't have any right to be upset given my history around here. But I'm also an engineer constantly trying to work out the impossible. Trust me, I know how that process works. Innovation isn't comfortable, especially when you're so close to the finish line you can taste it!

I'm just glad it's working, even if it's working in a way that makes my head hurt a bit. But, that's probably just the usual annoyances that come from mixing multiple security products.

[Jim.Alles]

...I don't think he 'fixed' the man page.

I was wrong, Simon Kelley did fix the man page.
version 2.77 changelog:

Fix the manpage which lied that only the primary address of an interface is used by --interface-name.

sorry if any confusion!