[Dnsmasq-discuss] DNS - preventing escalation to external

[fred at damen.org]

My feeble understanding is that dnsmasq does not evaluate the validity,
i.e., accessibility of the host, of the DNS name mapping in the /etc/hosts file,
and these mapping will always be resolved.  dnsmasq resolves the --dhcp-host
mappings based upon the validity of the mapping, i.e., existence of a DHCP
lease.  So, a not so elegant solution is to keep dual copies of the permanent
assignment in both /etc/hosts and dnsmasq.

In the past I have looked for, but did not find, a parameter to set to tell
dnsmasq to revolve --dhcp-host MAC/IP assignment irregardless of a current
DHCP lease.  Does this exist?

Hope this helps,

Fred

On Wed, December 5, 2012 8:42 am, Lovelady, Dennis E. wrote:
> 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>_______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>