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 
(text/plain)