[Dnsmasq-discuss] DNS - preventing escalation to external

Wed Dec 5 14:42:54 GMT 2012

Thanks for bearing with me, Richard.

Maybe we know what’s wrong now (though I still don’t get it entirely, since as I said, the search entry will be generated by the DHCP client.)  But that’s not the point.

So, back to the original question: What can I do to abort this behavior, and stop sending network requests to the wrong room?

From: richardvoigt at gmail.com [mailto:richardvoigt at gmail.com]
Sent: Wednesday, December 05, 2012 9:39 AM
To: Lovelady, Dennis E.
Cc: dnsmasq-discuss at lists.thekelleys.org.uk
Subject: Re: [Dnsmasq-discuss] DNS - preventing escalation to external

It's the "search Z.com" entry getting involved.

I don't believe that dnsmasq ever rewrites /etc/resolv.conf  Other software might, such as your DHCP client.

As far as *.Z.com resolving, there's nothing that requires DNS to be a static table of pre-existing names.  It's a client-server lookup, and the server can use any arbitrary algorithm for generating a response, not limited to a table lookup. Zone transfers wouldn't match, but I guess records could be hidden from zone transfer regardless, or zone transfer could be entirely refused.

On Wed, Dec 5, 2012 at 7:32 AM, Lovelady, Dennis E. <dlovelady1 at dtcc.com<mailto:dlovelady1 at dtcc.com>> wrote:
Thank you, Richard:

Yes, no doubt, /etc/resolv.conf on all these systems contains:

nameserver 192.168.158.2
search Z.com
domain Z.com

So are you suggesting that I remove one of these from those /etc/resolv.conf entries?  Interesting, I hadn’t thought to do that.  But even if I do that, won’t the domain-needed and domain= entries from dnsmasq.conf override that?  (In fact, won’t they cause overwrite of the /etc/resolv.conf file in most cases?)  Or what are you suggesting?

Is it my best bet to remove the domain= and domain-needed entries from dnsmasq.conf?  I hadn’t thought to do that either, but now it seems worth a try…   I’d still like to hear other suggestions, though.  Maybe something I can/should do in my hosted DNS entries?

I would like to understand how a specific name (like myhostess or myhostess.Z.com<http://myhostess.Z.com>) can resolve to a generic name like Z.com.  I thought DNS strictly avoids that; not true?

Thanks,
Dennis

From: richardvoigt at gmail.com<mailto:richardvoigt at gmail.com> [mailto:richardvoigt at gmail.com<mailto:richardvoigt at gmail.com>]
Sent: Tuesday, December 04, 2012 5:11 PM
To: Lovelady, Dennis E.
Cc: dnsmasq-discuss at lists.thekelleys.org.uk<mailto:dnsmasq-discuss at lists.thekelleys.org.uk>
Subject: Re: [Dnsmasq-discuss] DNS - preventing escalation to external

Sounds like a search suffix is getting involved: After failing to find myhostess. your resolver looks for myhostess.X.com<http://myhostess.X.com>. which finds the alias.  /etc/resolv.conf should contain the directives which control search suffix.

On Tue, Dec 4, 2012 at 4:44 PM, Lovelady, Dennis E. <dlovelady1 at dtcc.com<mailto:dlovelady1 at dtcc.com>> wrote:
I run a domain, which I’ll call Z.com.  There are two offices (atl.Z.com<http://atl.Z.com>, tam.Z.com<http://tam.Z.com>).  There is also a www.Z.com<http://www.Z.com> hosted outside these networks, and the Hosting Provider provides an alias to that, known simply as “Z.com.”  All pretty simple.

Since each office is independent, I have kept a simple DNSMASQ configuration, which you can see below.  (There were attempts to set up atl.Z.com<http://atl.Z.com> and tam.Z.com<http://tam.Z.com> in each office’s DNSMASQ configuration, but these were met with difficulties now forgotten.  I think the difficulty was an issue with web server not coming up.  If it’s important to resolution, I will pursue again and report the issues, but let’s get to the heart of the topic.)

Everything works OK until an incorrect hostname (or the name of a host that happens to be down) is referenced in either office.  For example, if I type “ssh myhostess” and there is no “myhostess” on the current network, then the name is magically resolved to the www.Z.com<http://www.Z.com> address, and I get the password prompt from there.  Not what I’d want; I’d prefer the lookup to fail - which would then fail the ssh command - but I don’t see a way to make that happen.

Is there something I can do in this configuration to cause, for example, lists.thekelleys.org.uk<http://lists.thekelleys.org.uk> to be resolved externally, but to keep the Z.com stuff between the walls?  And would this in fact be squared away by pursuing the atl.Z.com<http://atl.Z.com> (etc.) concept?  (I fear that would not resolve this.)  I could remove the alias to simply Z.com, and that might do it, but I’d prefer not to do that, and anyway I’m not sure why it would fix this.

I have the following DNS configuration in each office.  The dhcp-boot is not used at present, so may not be quite up to snuff.

domain-needed

bogus-priv

expand-hosts

domain=Z.com

dhcp-range=192.168.158.10,192.168.158.109,7d

dhcp-host=88:87:17:12:69:4d,canon-8120

dhcp-host=00:23:8b:8a:ad:70,aspire

dhcp-host=00:26:F2:DB:95:0C,stora-0

dhcp-host=C0:3F:0E:BC:43:B9,stora-2

dhcp-host=e0:91:f5:7c:7c:56,stora-3

dhcp-option=option:router,192.168.158.1

dhcp-boot=pxelinux.0

dhcp-boot=aspire-lucid/pxelinux.0

dhcp-match=set:gpxe,175 # gPXE sends a 175 option.

enable-tftp

tftp-root=/home/tftpd

_____________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss at lists.thekelleys.org.uk<mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

_____________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss at lists.thekelleys.org.uk<mailto:Dnsmasq-discuss at lists.thekelleys.org.uk>
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

<BR>_____________________________________________________________
<FONT size=2><BR>
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email
in error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses.  The company
accepts no liability for any damage caused by any virus transmitted
by this email.</FONT>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20121205/ca87d49d/attachment-0001.html>