RE: naive question; using bind behind a outbound-only firewall

[linda w]

Hey, I told you it was naive....you're right the firewall is actually
keeping track of DNS queries, apparently, and matching them -- its more
intelligent than I gave it credit for.

So that can't be most of the volume.  Hmmm...I seem to be getting regular 
inbound, BLOCKED, UDP from machines that appear nameservers.  Here's 5
minutes from the firewall log.  Successful DNS queries aren't logged.
hhmmss
000005-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000005-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000005-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000005-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000045-0 <- ns2.nic.uk17/(udp/port:34123)
000051-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000051-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000051-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000051-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000118-0 <- ns2.nic.uk17/(udp/port:34123)
000118-0 <- ns2.nic.uk17/(udp/port:34123)
000118-0 <- ns2.nic.uk17/(udp/port:34123)
000133-0 <- ns2.nic.uk17/(udp/port:34123)
000133-0 <- ns2.nic.uk17/(udp/port:34123)
000133-0 <- ns2.nic.uk17/(udp/port:34123)
000138-0 <- dsl081-234-137.lax1.dsl.speakeasy.net6/(http)
000141-0 <- dsl081-234-137.lax1.dsl.speakeasy.net6/(http)
000151-0 <- ns2.nic.uk17/(udp/port:34123)
000151-0 <- ns2.nic.uk17/(udp/port:34123)
000207-0 <- ns2.nic.uk17/(udp/port:34123)
000207-0 <- ns2.nic.uk17/(udp/port:34123)
000207-0 <- ns2.nic.uk17/(udp/port:34123)
000207-0 <- ns2.nic.uk17/(udp/port:34123)
000243-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000243-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000243-0 <- ns2.nic.uk17/(udp/port:34123)
000243-0 <- ns2.nic.uk17/(udp/port:34123)
000243-0 <- ns2.nic.uk17/(udp/port:34123)
000323-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000323-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000328-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000328-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000328-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000328-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000328-0 <- ns1.nic.uk17/(udp/port:34123)
000328-0 <- ns1.nic.uk17/(udp/port:34123)
000408-0 <- ns1.nic.uk17/(udp/port:34123)
000412-0 <- ns1.nic.uk17/(udp/port:34123)
000412-0 <- ns1.nic.uk17/(udp/port:34123)
000412-0 <- ns1.nic.uk17/(udp/port:34123)
000412-0 <- ns1.nic.uk17/(udp/port:34123)
000412-0 <- ns1.nic.uk17/(udp/port:34123)
000412-0 <- ns1.nic.uk17/(udp/port:34123)
000435-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000435-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000435-0 <- sec-nom.dns.uk.psi.net17/(udp/port:34123)
000445-0 <- ns2.nic.uk17/(udp/port:34123)
000448-0 <- ns1.nic.uk17/(udp/port:34123)
000448-0 <- ns1.nic.uk17/(udp/port:34123)
000448-0 <- ns1.nic.uk17/(udp/port:34123)
000448-0 <- ns1.nic.uk17/(udp/port:34123)
----------------
	Sniffing on the inside's interface shows plenty 2-way DNS traffic:

IP, Src Addr: ishtar.tlo (64.81.58.33), Dst Addr: ns3.packet-pushers.com (63.231.16.93)
UDP, Src Port: 34552 (34552), Dst Port: domain (53)
IP, Src Addr: ns3.packet-pushers.com (63.231.16.93), Dst Addr: ishtar.tlo (64.81.58.33)
UDP, Src Port: domain (53), Dst Port: 34552 (34552)
IP, Src Addr: ishtar.tlo (64.81.58.33), Dst Addr: ns2.hotmail.com (216.200.206.139)
UDP, Src Port: 34552 (34552), Dst Port: domain (53)
IP, Src Addr: ns2.hotmail.com (216.200.206.139), Dst Addr: ishtar.tlo (64.81.58.33)
UDP, Src Port: domain (53), Dst Port: 34552 (34552)
IP, Src Addr: ishtar.tlo (64.81.58.33), Dst Addr: c3.NSTLD.COM (192.26.92.32)
UDP, Src Port: 34552 (34552), Dst Port: domain (53)
IP, Src Addr: c3.NSTLD.COM (192.26.92.32), Dst Addr: ishtar.tlo (64.81.58.33)
UDP, Src Port: domain (53), Dst Port: 34552 (34552)
IP, Src Addr: ishtar.tlo (64.81.58.33), Dst Addr: ns1.uswest.net (204.147.80.5)
UDP, Src Port: 34552 (34552), Dst Port: domain (53)
IP, Src Addr: ishtar.tlo (64.81.58.33), Dst Addr: c3.NSTLD.COM (192.26.92.32)
UDP, Src Port: 34552 (34552), Dst Port: domain (53)
IP, Src Addr: c3.NSTLD.COM (192.26.92.32), Dst Addr: ishtar.tlo (64.81.58.33)
UDP, Src Port: domain (53), Dst Port: 34552 (34552)
IP, Src Addr: ishtar.tlo (64.81.58.33), Dst Addr: ns.above.net (207.126.96.162)
UDP, Src Port: 34552 (34552), Dst Port: domain (53)
IP, Src Addr: ns.above.net (207.126.96.162), Dst Addr: ishtar.tlo (64.81.58.33)
UDP, Src Port: domain (53), Dst Port: 34552 (34552)
IP, Src Addr: ishtar.tlo (64.81.58.33), Dst Addr: l2.NSTLD.COM (192.41.162.31)
UDP, Src Port: 34552 (34552), Dst Port: domain (53)

-------
	So why would I, be getting all the unmatched incoming UDP and how would I
decrease their occurance?  

	Is that slightly better? :-)
linda



> -----Original Message-----
> From: bind-users-bounce at isc.org 
> [mailto:bind-users-bounce at isc.org] On Behalf Of Simon Waters
> Sent: January 31, 2003 02:42a
> To: comp-protocols-dns-bind at isc.org
> Subject: Re: naive question; using bind behind a 
> outbound-only firewall
> 
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> linda w wrote:
> > I have bind 8.x setup behind an outgoing-only firewall.  
> I'm using=20
> > bind on a 'border machine' to serve IP's to isolated-subnet 
> clients.  =
> > The border machine can initiate outbound TCP UDP and ICMP 
> traffic but =
> > the only inbound data is "return" traffic ( on a TCP connection).  =
> > Incoming UDP and ICMP packets are dropped by a transparent 
> firewall =
> > before the get to the
> > border machine.
> > 
> > This has 'worked' for some time...
> 
> If this is a complete description I am quite surprised it 
> works at all.
> 
> I assume you are letting in UDP responses to queries, even if 
> you don't know it, or you must have some way of forcing TCP 
> queries, and fail to see large parts of the DNS that only 
> allow UDP queries.
> 
> You won't get UDP responses unless you asked UDP questions, 
> if you ask UDP questions and get no answer you won't ask TCP 
> questions.
> 
> I think you are confused - check these packets harder - or 
> show us some, they may not be what you think they are.
> 
> Doesn't Rusty have a diatribe somewhere about blocking all 
> ICMP packets - probably in the IPChains HOW-TO for Linux, but 
> that is off-topic.
> 
>  Simon
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQE+OlLlGFXfHI9FVgYRApfkAJ91ma66KKdnlTops4keUsBWzelMHQCgoJqM
> +zK1OywH78dbC5F+wyhQAPI=
> =QK88
> -----END PGP SIGNATURE-----
> 
> 
>