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

--
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