Re: logging forwarding reqs
In article , Gregory Hicks wrote: > > Date: Thu, 15 Apr 2010 14:25:35 -0400 > > Subject: Re: logging forwarding reqs > > From: Jonathan Reed > > To: bind-users@lists.isc.org > > > > But I am still unable to determine if those reqs are asking the > > forwarders. > > > > The forwarders are all Windows boxes which I dont have rights to > > access. Still hoping there is something within bind9 that can say > > the req went to fwd'er. > > Since you don't have access to the Windows boxen, it seems to me that > this is a candidate for the "old sniff the firewall" trick. > > Sniff the DNS traffic on the internal facing connection of your > firewall (you DO have a firewall, don't you?) and see which IP > addresses the DNS requests are originating from. If from your Windows > boxen, then the forwarding is working correctly. (You ARE getting dns > requests resolved on the non-windows clients are you not?) > > If not from the Windows boxen, then there is an error in your setup. Simpler yet, sniff the resolving server and see if it's getting its answers from the Windows boxes. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Re[2]: Apparent BIND problem doing RBL lookups for Postfix
Greg, Usually we use forwarders so we don't always have to bother root servers. Because our ISP's deals with great amount of requests from all the clients, probably most of your new requests are already in their cache and it's much faster than query a root server, because it's on the same network. I mentioned the forwarders parameter because it's usual to use our ISP's dns servers as a forwarder and I thought you might had a misconfigured forwarder. Although you have forwarders configured, from the point of view of your dns clients your dns server still answers the requests the same way, and if you have a problem with your dns server, the problem still remains, so, you are not putting the problem away. > Well, using forwarders might fix "general" bind errors, but it's > likely to run into problems for RBL lookups at spamhaus.org - since they have > limits (100K SMTP connects a day, and 300K lookups) > So using my ISP's name servers which have higher volume is likely to > run afoul of those limits because it's aggregating traffic. Even if > it doesn't right now, it could at any time when someone else does the > same and that increase in lookups pushes us over the edge. I don't think so. All the requests to spamhaus.org will be made by your postfix box, not from your forwarders. And look, your server only queries forwarders when its own cache expired, before that your server answers the queries by himself, without bothering forwarders. I use spamhaus.org with postfix/spamassassin and I've got no problem with it. Best Regards, Nuno Paquete ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled
On Apr 15 2010, Roy Badami wrote: Actually there *is* DNSSEC involved or the query would not have failed. Yes, sorry. I meant to imply that there is no DNSSEC involved beyond the verification of the covering NSEC that proves the lack of a DLV record. There is a bug in the BIND 9.7.0-P1 fixes that triggers this. The fix below is in review at the moment. Interesting - so it sounds like the problems I was seeing with 9.7.0 were probably unrelated. The patch certainly seems to fix the issue with www.bbc.net.uk. I'll run with it for a few days and see if the .org issue I was having earlier recurs. Incidentally, the same patch appears to cure the problem with 9.7.0-P1 and 9.6.2-P1 that I reported earlier as "dig dnskey int." different responses from recent BIND versions Caveat emptor until ISC make the patch official, of course. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Unexpected issues with "nslookup" command
Did I misread your original problem? I thought you said it worked if
you had only one of the nameservers in resolv.conf. You didn't state
but I assume (that word again) that you meant if either of your
nameservers was there by itself it worked?
Why would a recursion issue not come into play when you only had one
nameserver in resolv.conf?
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
Of James Roberts-Thomson
Sent: Friday, April 16, 2010 12:58 AM
To: ma...@isc.org
Cc: bind-users@lists.isc.org
Subject: RE: Unexpected issues with "nslookup" command
Hi Mark,
>allow-recursion defaults to "{ localnets; localhost; };".
>If the client was not on a directly connected network it
>will NOT get recursion by default.
So it would seem; I had made an assumption about subnetting that
apparently was not entirely accurate. Oh well, you know what they say
about assumptions...
>When a piece of software is complaining about something it
>is usually a pretty good bet that it is right and you are
>wrong.
Ah! Humour. Yes, aware of the concept, thanks. :-)
Seriously, whilst I would have been suprised if I'd found a bug in a
fairly well used piece of code like Bind, it has been known to happen.
Thanks for your assistance in helping my understanding of what was
happening.
James.
Usual apologies for the disclaimer:
---
This email and any attachments may contain information that is
confidential and subject to legal privilege. If you are not the intended
recipient, any use, dissemination, distribution or duplication of this
email and attachments is prohibited. If you have received this email in
error please notify the author immediately and erase all copies of the
email and attachments. The Ministry of Social Development accepts no
responsibility for changes made to this message or attachments after
transmission from the Ministry.
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
information and is for the sole use of the intended recipient(s). If you are
not the intended recipient, any disclosure, copying, distribution, or use of
the contents of this information is prohibited and may be unlawful. If you have
received this electronic transmission in error, please reply immediately to the
sender that you have received the message in error, and delete it. Thank you.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
test - plz ignore
___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC and ISAKMP?
Do I need to allow UDP/500 packets (ISAKMP) to my bind DNS servers for DNSSEC? I've been seeing a lot of UDP/500 attempts from the general internet to my public DNS servers, and can't figure out why. The Wikipedia page for DNSSEC doesn't mention anything about ISAKMP or VPN tunnels. -- deny ip any any (4393649193 matches) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC and ISAKMP?
On 4/16/2010 9:49 AM, Deny IP Any Any wrote: > Do I need to allow UDP/500 packets (ISAKMP) to my bind DNS servers for DNSSEC? > > I've been seeing a lot of UDP/500 attempts from the general internet > to my public DNS servers, and can't figure out why. The Wikipedia page > for DNSSEC doesn't mention anything about ISAKMP or VPN tunnels. DNSSEC and ISAKMP are not related. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC and ISAKMP?
On Fri, 16 Apr 2010, Deny IP Any Any wrote: Do I need to allow UDP/500 packets (ISAKMP) to my bind DNS servers for DNSSEC? I've been seeing a lot of UDP/500 attempts from the general internet to my public DNS servers, and can't figure out why. The Wikipedia page for DNSSEC doesn't mention anything about ISAKMP or VPN tunnels. In general, I've seen an increase in udp 500 backscatter. It is not specific to you or dns servers. Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Questions on BIND Start/stop Timings Solaris 9 vs. Ubuntu hardy
I did some timings with BIND 9.6.1-P3 and 9.7.0-P1 on two servers: SunOS 5.9 sun4u sparc SUNW,Sun-Blade-1500 (old hardware) Ubuntu hardy x86_64 GNU/Linux (more modern hardware) I had noticed long times for "rndc reload" to complete, and I wanted to see if 9.6.1-P3 was different than 9.7.0-P1. My test DNS has three small "regular" zones defined. It also has our list of 75,507 spyware/malware zones that we define to point to a "honeypot" machine to log and respond to the traffic. I have marked with "<=" areas where I have questions. SunOS 5.9: --- 9.7.0-P1 Apr 15 10:27:48 ./rndc reload Apr 15 10:28:21 reloading configuration succeeded Apr 15 10:28:21 zone binhafeez.ae/IN: loaded serial ... Apr 15 10:30:38 zone thabengmanagement.co.za/IN: loaded serial ... named process taking 99.44% of CPU. <= Apr 15 10:32:51 reloading zones succeeded Apr 15 10:32:51 next command prompt --- Apr 15 10:46:07 ./rndc stop Apr 15 10:46:07 shutting down: flushing changes Apr 15 10:46:07 no longer listening on 146.137.180.21 Apr 15 named process not shown in "top" output. Apr 15 10:47:41 ps -ef | grep named shows named process gone. <= --- Apr 15 10:53:09 Start BIND. Apr 15 10:53:09 built with '--prefix=/export/home/named/bind' '--with-openssl=/krb5' '--sysconfdir=/export/home/named' '--enable-threads' '--localstatedir=/var' Apr 15 10:53:56 named taking 87% of CPU Apr 15 10:54:49 ps -ef | grep named shows two named processes. root 21638 21637 94 10:53:09 ?1:34 /e... root 21637 19863 0 10:53:09 pts/20:00 /e... Apr 15 10:53:40 zone binhafeez.ae/IN: loaded serial ... Apr 15 10:55:55 zone thabengmanagement.co.za/IN: loaded serial ... Apr 15 10:58:08 two named processes <= Apr 15 10:58:09 next command prompt Apr 15 10:58:13 one named process --- Apr 15 11:29:07 ./rndc stop Apr 15 11:29:07 next command prompt named taking 90% - 95% of CPU <= Apr 15 11:30:45 named process finally stops --- 9.6.1-P3 Apr 15 11:32:34 Start BIND. Apr 15 11:32:34 built with '--prefix=/export/home/named/bind' '--with-openssl=/krb5' '--sysconfdir=/export/home/named' '--enable-threads' '--localstatedir=/var' two named processes running named taking 80% - 99% of CPU Apr 15 11:33:05 zone binhafeez.ae/IN: loaded serial ... Apr 15 11:35:17 zone thabengmanagement.co.za/IN: loaded serial ... Apr 15 11:37:31 running <= Apr 15 11:37:31 next comand prompt Apr 15 11:37:32 one named process running --- Ubuntu hardy: --- 9.7.0-P1 Apr 15 10:38:54 ./rndc reload named process taking 11% - 20% of CPU Apr 15 10:39:04 zone binhafeez.ae/IN: loaded serial ... Apr 15 10:40:06 zone thabengmanagement.co.za/IN: loaded serial ... Apr 15 10:40:19 next command prompt Apr 15 11:07:51 ./rndc stop Apr 15 11:07:51 next command prompt Apr 15 11:07:52 no longer listening on 146.139.115. 146#53 Apr 15 named taking 87% of CPU. Apr 15 11:10:00 exiting Apr 15 11:10:06 named process is gone. --- Apr 15 11:12:27 Start BIND. Apr 15 11:12:27 built with '--prefix=/etc/iscbind/bind/' '--sysconfdir=/etc/iscbind' '--mandir=/usr/share/man' '--infodir=/usr/share/info' named taking 80% of CPU two named processes running root 31162 1 60 11:12 ?00:00:38 /et Apr 15 11:12:37 zone binhafeez.ae/IN: loaded serial ... Apr 15 11:13:12 zone thabengmanagement.co.za/IN: loaded serial ... Apr 15 11:13:14 next command prompt Apr 15 11:13:15 one named process running --- Apr 15 11:18:25 ./rndc stop --- 9.6.1-P3 Apr 15 11:22:57 Start BIND. Apr 15 11:22:58 built with '--prefix=/etc/iscbind/bind/' '--sysconfdir=/etc/iscbind' '--localstatedir=/var' '--mandir=/usr/share/man' '--infodir=/usr/share/info' Apr 15 11:23:07 zone binhafeez.ae/IN: loaded serial ... Apr 15 11:23:27 zone thabengmanagement.
Re: DNSSEC and ISAKMP?
> DNSSEC and ISAKMP are not related. Well, that's no longer entirely true... AIUI Microsoft seem to have decided that in their DNSSEC implementation they will use IPsec (and hence IKE with GSS-API) to secure communications from the client to the validating resolver (rather than using GSS-TSIG, which is how they secure dynamic updates). So in the MS world, DNSSEC and ISAKMP *are* at least indirectly related. I have no idea whether this is likely to result in port 500 traffic to random non-participating nameservers, though - I would assume not but am prepared to be proved wrong. -roy ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unexpected issues with "nslookup" command
In message , "Lightner , Jeff" writes: > Did I misread your original problem? I thought you said it worked if > you had only one of the nameservers in resolv.conf. You didn't state > but I assume (that word again) that you meant if either of your > nameservers was there by itself it worked? > > Why would a recursion issue not come into play when you only had one > nameserver in resolv.conf? When you get to the last (only) nameserver you can fail the query or hope that even though RA is not set the answer is good. The later strategy was choosen. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC and ISAKMP?
On 4/16/2010 4:03 PM, Roy Badami wrote: >> DNSSEC and ISAKMP are not related. > > Well, that's no longer entirely true... AIUI Microsoft seem to have > decided that in their DNSSEC implementation they will use IPsec (and > hence IKE with GSS-API) to secure communications from the client to > the validating resolver (rather than using GSS-TSIG, which is how they > secure dynamic updates). So in the MS world, DNSSEC and ISAKMP *are* > at least indirectly related. > > I have no idea whether this is likely to result in port 500 traffic to > random non-participating nameservers, though - I would assume not but > am prepared to be proved wrong. Wow... Good catch! I've read the Microsoft documentation on 'last mile' DNSSEC goodness and yes, they do rely on IPSec to secure that portion of the DNS transaction. Thanks for pointing that out. It will definitely be interesting to see if this increase in ISAKMP traffic is a side effect of DNSSEC deployment. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Apparent BIND problem doing RBL lookups for Postfix
In article , "Nuno Paquete" wrote: > Greg, > > Usually we use forwarders so we don't always have to bother root > servers. You only bother the root servers when the TLD's NS records aren't in cache. Since these NS records have 2-day TTLs, you don't have to go to the root servers very often. > Because our ISP's deals with great amount of requests from all the > clients, probably most of your new requests are already in their cache > and it's much faster than query a root server, because it's on the same > network. This is certainly true for popular names like yahoo.com and google.com. But entries in the spamhaus RBL are not as likely to be cached, because most users don't look these things up. > I mentioned the forwarders parameter because it's usual to use our ISP's > dns servers as a forwarder and I thought you might had a misconfigured > forwarder. > Although you have forwarders configured, from the point of view of your > dns clients your dns server still answers the requests the same way, and > if you have a problem with your dns server, the problem still remains, > so, you are not putting the problem away. > > > Well, using forwarders might fix "general" bind errors, but it's > > likely to run into problems for RBL lookups at spamhaus.org - since > they have > > limits (100K SMTP connects a day, and 300K lookups) > > So using my ISP's name servers which have higher volume is likely to > > run afoul of those limits because it's aggregating traffic. Even if > > it doesn't right now, it could at any time when someone else does the > > same and that increase in lookups pushes us over the edge. > > I don't think so. All the requests to spamhaus.org will be made by your > postfix box, not from your forwarders. But the postfix box queries his nameserver, which would then query the ISP's nameserver. By the time the query reaches the spamhaus authority, it will be coming from the ISP's server, and thus subject to the rate limiter. However, I doubt that spamhaus would set their rate limits low enough that the aggregated queries from an ISP would trigger it. They've presumably looked at their actual hit rates, and 300K lookups/day probably allows plenty of breathing room. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
