Bind Configuration

[Keith Smith]

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 at lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss

-- 
Keith Smith