Hi Austin,

Bind and mail are new to me.  I can do the LAMP part.  I've looked at webmin and would like to stay away from it.  I think webmin is a great resource, however I really want to do this from the command line.

Between the docs, Google, YouTube, and you guys so graciously helping me, I should be able to learn this at the command line.

Thank!
Keith


On 2014-12-08 12:09, JD Austin wrote:

If all of this is new to you install webmin (but don't allow it
outside of your firewall):http://www.webmin.com/ [1]

-- JD Austin
Voice: 480.269.4335 (480 2MY Geek)
jd@twingeckos.com

On Mon, Dec 8, 2014 at 10:11 AM, Keith Smith
<techlists@phpcoderusa.com> wrote:

Sorry guys.  I should have given more info.

I'm a LAMP developer.  I am increasingly doing more sys admin
stuff.  I home office.  I have a Cox business account that allows
me to run a server.  I bought a Dell i5 / 8GB RAM for this
project.  I have never configured BIND or any email server. It is
my goal to do so.  One LAMP+Dind+Mail server in my home office.

I installed CentOS 7 on the Dell and am hoping to use this project
to learn how to mange a server from top to bottom. I have no problem
configuring a LAMP server.  It is Bind and
Postfix+Dovecott+Spamassassin+MySql that I need help with.

I figure by running my own server I will learn a lot and round out
my skills.

So that is my project......

Thank you so much for your help!!  I'm sure I will have lots of
questions along the way.

Keith

On 2014-12-08 10:40, der.hans wrote:

Am 08. Dez, 2014 schwätzte Michael Butash so:

moin moin,

On 12/07/2014 10:42 PM, der.hans wrote:
Am 07. Dez, 2014 schwätzte Michael Butash so:

You'll want to allow tcp/53 if doing any sort of public dns -
anything greater than 1500 bytes (ie most domain-keys//spf records),
and also any

True, if you're doing those things, you might have large dns
payloads and
need tcp. If you think they cause problems rather than fixing them,
then
...

 "Normal" use of these yes, but imho better just to leave it be
serviced anyways, especially if any sort of provider for others.

 Yeah, I suppose I pre-optimized and presumed this would be home, non
3rd
 party use for Keith.

anomaly mitigation gear (the things that keep 400gb DDoS at bay)
use that to

What would anomaly mitigation gear be doing to cause large dns
payloads?
That's a serious question as I don't even know what anomaly
mitigation
gear is.

 It's not a large payload issue, it's a method of them validating who
is a script opening a raw udp socket to spew junk, etc vs. a "real"
RFC-compliant client by sending that truncate bit back to the client,
making them request via tcp, and thus doing something more than legit
aiming a cannon.

 Hmm, this isn't making sense to me. Are you saying a client makes a
 request to your dns service and you force the client over to tcp
lookups?
 If so, does that cause the rest of the recursive lookup to other
servers
 to be tcp as well?

Having worked for one of those large hosting companies that gets
those 300gb ddos attacks you read about (not to mention being
responsible for dealing with them), you need something to do
mitigate botnet blasts automagically,

 Most of our protocols could use some updates.

and luckily some smart people figure out protocol challenge
behavioral hacks to do that.  I remember back in 2003 needing to
open firewalls to allow tcp for our dns just for that alone when
ddos became vogue among warring customers, but became more common at
various other businesses to have to address allowing tcp as well for
spf and others.

It also broke some remote providers that blocked tcp/53 as well for
some reason when our devices couldn't "validate" them, adding them
to a drop list vs. whitelisting them as "valid" clients.

 Did those remote providers block tcp/53 for client or just for server
(
 only incoming syn blocks )?

Not that big a deal running a server at your house, and never using
dkim/spf. I think most default cisco asa firewall configs still
filter udp dns protocol traffic by default over 512 too.

figure our if you're real or not. Blocking tcp for dns is not a
good idea as a whole, it's just RFC-compliant behavior things
expect.

As I recall, the RFC only specifies tcp for large payloads. Don't
allow
them and tcp isn't necessary.

 Less is more I suppose when talking firewalls, just know when you
*do* need things like tcp-based dns.

 Yeah, good thing for Keith that you're pointing out that a service
 provider probably has to leave tcp/53 exposed, especially when using
newer
 dns record 'features'.

 ciao,

 der.hans
 ---------------------------------------------------
 PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
 To subscribe, unsubscribe, or to change your mail settings:
 http://lists.phxlinux.org/mailman/listinfo/plug-discuss [2]

 --
 Keith Smith

 ---------------------------------------------------
 PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
 To subscribe, unsubscribe, or to change your mail settings:
 http://lists.phxlinux.org/mailman/listinfo/plug-discuss [2]


Links:
------
[1] http://www.webmin.com/
[2] http://lists.phxlinux.org/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss