Regarding your DNS issue - I've seen this before and it's a configuration issue (usually on the client side). Unfortunately it was a long time ago and I can't remember the specifics. One clue is that using "mackbook." forces a lookup on the DNS server (the Asus). Using a short name "mackbook", particularly on Windows clients, can use different resolution priorities like NetBIOS or appending local DNS suffixes.
Expanding a bit more on this...
With your default setup the domain was not defined and is in effect a null string. Hence "macbook." is a FQDN.
Also, because the domain was not defined, this "null" domain is not "pushed out" to the DHCP clients. This in itself
shouldn't be a problem.
What
will be a problem is if any of the clients are already configured as members of a domain (other than the "null" domain). This "other" domain will be appended to your short name lookups (macbook -> macbook.otherdomain.com) and will result in the error you are seeing.
So on Windows clients do an "ipconfig /all" and make sure there isn't anything in "Primary Dns Suffix", "DNS Suffix Search List" or "Connection-specific DNS Suffix".
On *nix look in /etc/resolv.conf and make sure it doesn't have a "search" entry.
Good luck.
P.S. You could try John's suggestion of defining a local domain but that does mean putting the RT- back into router mode and repeating the setup procedure from that point

, or manually adding 3 lines to dnsmasq.conf. I don't know whether that will fix your problem, but it does mean that the local domain is "pushed" to the DHCP clients, so that might overwrite any pre-existing domain.
P.P.S. If all else fails you could log all the queries being processed by dnsmasq. That would tell you a) if the query is getting to dnsmasq at all, and b) what the expanded hostname is.
Log onto the RT-N66U and:
killall dnsmasq
dnsmasq --log-async --log-queries=extra
tail -f /tmp/syslog.log