and perhaps there is more I should know about? Clearly the last two are my ISPs nameservers. Now I’d like in a script to change these. But guess what? I did, and nothing seems to change. Still seem to be using those two namesevers.
So I restart the resolver:
# /etc/init.d/resolver restart
Same deal. Nothing seems to change.
Now I’m light on diagnostic skills here alas. The test I use is the two nameservers I want to use resolve some more names (they are on a VPN) than my ISP does.
I guess one thing I’m after is some angle on diagnostics, tracing the comms here. If I do an nslookup I get scant details back. I want a log from kresd I guess, letting me know it got a request and the steps it’s taking to resolv it. Such a thing available?
Previously i gave a temporarily solution, but i was noticed that it was a very dangerous solution. Now i have just copied the resolv.conf to a different place and i guess you can even put it in your homefolder.
Then in the /etc/config/dhcp under dnsmasq, put a addition line referring to the resolv.conf file you want it to use. I gave a reboot and everything is still working fine. In my case i put it on my m.SATA partition.
config dnsmasq
option domainneeded '1'
option boguspriv '1'
option localise_queries '1'
option rebind_protection '1'
option rebind_localhost '1'
option local '/lan/'
option domain 'lan'
option expandhosts '1'
option authoritative '1'
option readethers '1'
option leasefile '/tmp/dhcp.leases'
option localservice '1'
option nonwildcard '0'
option port '0'
list server '8.8.8.8'
list server '8.8.4.4'
option logqueries '1'
option resolvfile '/mnt/LXC/backup/resolv.conf'
@Bernd_Wechner If you want to escape your ISP’s DNS severs you would need to put
option peerdns '0'
into the PPPoE Interface (/etc/config/network), or else through LuCI. Otherwise DNS will be always queried through the ISP and not by the Knot resolver. And as @vcunat pointed out you can set upstream DNS servers in the Knot resolver configuration.
Yet you are mentioning VPN and script and perhpas you are more after hotplug scripts for VPN usage, which is not quite clear from the initial post, neither what your script looks like and how it is deployed.
nslookup is know of not working in OpenWRT (and subsequent TO).
You can use dig at the cli to lookup DNS records, or install drill, and it will show whether your local resolver (127.0.0.1) is being utilized or something else.
Not escape so much. Apologies for modest context provision. But yet, a a hotplug is in the right direction though I don’t mind manually invoking a script. I may be barking up the wrong tree here anyhow as it happens. What I was hoping is to fix the following use case:
My Omnia acts as DNS for my LAN devices.
It resolves local names well, and consults the configured WAN DNSs for all other names
This is a beautiful scenario BTW. It means we have a great LAN in which local names are all resolved (either with .lan as TLD or lacking a TLD).
When I connect to VPN (using vpnc as it happens) it inserts the VPN DNSs into /etc/resolve.conf above the Omnia. The effect of which is I no longer get LAN names resolved.
My hope was to remove those DNSs from there (easy with small bash script) and instead ask the Omnia to consult the VPN DNSs rather than my ISP DNSs.
The intent here was that the VPN DNSs like the Omnia also resolve VPN names cleanly and then defer to a WAN DNS. To wit this desire with a script to make a config change on the Omnia that changes the DNSs (which could indeed be run manually on a hotplug when the VPNS goes up).
Conversely when the VPN goes down, to swap these back.
The problem I see in the interim is that the Omnia is not on the VPN in this scenario (I could work on that as a strategy but for now the intent was one local device gets on the VPN) and so the VPN DNs are not visible to it (not visible from the WAN), certainly not with the IPs that vpncs gets when it connects as they are LAN reserved (192.168.1.)
So perhaps I have a broader (and different) problem still. Which may be worth another thread on a different forum, which is how to configure a Linux box so it consults the Omnia first, then the VPN and then the WAN DNS … in a kind of cascade of consults until a resolution is found. That way when the VPN is up I’d get goo name resolution on the local LAN, the VPN and the WAN. It may be a pipe dream ;-).
VPNC is indicating that the TO is a client connecting to a Cisco/ASA/Juniper VPN device. From the response it sounds like you are looking for something like split DNS
Yep it’s a Cisco VPN, but I have no control over its config alas. The Split DNS system looks to need some configs on the VPN providers side. What I’d need is a solution on an Ubuntu based desktop machine, that does split DNS (referring local names to my DNS and the rest to the VPN DNS (it in turn does same from its perspective already))
Sounds like a corporate VPN remote server. In which case they commonly mandate/push the corporate DNS for/to the VPN clients - usually for security purpose and/or to resolve hostnames in the corporate network.
Logically the corporate remote DNS would not resolve any hostname/DNS record in your local network since it would not be aware of any local hostname/DNS record.
Not sure whether the VPNC interface (I am not familiar with it) on the TO offers any option to utilize dnsmasq (or Knot resolver) for resolving your local network, or set DNS A/CNAME records for the local network.
As for the particular Ubuntu machine it should be feasible to overrride the corportate DNS resolver via the respective machine settings - perhaps this helps to get started.
I’ll look into dnsmasq (or knot whichever is easier). I can override it easily. I just edit /etc/resolv.conf. The problem is I cna’t get a split this way. I either refer DNS requests to the Omnia or to the VPN DNS, and I’m either getting my LAN names resolved or the VPN names, not both.
dnsmaqs/knot resolver on the TO are superseded by the corporate DNS (when connnected).
Like you stated it is either or, both simultaniously is not feasible imho/afaik, unless implemented in the remote VPN server - over which you do not yield control.
You mentioned that it concerns only one Ubuntu desktop machines. That is where you should change the DNS settings, if that machine has no role in the VPN.
I need to learn more here. Somehow my local box decides where to go to resolve names … and empirically that seems to be /etc/resolve.conf.
If I edit that I can impact which DNS is used and what names are resolved. Tried it. Works fine.
To wit if that file pointed at 127.0.0.1 (loopback) and I have knot running it could do the split in the way it seems to be doing on the Omnia (it currently receives a DNS request and if it resolve son the local LAN returns that IP and if not passes it on to WAN DNS servers).
So conceptually it would seem possible, but non-trivial at this point! Still if I used knot, gaining knot skills helps me with my router/gateway too (I like consistency). And I know a little about knot, not much, but a little ;-).
For .lan the resolver can see if a name belongs to the list and decide easily. With VPN I generally can’t see how it can locally decide whether a name belongs to the remote part of VPN or is from public DNS. If the VPN names are nested in some specific DNS subtree, that’s easy.
Well, one alternative is to install Knot Resolver on your machine (the VPN client) and configure forwarding in way which sends lan. suffix to local Omnia and everything else to corporate DNS.
The config would look like this:
policy.add(policy.suffix(policy.FORWARD('192.168.1.1<local Omnia IP address>'), {todname('lan')}))
policy.add(policy.all(policy.FORWARD('10.0.0.1<corporate DNS IP address>')))