I don't know how your OS does it or what you need to do to use it, but if
I have a file called HOSTS in my (c:\winnt\system32\drivers\etc\ directory
(each OS has a similar location for this file)) that contains a list of
hostname - IP address pairs then whenever I attempt to do a hostname
resolution, my IP stack will use that file *first* before attempting to
contact a DNS server. If it finds the hostname in the HOSTS file then it
never calls a DNS server.
I am suggesting that you populate a hosts file suitable to resolve the
hostnames to ip addresses for your user base. That way you should be able
to remove --skip-name-resolve (allowing MySQL to do hostname-based
security) and not run into the issue of a DNS server becoming flaky unless
someone with a hostname NOT in the list tries to login.
However, if your users are always getting new IP addresses (some places
are like that) then this workaround won't work for you. It may not work at
all but I thought it was worth a shot.
Shawn Green
Database Administrator
Unimin Corporation - Spruce Pine
Tuc at T-B-O-H <ml@stripped> wrote on 09/01/2005 11:24:24 AM:
> Hi,
>
> (Lets not get into top/bottom/mixed post discussions. :) )
>
> I'm not sure why putting in hosts would make a difference.
> Doesn't the --skip-name-resolve bypass any sort of name resolution,
> be it /etc/hosts or resolver? Or are you telling me to change
> nsswitch.conf from "hosts: files dns" to just "hosts: files"?
> Would be a SLIM possibility, if this wasn't a machine that didn't
> only do MySQL and other things in my TCPWrappers (/etc/hosts.allow)
> did partial domain matching for clients.
>
> Thanks, Tuc
> >
> >
> > (please, either top-post or bottom-post but don't mix it up)
> >
> > One way to bypass a broken DNS server is to create complete HOSTS
files on
> > your servers. That way you can keep using your hostnames but avoid the
> > problems of actual DNS server negotiations going sour as all hostname
to
> > IP address translations are handled locally. This is especially useful
for
> > resolving internal names for resources that rarely change addresses
(like
> > servers and most users). Then, the only names that pose a risk would
be
> > those not on the list.
> >
> > It's not a perfect solution but it may keep you going until MySQL can
> > figure out something better to deal with misbehaving DNS servers.
> >
> > Shawn Green
> > Database Administrator
> > Unimin Corporation - Spruce Pine
> >
> > Tuc at T-B-O-H <ml@stripped> wrote on 09/01/2005 10:56:24 AM:
> >
> > > >
> > > > Hello.
> > > >
> > > > Have a look here:
> > > > http://dev.mysql.com/doc/mysql/en/dns.html
> > > >
> > > > You may want to start mysqld with the --skip-name-resolve option.
> > > >
> > > Hi,
> > >
> > >
> > > Thanks for the reply. I did see that page before, but
> > > I guess my bigger question is why if the DNS is broken/slow, why
> > > does the entire server come to a COMPLETE halt, no commands can
> > > be done via either TCP *OR* the socket. If it just errored, that
> > > session took forever, whatever... I could understand. The problem
> > > is that when it gets probed, it COMPLETELY offlines (DOS) the
server.
> > > And just *1* connection!
> > >
> > > Just also seems difficult to keep proper documentation if
> > > we are using IPs and not complete hostnames.
> > >
> > >
> > > Thanks, Tuc
> > > >
> > > > Tuc at T-B-O-H <ml@stripped> wrote:
> > > > > Hi,
> > > > >
> > > > > We seem to be running into a problem with our
> > > > > installation that we don't understand.
> > > > >
> > > > > We are running "mysql-server-4.0.25" from
> > > > > the ports collection on a FreeBSD 5.3-RELEASE-p10
> > > > > machine. Its tcpwrapper'd to only allow from our
> > > > > /24, and a single machine outside the /24.
> > > > >
> > > > > At times, all of a sudden the server seems
> > > > > to "freeze". It appears that we've narrowed it down
> > > > > to an issue with people attacking the server that
> > > > > come from a site that has a bad reverse DNS setup.
> > > > >
> > > > > Has anyone else seen this, or knows how
> > > > > to stop it?
> > > > >
> > > > > Thanks, Tuc
>
