back to

asdfsadf Edit

UPLINK GATEWAY NODE GETS A DHCP lease from D-LINK router: We are new to mesh technology, but we experienced DNS problems with the first node we installed. The uplink gateway node was getting a DHCP lease from a D-Link router. Internet browsing would work for just a couple minutes, and then we could no longer resolve domain names (entering IP addresses would work fine).We removed the D-Link router and replaced with a Cisco Pix firewall and it seems to be working fine (not 100% sure since this is a pilot site and no one is really using it yet).

DNS issues Edit

QUES: OK, I think the problem maybe that every node (gateway or not) is set

{{{ (G) Gateway use DHCP dns: Yes (D) Daisy chain gateway's dns: Yes Just so that I'm really clear The Gateway node(s) should be set Gateway use DHCP dns: Yes Daisy chain gateway's dns: No and a normal node set to Gateway use DHCP dns: No Daisy chain gateway's dns: Yes }}} Is that correct? before I change anything.... I've been looking at the resolv.conf on each node in there current set up and all seems well, the gw is using the dns handed out by the dhcp and the nodes are using either the other end of their vpn tunnel (which I think is the gateway by doning a ifconfig on the gw) or BUT when i do a ping on a node (not the gw that is OK) to say and sniff the traffic comming out to the gw node it is doing DNS lookups to multiple dns servers none of which are the one the GateWayNotes is using. I've not gone as far (yet!) as looking in the dns packet to see what it is looking up.

1. Enable Daisy Chain DNS if you want your downstream nodes to use the gateway node's dns and set Gateway Use DHCP dns if you want your gateway to always use the dns handed out by the DhCp server.
1. Of course if the dns server handed out by the DhCp server is incorrect or fails then it will bring down your entire mesh.

QUES: I would like my Gateway nodes to use only certain DNS servers (ones I control). the gateway node is getting the correct settings from my DHCP server and I can confirm this in the /etc/resolve.conf on the node. When I use the mesh though the DNS must be being got from other DNS servers, on sniffing the ethernet connection on the gateway node I can confirm that it is using other servers as well as the one I want it to use. I could block DNS lookups out to the internet but this just should not beneeded if the settings were being used and I've not tested it in case it stops the Mesh working... Network attacks via DNS /. article

This is an interesting issue, I believe many corporates and ISP's >use a combination of DNS proxy's and >and packet filtering to ensure the content of DNS packets are what >they should be. >The following link contains some information. > >I would think it possible to implement something similar within the >Mesh by replacing the caching name servers >on each meshbox , using DNS passthrough and applying the correct filter rules. >Not a small undertaking though ... but a possible solution.

Unfortunately, I don't believe that this will make any difference. The point of the article is that the queries are genuine DNS queries. They will go through proxies. As far as I can see, the only way to deal with this is to refuse to allow systems to issue a DNS query unless they have been authenticated. This is what the meshboxes do if you are trying to use a DNS server other than the meshbox.

However, a complete ban reduces usability, as people won't see the splash screen if a DNS lookup fails (the browsers will issue the DNS failed screen instead). The way around this would be to issue the initial request as an IP address, but this requires more skill on the part of the user.

Perhaps one solution would be for pre-authentication requests to resolve to the IP address of the meshbox without doing any DNS lookup at all. A request on any name will be returned with the IP address of the meshbox without any DNS query. This would at least deal with the exploit until authentication has happened.

* If there is no way to do a DNS lookup, then there is no way to tunnel in the packets.