Re: [dns-operations] DNS Issue

2013-04-26 Thread Dobbins, Roland

On Apr 26, 2013, at 12:27 AM, Warren Kumari wrote:

 I think that in many cases it is not that the named version doesn't support 
 randomization, but rather that they / their firewall group believes that DNS 
 should only be allowed on port 53 (and UDP, natch).

The actual problem being that the DNS servers oughtn't to be behind a firewall 
in the first place.

;

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread WBrown
 From: Dobbins, Roland rdobb...@arbor.net

 The actual problem being that the DNS servers oughtn't to be behind 
 a firewall in the first place.

Can you elaborate on your statement?  I can guess what the reaction around 
here would be if I suggested it.



Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread Joe Abley

On 2013-04-26, at 08:11, wbr...@e1b.org wrote:

 From: Dobbins, Roland rdobb...@arbor.net
 
 The actual problem being that the DNS servers oughtn't to be behind 
 a firewall in the first place.
 
 Can you elaborate on your statement?  I can guess what the reaction around 
 here would be if I suggested it.

This list needs a FAQ. The following is the usual way this conversation pans 
out.

The assumption is that firewall means device that keeps state. This could 
be a firewall, or a NAT, or an in-line DPI device, or something similar. We're 
not talking about stateless packet filters.

A DNS server can process 100,000 qps on only mildly modern iron. With typical 
query patterns, that means something approaching a capacity of 100,000 flows 
per second.

Your steady state query load may be much lower, but DNS servers have a habit of 
attracting flash crowds.

The number of stateful firewalls that can happily handle occasional flows of up 
to 100,000 flows per second two/from individual devices are few. Yours 
probably isn't one of them.


Joe

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread Cihan SUBASI (GARANTI TEKNOLOJI)
Hi,

Also can someone explain why tcp53 should be allowed on the firewalls if dns is 
behind a firewall?

And why auditors do not like tcp53 open to public?



-Original Message-
From: dns-operations-boun...@lists.dns-oarc.net 
[mailto:dns-operations-boun...@lists.dns-oarc.net] On Behalf Of wbr...@e1b.org
Sent: Friday, April 26, 2013 3:11 PM
To: Dobbins, Roland
Cc: dns-operations@lists.dns-oarc.net List; 
dns-operations-boun...@lists.dns-oarc.net
Subject: Re: [dns-operations] DNS Issue

 From: Dobbins, Roland rdobb...@arbor.net

 The actual problem being that the DNS servers oughtn't to be behind a 
 firewall in the first place.

Can you elaborate on your statement?  I can guess what the reaction around here 
would be if I suggested it.



Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


This message and attachments are confidential and intended solely for the 
individual(s) stated in this message. If you received this message although you 
are not the addressee, you are responsible to keep the message confidential. 
The sender has no responsibility for the accuracy or correctness of the 
information in the message and its attachments. Our company shall have no 
liability for any changes or late receiving, loss of integrity and 
confidentiality, viruses and any damages caused in anyway to your computer 
system.  

Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve 
gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza ulasmis olmasi 
halinde mesaj iceriginin gizliligi ve bu gizlilik yukumlulugune uyulmasi 
zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde yer alan 
bilgilerin dogrulugu ve guncelligi konusunda gonderenin ya da sirketimizin 
herhangi bir sorumlulugu bulunmamaktadir. Sirketimiz mesajin ve bilgilerinin 
size degisiklige ugrayarak veya gec ulasmasindan, butunlugunun ve gizliliginin 
korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi 
herhangi bir zarardan sorumlu tutulamaz.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread Phil Regnauld
Joe Abley (jabley) writes:
 
 The number of stateful firewalls that can happily handle occasional flows of 
 up to 100,000 flows per second two/from individual devices are few. Yours 
 probably isn't one of them.

Corollary: whatever device you'll be putting in front of the DNS servers
to protect them probably won't be dealing so well with whatever 
conectivity
you'll have a couple of years down the road. In general, vendors of
attack mitigation equipment rarely advise you about what you'll need
in the future, only what they can sell you now.

Phil

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread Dobbins, Roland

On Apr 26, 2013, at 7:24 PM, Cihan SUBASI (GARANTI TEKNOLOJI) wrote:

 Also can someone explain why tcp53 should be allowed on the firewalls if dns 
 is behind a firewall?

Truncate mode.

 And why auditors do not like tcp53 open to public?

'Security' misinformation spread by firewall vendors since the late 1990s.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread Dobbins, Roland

On Apr 26, 2013, at 7:23 PM, Joe Abley wrote:

 The number of stateful firewalls that can happily handle occasional flows of 
 up to 100,000 flows per second two/from individual devices are few. Yours 
 probably isn't one of them.

I've seen 3mb/sec of spoofed SYN-flood take down a stateful firewall rated at 
20gb/sec - DDoS, deliberate or inadvertent, means that no stateful firewall 
which could practically be constructed now or in the foreseeable future could 
handle this.

What's more, it's unnecessary - since every incoming connection is unsolicited, 
there's no state to inspect in the first place.  Operators should use stateless 
ACLs in hardware-based routers/layer-3 switches to instantiate network access 
policies (I know you know all this, just posting it for the sake of 
completeness).

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread Dobbins, Roland

On Apr 26, 2013, at 7:29 PM, Phil Regnauld wrote:

 In general, vendors of attack mitigation equipment rarely advise you about 
 what you'll need in the future, only what they can sell you now.

+1.

The architecture should be designed for horizontal scalability from the outset.

---
Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com

  Luck is the residue of opportunity and design.

   -- John Milton

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread Warren Kumari

On Apr 26, 2013, at 4:32 AM, Dobbins, Roland rdobb...@arbor.net wrote:

 
 On Apr 26, 2013, at 12:27 AM, Warren Kumari wrote:
 
 I think that in many cases it is not that the named version doesn't support 
 randomization, but rather that they / their firewall group believes that 
 DNS should only be allowed on port 53 (and UDP, natch).
 
 The actual problem being that the DNS servers oughtn't to be behind a 
 firewall in the first place.

Oh, yeah, *fully* agree -- I meant to mention this in my response (actually I 
was just going to cut-n-paste from an earlier rant on the subject) but forgot.

I'd probably s/firewall/firewall, load-balancer or anything else that keeps 
state/ -- I know you already mentioned statefull things further down in the 
thread, but for some reason many folk don't think of load-balancers as keeping 
state[0]...

W
[0]: Yes, yes, I know that you can configure LBs in a non-stateful / DSR mode 
(been there, done that, got the t-shirt), but many folk plug an LB in front of 
their DNS servers in some NAT / stageful manner and then get sad when it falls 
over…



 
 ;
 
 ---
 Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com
 
 Luck is the residue of opportunity and design.
 
  -- John Milton
 
 ___
 dns-operations mailing list
 dns-operations@lists.dns-oarc.net
 https://lists.dns-oarc.net/mailman/listinfo/dns-operations
 dns-jobs mailing list
 https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
 

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can talk 
but choose not to do so in case humans put them to work, possibly in the 
television industry. In fact they can talk. It's just that they talk in 
Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread John Kristoff
On Fri, 26 Apr 2013 12:24:01 +
Cihan SUBASI (GARANTI TEKNOLOJI) cih...@garanti.com.tr wrote:

 Also can someone explain why tcp53 should be allowed on the firewalls
 if dns is behind a firewall?

DNS over TCP is not just for zone transfers.  Many legitimate queries
and answers, will be carried over TCP.  Usually this will occur in one
of two scenarios:

  1. An answer does not fit into single, negotiated, through EDNS0 or
 not, UDP message.

  2. An operator is forcing DNS to switch-over to TCP to mitigate
 spoofed source address queries, usually in response to some sort of
 packet flooding attack.  Some in-line gear has done this in the
 past, but more recently it is being put directly into
 implementations.  See http://redbarn.org/dns/ratelimits for
 details.

IETF RFC 5966 updates 1035 and 1123 to specify that DNS over TCP must
be supported in implementations.  See that document and this generic
sounding talk almost a decade ago for some additional discussion about
why disallowing TCP can be harmful:

  DNS Anomalies and Their Impact on DNS Cache Servers
  
http://www.nanog.org/meetings/nanog32/abstracts.php?pt=NTY4Jm5hbm9nMzI=nm=nanog32

Note, rarely in my experience does a query start with TCP outside of
troubleshooting scenarios, but it is not infeasible and it is not hard
to imagine it being done.

 And why auditors do not like tcp53 open to public?

They may have an outdated, naive view of what should be open and
what shouldn't be?  Show them the above and ask them why.  I'd be
curious what the response is.

John
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread Vernon Schryver
 From: Jared Mauch ja...@puck.nether.net

 Because someone told them the wrong thing and they don't know any
 difference.  Just because they're an auditor doesn't mean they are
 clued.  Simple thing would be to show them a dns query that requires
 tcp, such as:

Would you show anything to a doctor prescribing bloodletting to cure
what ails you or would you quietly leave?  (except for lab work)

Someone who let a financial auditor with equivalent ignorance about
the fundamentals of bookkeeping near the company's books (not to
mention hiring) would fear being fired or indicted as an accessory.
If your boss or boss' boss' boss etc. hired an equivalent to audit
the company books, you'd infer the worst and start looking for a
new job while the banks are still cashing your paychecks.

The same should apply to network security quacks.  Bogus security
audits or auditors might not signal as much about your paychecks as
bogus financial audits, but they do signal coming security disasters
that probably won't help your career.


Vernon Schryverv...@rhyolite.com
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs


Re: [dns-operations] DNS Issue

2013-04-26 Thread Fred Morris
Good timing...

On Fri, 26 Apr 2013, Cihan SUBASI (GARANTI TEKNOLOJI) wrote:
 Also can someone explain why tcp53 should be allowed on the firewalls if dns 
 is behind a firewall?

 And why auditors do not like tcp53 open to public?

See, that's another of the arguments why DNS should *not* be behind the
firewall: topology issues.

If your (recursive/caching) DNS server was outside the firewall, with
appropriate access controls, then port 53 through the firewall needs only
to be open with respect to the servers which you control.

That's not to say that you wouldn't/shouldn't have appropriate traffic
monitoring/etc. in place between the server and the rest of the
internet.

Agree/disagree, but there it is...

--

Fred Morris

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs