Re: Caching-only Name server does Zone Updates
In article gm8o6b$1va...@sf1.isc.org, Ashish ashish@wipro.com wrote: Thank you Mark, Doupdate is followed by lot of statements like Db_update Match Please see the content below. = Doupdate(zone 0, savens x, flags y) Doupdate: dname 21.in-addr.arpa type 6 class 1 ttl 600 Db_update(21.in-addr.arpa, 0x12345, 0x56789, 087, 0x76543) match(0x9b430, 1, 6) 1, 6 db_update: flags = 0x19, sizes = 71, 71 (1) match(0x9123v, 1, 6) 1, 6 db_update: flags = 0x19, sizes = 71, 71 (1) match(0x9sd33, 1, 6) 1, 6 db_update: flags = 0x19, sizes = 71, 71 (1) match(0xdg6d8, 1, 6) 1, 6 db_update: flags = 0x19, sizes = 71, 71 (1) match(0x6abde, 1, 6) 1, 6 == Please correct me if I am wrong, I thought that for cache update it should update only one record. So why so many updates are been made. The response probably contained NS records in the Authority Section and the corresponding A records in the Additional Section. These update the cache as well. -- 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
Fragment Flags Invalid
I installed fresh installation of solaris 10 on sparc machine with latest
bind v9,this server is behind the hardware Firewall(policy from out to in is
udp53from in to out is any).
But my cisco IDS always announces this alarm from my server to other
external clients or servers:
Fragment Flags Invalid
Src Address Dst Address Signature Name
192.168.1.1 x.x.x.xFragment Flags Invalid
Here is my named.conf:
options {
version version not currently available;
pid-file .../run/named.pid;
directory .../named/namedb;
dump-file .../named.dump;
recursive-clients 1;
statistics-file /namedb/statistics;
tcp-clients 1000;
allow-recursion {
any;
};
};
logging {
channel simple_log {
file /var/adm/named/bind.log versions 3 size 50m;
print-category yes;
print-severity yes;
print-time yes;
severity warning;
};
category default {
simple_log;
};
};
key rndc-key {
algorithm ,;
secret ;
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { rndc-key; };
};
does anybody have idea about this alarm? can i fix this error by tunning
bind?
Regards
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Caching-only Name server does Zone Updates
Hi Barry, Thank you for your reply. There was a reverse lookup done as per the Debug content. We have 4 Name servers so there should be 4 response containing NS records in the Authority Section and the corresponding A records in the Additional Section. But we have thousands of statement like Db_update Match in the Debug file. Kindly advice. Kind Regards, Ashish -Original Message- Date: Tue, 03 Feb 2009 03:42:32 -0500 From: Barry Margolin bar...@alum.mit.edu Subject: Re: Caching-only Name server does Zone Updates To: comp-protocols-dns-b...@isc.org Message-ID: barmar-900c8b.03423203022...@mara100-84.onlink.net In article gm8o6b$1va...@sf1.isc.org, Ashish ashish@wipro.com wrote: Thank you Mark, Doupdate is followed by lot of statements like Db_update Match Please see the content below. = Doupdate(zone 0, savens x, flags y) Doupdate: dname 21.in-addr.arpa type 6 class 1 ttl 600 Db_update(21.in-addr.arpa, 0x12345, 0x56789, 087, 0x76543) match(0x9b430, 1, 6) 1, 6 db_update: flags = 0x19, sizes = 71, 71 (1) match(0x9123v, 1, 6) 1, 6 db_update: flags = 0x19, sizes = 71, 71 (1) match(0x9sd33, 1, 6) 1, 6 db_update: flags = 0x19, sizes = 71, 71 (1) match(0xdg6d8, 1, 6) 1, 6 db_update: flags = 0x19, sizes = 71, 71 (1) match(0x6abde, 1, 6) 1, 6 == Please correct me if I am wrong, I thought that for cache update it should update only one record. So why so many updates are been made. The response probably contained NS records in the Authority Section and the corresponding A records in the Additional Section. These update the cache as well. -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DDOS prevention - how to restrict queries to hint (root) zones?
In message 1233658532.12933.42.ca...@muccalla.uninsubria.it, MAtteo HCE Valsa
sna writes:
hi all,
We run BIND 9.3.4-P1.1 on Debian GNU/Linux 4.0 (using the distribution's
package), that do both recursive queries for internal clients (with
proper allow-recursion clause) and authoritative servers for the
institution's domain.
There are reports of DDOS attacks based on DNS requests for the root
zone with spoofed source IP address:
* the attacker sends a request for the root zone with spoofed source
address to a DNS server
* The intermediate victim (DNS server) sends the reply packet -
significatively larger than the request - to the ultimate victim (the
owner of the spoofed source IP address in the request packet).
* the ultimate victim connection is flooded
http://isc.sans.org/diary.html?storyid=5773
I verified that our servers reply when queried from a non-trusted source
address for the root zone. (and we must also notice that the
non-trusted source address argument is pretty pointless when dealing
with spoofed source addresses: if a query with a spoofed internal source
address could reach the server, the server would just DDOS an internal
machine. But we do discard inbound packets with internal source IP
addresses on the network border).
The first answer to this threat would be to disallow queries for the
root zone would for any client (the root zone is used only by the server
itself, right?).
* Do you think there is any reason NOT do do this?
* Do you know a simple way to do this?
the trivial solution of adding an allow-query clause to the root
zone definition is refused by the server, as hint type zones
cannot have an allow-query clause - see
https://lists.isc.org/pipermail/bind-users/2006-January/061077.html
there is possibly a way to do this using views, but...
anything simpler?
options {
allow-query { recusrsive-clients; };
allow-recursion { recusrsive-clients; };
};
zone {
type (slave|master);
...
allow-query { any; };
};
Or upgrade to BIND 9.4 or later and use allow-query-cache,
BIND 9.3 is past end-of-life.
Mark
best regards and thanks for any answer
MAtteo Valsasna
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DDOS prevention - how to restrict queries to hint (root) zones?
On Tue, 3 Feb 2009, Mark Andrews wrote:
In message 1233658532.12933.42.ca...@muccalla.uninsubria.it, MAtteo HCE Valsa
sna writes:
hi all,
We run BIND 9.3.4-P1.1 on Debian GNU/Linux 4.0 (using the distribution's
package), that do both recursive queries for internal clients (with
proper allow-recursion clause) and authoritative servers for the
institution's domain.
There are reports of DDOS attacks based on DNS requests for the root
zone with spoofed source IP address:
* the attacker sends a request for the root zone with spoofed source
address to a DNS server
* The intermediate victim (DNS server) sends the reply packet -
significatively larger than the request - to the ultimate victim (the
owner of the spoofed source IP address in the request packet).
* the ultimate victim connection is flooded
http://isc.sans.org/diary.html?storyid=5773
I verified that our servers reply when queried from a non-trusted source
address for the root zone. (and we must also notice that the
non-trusted source address argument is pretty pointless when dealing
with spoofed source addresses: if a query with a spoofed internal source
address could reach the server, the server would just DDOS an internal
machine. But we do discard inbound packets with internal source IP
addresses on the network border).
The first answer to this threat would be to disallow queries for the
root zone would for any client (the root zone is used only by the server
itself, right?).
* Do you think there is any reason NOT do do this?
* Do you know a simple way to do this?
the trivial solution of adding an allow-query clause to the root
zone definition is refused by the server, as hint type zones
cannot have an allow-query clause - see
https://lists.isc.org/pipermail/bind-users/2006-January/061077.html
there is possibly a way to do this using views, but...
anything simpler?
options {
allow-query { recusrsive-clients; };
allow-recursion { recusrsive-clients; };
};
zone {
type (slave|master);
...
allow-query { any; };
};
Or upgrade to BIND 9.4 or later and use allow-query-cache,
BIND 9.3 is past end-of-life.
Mark
best regards and thanks for any answer
MAtteo Valsasna
Using allow-query to deny some queries still takes time and resources from
your server as it then sends a denied message back to the query source.
As the source is spoofed it then contributes in a small way to the DDoS
attack. I think it is better to just drop the queries on your firewall.
I found this entry for iptables on the list a while back and it works
well and drops around a thousand queries a day.
iptables -A INPUT -i $LOCALIF -j DROP -p udp --dport domain -m u32 --u32
0220...@1216=10220...@2024=00220...@21=0x00020001
--
David Forrest
St. Louis, Missouri
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
DDOS prevention - how to restrict queries to hint (root) zones?
hi all, We run BIND 9.3.4-P1.1 on Debian GNU/Linux 4.0 (using the distribution's package), that do both recursive queries for internal clients (with proper allow-recursion clause) and authoritative servers for the institution's domain. There are reports of DDOS attacks based on DNS requests for the root zone with spoofed source IP address: * the attacker sends a request for the root zone with spoofed source address to a DNS server * The intermediate victim (DNS server) sends the reply packet - significatively larger than the request - to the ultimate victim (the owner of the spoofed source IP address in the request packet). * the ultimate victim connection is flooded http://isc.sans.org/diary.html?storyid=5773 I verified that our servers reply when queried from a non-trusted source address for the root zone. (and we must also notice that the non-trusted source address argument is pretty pointless when dealing with spoofed source addresses: if a query with a spoofed internal source address could reach the server, the server would just DDOS an internal machine. But we do discard inbound packets with internal source IP addresses on the network border). The first answer to this threat would be to disallow queries for the root zone would for any client (the root zone is used only by the server itself, right?). * Do you think there is any reason NOT do do this? * Do you know a simple way to do this? the trivial solution of adding an allow-query clause to the root zone definition is refused by the server, as hint type zones cannot have an allow-query clause - see https://lists.isc.org/pipermail/bind-users/2006-January/061077.html there is possibly a way to do this using views, but... anything simpler? best regards and thanks for any answer MAtteo Valsasna ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Dynamic update of TXT record?
On Mon, Jan 5, 2009 at 5:03 PM, JINMEI Tatuya / 神明達哉 jinmei_tat...@isc.orgwrote: At Thu, 1 Jan 2009 12:23:02 +0100, Michelle Konzack linux4miche...@tamay-dogan.net wrote: Q 1:Which setting is missing? Q2: Can someone tell me how to update a TXT record? Please show named.conf of the authoritative server (the one accepting dynamic updates). It's also helpful to debug it to show log messages of the server when it refused the request. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users allow-update ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Split DNS, internal/external
Hi all,
Having a problem setting up split DNS for the purpose of separating
internal, recursive, caching responses vs external, non caching, non
recusrive responses. First off, can views be used to do this?
If yes, here are the relevant (I hope) portions of named.conf, which I've
set up based on http://www.cymru.com/Documents/secure-bind-template.html:
acl trusted {
8.8.8.0/24;
};
..snip..
view internal-in in {
match clients { trusted };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;
zone . in {
// Link in the root server hint file.
type hint;
file db.cache;
};
zone ournetwork.com in {
// Our internal A RR zone. There may be several of these.
type master;
file ournetwork.com.db;
};
zone 8.8.8.in-addr.arpa in {
// Our internal PTR RR zone. Again, there may be several of these.
type master;
file 8.8.8.in-addr.arpa.db;
};
};
view external-in in {
match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;
zone 8.8.8.in-addr.arpa in {
// Our internal PTR RR zone. Again, there may be several of these.
type master;
file 8.8.8.in-addr.arpa.db;
allow-query { any; };
};
zone ournetwork.com in {
// Our internal A RR zone. There may be several of these.
type master;
file ournetwork.com.db;
allow-query { any; };
};
zone . in {
// Link in the root server hint file.
type hint;
file db.cache;
};
};
The result is that all requests outside the trusted IP range are being
REFUSED. Not sure why that is, though; anyone?
Thanks a bunch!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
