Re: Secondary and TLD not updating
Hey, maybe it's time to agree to disagree on this one? If Bert and Ernie can live together in roommate bliss, I'm sure we can all accept and appreciate each others differences. On Mon, Nov 17, 2008 at 7:47 PM, Kevin Darcy [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Just because individual records are public doesn't mean you should allow just anyone to configure their nameserver as a slave to your domain. There's no benefit to allowing transfers to just anybody except for the allowance it makes for the laziness of admins. Incorrect. I've often AXFR'ed people's zones to help troubleshoot problems they've reported. Weigh that against the risks of DoS attacks, and the sucking up of previous upload bandwidth by domain transfers out. Each such transfer could well use many many queries worth of bandwidth. Individual queries of every record in the zone consumes as much or even more bandwidth. Moreover, if a would-be hacker were to start *guessing* at names in the zone, then the total query traffic might actually be *substantially* larger than the zone transfer would be. (If Intrusion Detection/Prevention is in place, the hacker could fly under the radar horizon by spreading the queries over a moderately-long period of time, from different clients in a botnet, but the aggregate traffic might still be higher than an AXFR). Perhaps you don't understand that AXFRs are TCP. So reflection attacks aren't really an issue, and the usual concerns about DoS-amplification-via-reflector are misplaced. Admittedly, if one has exceptionally large RRsets in a given zone (e.g. using TXT RRs as a kind of _ad_hoc_ database), then allowing AXFRs might enable the hackers to find those RRsets and use them for amplification in subsequent DoS attacks. But the moral of that story is that one shouldn't use DNS as a generic distributed database, not that open AXFRs are inherently a security vulnerability. We never experienced any problems with having zone transfers completely open, for years. I realize that's just anecdotal evidence, but, on the other hand, are there any documented cases where open AXFRs were actually used in any kind of attack? If not, then I call FUD. Its one more potential vulnerability with no particular benefit. Sounds like a poor trade to me. That's one opinion. I cited a particular benefit above. Another benefit is that maintaining lists of authorized slaves, potentially on a zone-by-zone basis, complicates named.conf and, as we all know, complicated configs lead to a higher risk of error, which can itself lead itself to security breaches. - Kevin --Original Message-- From: Res Sender: [EMAIL PROTECTED] To: Jefferson Ogata Cc: bind-users@lists.isc.org Subject: Re: Secondary and TLD not updating Sent: Nov 17, 2008 4:20 PM On Mon, 17 Nov 2008, Jefferson Ogata wrote: On 2008-11-17 14:25, Holger Honert wrote: Chris Thompson schrieb: On Nov 17 2008, Res wrote: Ack! allow-transfer should never be any What, never? Why not? Security issue! You really want everyone to download your zone(s)? I couldn't care less. If the security of my systems were the least bit dependent on keeping DNS records secret, I would kinda suck as an admin, wouldn't I? does your employer know this is your attitude? he/she might take a different stand :) I know you'd no longer be working for me, if that was your take on how things should be. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Google for President YouTube for VP in any year divisible by 4 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC launches new website and mailing list manager
The mailing list conversion requires a little explanation: * The new one-stop page for all the lists under isc.org is https://lists.isc.org/mailman/listinfo Now, can it be configured to strip or reject html rubbish? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Views and Blackhole
Chris,
Thanks that worked.
RootNet08
On Tue, Nov 18, 2008 at 12:46 AM, Chris Buxton [EMAIL PROTECTED]wrote:
Remove your subnet from the bogons ACL at the beginning.
acl bogons {
! 192.168.16.0/21;
0.0.0.0/8;
[...]
192.168.0.0/16;
[...]
};
Chris Buxton
Professional Services
Men Mice
On Nov 17, 2008, at 8:38 PM, root net wrote:
Hello,
I have a server I am testing before I put in production. Working on a more
secure bind config. BTW if anyone has any other suggestions on locking down
bind beside below and chroot let me know. I was adding views which has been
debated time and time again whether or not it really helps but anyway. My
problem is I have the latest bogons from team-cymru which includes my
internal network subnet 192.168.16.0/21. So in the bogons list it says
192.168.0.0/16 which is blackholed. So my local network is being
blackholed but it works fine when users not on the bogons query the server
from the external view. My question is how can I get this to work without
adding each cidr block of the 192.168.0.0/16 separately or even breaking
it up in /21s? I have tried everything I know how. A sanitized portion of
my named.conf is this:
//For length sakes I took out the other networks.
acl i_lan { 127.0.0.1; 192.168.16.0/21};
acl i_dns { 127.0.0.1; 192.168.16.2; 192.168.23.2;};
acl bogons { 0.0.0.0/8;
1.0.0.0/8;
2.0.0.0/8;
5.0.0.0/8;
192.168.0.0/16;
198.18.0.0/15;
223.0.0.0/8;
224.0.0.0/3;
};
options {
version Go Away;
directory /var/named;
dump-file /var/dump/named_dump.db;
pid-file /var/run/named/named.pid;
statistics-file /var/stats/named.stats;
recursion no;
allow-query { any; };
listen-on { 127.0.0.1; 192.168.16.2;};
recursive-clients 1000;
tcp-clients 1000;
auth-nxdomain yes;
blackhole { bogons; };
view internal {
match-clients { i_lan; };
notify no;
recursion yes;
allow-transfer { i_dns;};
zone localhost {
type master;
file localhost.zone;
};
zone 127.in-addr.arpa {
type master;
file localhost.zone;
};
zone 0.in-addr.arpa {
type master;
file named.zero;
};
zone 255.in-addr.arpa {
type master;
file named.broadcast;
// zones go here
};
view external {
match-clients { !i_lan; any; } ;
recursion no;
allow-transfer { i_dns;};
// zones go here
};
Any help is appreciated and thanks in advanced.
RootNet08
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: ISC launches new website and mailing list manager
That reminds me of the debate over V chips/parental controls. People that DON'T want something think it is the responsibility of others not to send it to them rather than THEIR own responsibility to block it with the tools they have. If you don't want HTML just set up a rule in your mail client that blocks it. If your mail client doesn't allow you to setup rules then you probably need to use something created in the current millennium. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lars Hecking Sent: Tuesday, November 18, 2008 7:54 AM To: bind-users@lists.isc.org; [EMAIL PROTECTED] Subject: Re: ISC launches new website and mailing list manager The mailing list conversion requires a little explanation: * The new one-stop page for all the lists under isc.org is https://lists.isc.org/mailman/listinfo Now, can it be configured to strip or reject html rubbish? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- 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
RE: Reverse lookups failing
Please disregard. This is working now. Was either an ASA firewall dns filter which was stopped and restarted during testing or the setting of both nameservers to run bind9.3.5-P2. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davenport, Steve M Sent: Monday, November 17, 2008 8:20 PM To: [EMAIL PROTECTED] Subject: Reverse lookups failing Hello, I am having issues with reverse lookups failing and can not find the cause. Running bind 9.3.5-P1 and 9.3.6rc1. On an external server dig gives: $ dig @harley.mc.utmck.edu -x 165.6.6.27 ; DiG 9.5.0-P1 @harley.mc.utmck.edu -x 165.6.6.27 ; (1 server found) ;; global options: printcmd ;; connection timed out; no servers could be reached Internally the same query is fine: $ dig @harley.mc.utmck.edu -x 165.6.6.27 ; DiG 9.2.4 @harley.mc.utmck.edu -x 165.6.6.27 ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1952 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;27.6.6.165.in-addr.arpa. IN PTR ;; ANSWER SECTION: 27.6.6.165.in-addr.arpa. 21600 IN PTR ns-2.hosp.utmck.edu. ;; AUTHORITY SECTION: 6.165.in-addr.arpa. 21600 IN NS ns-2.hosp.utmck.edu. 6.165.in-addr.arpa. 21600 IN NS harley.mc.utmck.edu. ;; ADDITIONAL SECTION: ns-2.hosp.utmck.edu.21600 IN A 165.6.6.27 harley.mc.utmck.edu.21600 IN A 165.6.131.32 ;; Query time: 18 msec ;; SERVER: 165.6.131.32#53(harley.mc.utmck.edu) ;; WHEN: Mon Nov 17 19:50:49 2008 ;; MSG SIZE rcvd: 144 The config file has allow query set on the reverse zone. This was working earlier and I'm told there have been no network changes. Does this appear to be a firewall issue? Is there anything else that might help narrow down the problem? Thanks for your assistance, Steve ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind9 no longer detect my ipv6 interface after having upgrade from ubuntu server 8.04 to 8.10
On Tue, Nov 18, 2008 at 04:13:35PM +0100, Thomas Manson wrote: Hi, Hi, I've my secondary DNS Server that run bind9 version 9.5.0-P2 (from ubuntu 8.10 server) Before, I was using the version on ubuntu 8.04 and it was working successfully with ipv6. I think BIND from Ubuntu distribution is not compiled as GNU source (with _GNU_SOURCE macro defined). It is needed to get IPv6 working. The best solution is to open ticket in Ubuntu bug tracker. Adam -- Adam Tkac, Red Hat, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Zone does not show an A record when using Dig
It's resolving correctly from dnsstuff.com ... Shawn Somers Systems Administrator Skynet BroadBand (360)802-6657 Steve Koon wrote: I have one of my zones that is not showing one of the A records when using Dig anyone know why this is happening? *emailclickA 64.186.224.244* Thanks, Steve === Zone file content on secondary $ORIGIN . $TTL 900 ; 15 minutes discoversunriver.com IN SOA ns1.escapia.com. nsadmin.escapia.com. ( 2008111801 ; serial 10800 ; refresh (3 hours) 3600 ; retry (1 hour) 86400 ; expire (1 day) 86400 ; minimum (1 day) ) NSns1.escapia.com. NSns2.escapia.com. NSpdns1.ultradns.net. NSpdns2.ultradns.net. A 69.25.129.10 MX1 aspmx.l.google.com. MX5 alt1.aspmx.l.google.com. MX5 alt2.aspmx.l.google.com. MX10 aspmx2.googlemail.com. MX10 aspmx3.googlemail.com. MX10 aspmx4.googlemail.com. MX10 aspmx5.googlemail.com. TXT v=spf1 ip4:64.186.224.192/26 ip4:69.63.216.128/26 ip4:69.63.211.0/25 ip4:69.25.129.6 ip4:72.18.155.106/29 a mx a:wezen.escapia.com include:aspmx.googlemail.com ~all $ORIGIN discoversunriver.com. emailclick A 64.186.224.244 googlea4183689 CNAMEgoogle.com. mail CNAMEcrs.ultradns.net. www A 69.25.129.10 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
