DNS server support for local name resolution

[tc143]

Hi,

I did a bit of testing last night with regard to n66u name resolution features. It appears that although Dnsmasq is implemented, it does not provide DNS name resolution for local clients that receive a DHCP allocated address i.e., the router does not function as a DNS server.

According to my read of the Dnsmasq wiki, DNS server function is included.
http://en.wikipedia.org/wiki/Dnsmasq

"It can serve the names of local machines which are not in the global DNS. The DHCP server integrates with the DNS server and allows machines with DHCP-allocated addresses to appear in the DNS with names configured either in each host or in a central configuration file."

If I have interpreted this correctly, is there some way of including or accessing the DNS server capabilities in Dnsmasq on the router?

Regards,
tc143

 

[RMerlin]

Hi,

I did a bit of testing last night with regard to n66u name resolution features. It appears that although Dnsmasq is implemented, it does not provide DNS name resolution for local clients that receive a DHCP allocated address i.e., the router does not function as a DNS server.

According to my read of the Dnsmasq wiki, DNS server function is included.
http://en.wikipedia.org/wiki/Dnsmasq

"It can serve the names of local machines which are not in the global DNS. The DHCP server integrates with the DNS server and allows machines with DHCP-allocated addresses to appear in the DNS with names configured either in each host or in a central configuration file."

If I have interpreted this correctly, is there some way of including or accessing the DNS server capabilities in Dnsmasq on the router?

Regards,
tc143

It does provide resolution for local devices. Works fine here:

C:\Users\Merlin>nslookup - 192.168.10.1
Default Server:  www.asusnetwork.net
Address:  192.168.10.1

> camelot
Server:  www.asusnetwork.net
Address:  192.168.10.1

Name:    camelot.lostrealm.lan
Address:  192.168.10.100

> 192.168.10.100
Server:  www.asusnetwork.net
Address:  192.168.10.1

Name:    camelot.lostrealm.lan
Address:  192.168.10.100

 

[tc143]

Must be misconfiguration on my end. I will retest tonight.

 

[tc143]

I'm unable to find the misconfiguration, but I noticed in syslog that the file /etc/hosts.dnsmasq does not exist.

This router is only few days old and has never been connected to wan (wan set to disabled in webui) if that is relevant. It's running 270.26b. Below is some data from my test. The odd looking stuff is bolded.

syslog

Dec 31 19:00:11 dnsmasq[499]: started, version 2.65 cachesize 1500
Dec 31 19:00:11 dnsmasq[499]: compile time options: IPv6 GNU-getopt no-RTC no-DBus no-i18n no-

IDN DHCP DHCPv6 no-Lua TFTP no-conntrack
Dec 31 19:00:11 dnsmasq[499]: asynchronous logging enabled, queue limit is 5 messages
Dec 31 19:00:11 dnsmasq-dhcp[499]: DHCP, IP range 192.168.1.2 -- 192.168.1.254, lease time 1d
Dec 31 19:00:11 dnsmasq[499]: read /etc/hosts - 3 addresses
Dec 31 19:00:11 dnsmasq[499]: failed to load names from /etc/hosts.dnsmasq: No such file or directory

etc/hosts

127.0.0.1 localhost.localdomain localhost
192.168.1.1 www.asusnetwork.net
192.168.1.1 RT-N66U.home.local RT-N66U

nslookup

Default Server: 1.1.168.192.in-addr.arpa
Address: 192.168.1.1

> lt6
Server: 1.1.168.192.in-addr.arpa
Address: 192.168.1.1

Name: lt6.home.local
Addresses: 10.0.0.1
10.0.0.1

ipconfig

Windows IP Configuration

Host Name . . . . . . . . . . . . : LT6
Primary Dns Suffix . . . . . . . : home.local
Node Type . . . . . . . . . . . . : Broadcast
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : home.local

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Physical Address. . . . . . . . . : xx-xx-xx-xx-xx-xx
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : xxxx::xxxx:xxxx:xxxx:xxxxxxx(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.83(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Tuesday, March 26, 2013 3:24:34 PM
Lease Expires . . . . . . . . . . : Wednesday, March 27, 2013 3:24:34 PM
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DHCPv6 IAID . . . . . . . . . . . : 300961186
DHCPv6 Client DUID. . . . . . . . : xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx

DNS Servers . . . . . . . . . . . : 192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Disabled

 

[RMerlin]

It's possible that dnsmasq isn't working as expected if you aren't using the router's WAN capabilities.

Also, where is that 10.0.0.0 subnet coming from? Do you have either multiple DHCP servers, or static IPs from a different subnet on your LAN?

Might help if you described your LAN topology a bit more. I assume you have a non-typical network setup since your router's WAN is disabled, for instance.

 

[tc143]

Existing LAN uses 10.x.x.x. and hosts DHCP/DNS, file server, etc. Its a small LAN with no subnets.

Testing for the n66u is being done on an isolated switch so I'm not sure where the 10.0.0.1 address is coming from in the n66u, unless it was from some early tinkering . That address happens to be the default gateway address for our LAN.

The routers WAN interface is disabled because I do not have a separate WAN link to test on, and I'm hesitant to test it on our production link since I'm not sure how our ISP (Comcast) handles toggling between different routers/firewalls connected to cable modem.

I would think that WAN link state should not be affecting dnsmasq since WAN link being down is something that happens from time to time due to issues at ISP. But possibly, dnsmasq needs to have a WAN link at some point to complete some type of initialization.

In any case, it might be useful for me to first reset the router to defaults in order to rule out a misconfiguration issue, then retest without WAN link, then if same results (no local dns), I'll figure out a way to hook it up to WAN link.

Is there a command to reset the router to defaults?

 

[tc143]

Update: local dns is working now. I set a bogus static ip for the wan link and then enabled it. Its not actually connected but it seems that the wan address fields need to be populated for dnsmasq to function properly.

Still would like to know what command resets router to defaults.

regards,
tc143

 

[RMerlin]

Update: local dns is working now. I set a bogus static ip for the wan link and then enabled it. Its not actually connected but it seems that the wan address fields need to be populated for dnsmasq to function properly.

Still would like to know what command resets router to defaults.

regards,
tc143

There are multiple ways to do so. See the FAQ on the Wiki.

 

[tc143]

After resetting to defaults, configuring for my environment, then connecting to my cable modem I can report success I can also swap between the n66u and my ISA firewall without problems. The cable modem must be powered down before swapping.

However, the issue where local DNS does not function if the WAN link is down is still present. I tested three cases: (1) pulling the cable, (2) disabling in the webui and (3) powering off the cable modem. In each case, nslookup showed the following:

Default Server: 1.1.168.192.in-addr.arpa
Address: 192.168.1.1

instead of:

Default Server: www.asusnetwork.net
Address: 192.168.10.1

I don't think the WAN link state should be affecting local DNS...

Can anyone repro this?

 

[kaiguy]

I could be wrong on whether or not this would help, but there is a dnsmasq option which may help with this.

From http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html :

-b, --bogus-priv
Bogus private reverse lookups. All reverse lookups for private IP ranges (ie 192.168.x.x, etc) which are not found in /etc/hosts or the DHCP leases file are answered with "no such domain" rather than being forwarded upstream.

This setting is not enabled by default in the Asus or Merlin configs, but is in other router firmwares (like OpenWRT, for example).

 

[Nerre]

However, the issue where local DNS does not function if the WAN link is down is still present. I tested three cases: (1) pulling the cable, (2) disabling in the webui and (3) powering off the cable modem. In each case, nslookup showed the following:

I've commented on this before.

http://forums.smallnetbuilder.com/showthread.php?t=8548

It's a real pain that when WAN goes down dnsmasq stops working as it should.. Which means my diskless MythTV frontends won't be able to PXE-boot

 

[tc143]

Very interesting.

I would think that this issue is the result of a bug, not in dnsmasq itself, but in how it is implemented in the router firmware.

Dnsmasq should definitely continue to answer DNS queries for DHCP configured hosts and for hosts in the /etc/hosts file regardless of the state of the WAN interface.

@RMerlin, would you be able to look into this and see if there is a way to keep the DNS working?

 

[RMerlin]

Very interesting.

I would think that this issue is the result of a bug, not in dnsmasq itself, but in how it is implemented in the router firmware.

Dnsmasq should definitely continue to answer DNS queries for DHCP configured hosts and for hosts in the /etc/hosts file regardless of the state of the WAN interface.

@RMerlin, would you be able to look into this and see if there is a way to keep the DNS working?

Don't have time right now since 354 is the priority, but I can take a look at it later. Might be possible that, since dnsmasq acts as a DNS relay, it might have trouble answering even local requests if it no longer has access to a remote DNS to handle forwarded requests.

 

[Nerre]

I think it might be that when WAN goes down dnsmasq gets reconfigured to direct external requests (like a captive portal) to a web page on the router stating that WAN is down (however that page does not seem to exist).

 

[RMerlin]

I think it might be that when WAN goes down dnsmasq gets reconfigured to direct external requests (like a captive portal) to a web page on the router stating that WAN is down (however that page does not seem to exist).

That's also possible - would be part of the QiS Wizard interception feature.

I'll take a look at it when I get some time.

 

[tc143]

Very interesting.

I would think that this issue is the result of a bug, not in dnsmasq itself, but in how it is implemented in the router firmware.

Dnsmasq should definitely continue to answer DNS queries for DHCP configured hosts and for hosts in the /etc/hosts file regardless of the state of the WAN interface.

@RMerlin, would you be able to look into this and see if there is a way to keep the DNS working?

Don't have time right now since 354 is the priority, but I can take a look at it later. Might be possible that, since dnsmasq acts as a DNS relay, it might have trouble answering even local requests if it no longer has access to a remote DNS to handle forwarded requests.

Great thanks

btw, just to keep this tip from an earlier post visible, a workaround that keeps DNS going when the WAN link is down is to simply configure the WAN interface with a bogus static IP address.

 

[RMerlin]

Great thanks

btw, just to keep this tip from an earlier post visible, a workaround that keeps DNS going when the WAN link is down is to simply configure the WAN interface with a bogus static IP address.

The problem is caused by Asus's web redirection feature. When there is no working WAN, the router will redirect all http connections to a mini web server, and all DNS lookups to a mini DNS server, which always returns 10.0.0.1 for all queries.

I suspect the DNS redirection is overkill if the goal is only to allow someone to type any random URL and be redirected to either the QIS wizard or to an error page if there is no WAN connection. I'll try limiting the redirection to only port 80 connections and see if web redirection still works.

 

[RMerlin]

Fixed. I no longer redirect all DNS queries to the mini DNS server when the router is in web redirection mode, but instead I reconfigure dnsmasq so any unresolvable queries (i.e. any non-local query) will return the same IP as the mini DNS server would return. This means we can now resolve local queries, but still get redirected to the router's error page when trying to access a website with the WAN interface down.

 

[tc143]

Ah, that explains where the 10.0.0.1 address was coming from. It had me scratching my head while testing the router on an isolated LAN since my business LAN uses 10.0.0 address space. I was thinking it might be some sort of weird client IP address issue...

This fix (+ others) will be incorporated into a ..270.27 release or something like that?

 

[RMerlin]

Ah, that explains where the 10.0.0.1 address was coming from. It had me scratching my head while testing the router on an isolated LAN since my business LAN uses 10.0.0 address space. I was thinking it might be some sort of weird client IP address issue...

This fix (+ others) will be incorporated into a ..270.27 release or something like that?

Next release. Will be a 354.xxx one, undecided yet if there will be a second 354.27 beta, or I'll jump to 354.28 beta (since I ended up implementing quite a few additional changes while waiting for a driver update - those are beyond what I had planned for 354.27).