Re: TKEY and zone transfer
Evan Hunt wrote: > > Also, generate a TSIG key to use for the initial TKEY negotiation. I thought the point of TKEY was to upgrade from slow public key authentication to fast secret key authentication, i.e. that you would start off by authenticating the client with SIG(0). Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: TKEY and zone transfer
> > Also, generate a TSIG key to use for the initial TKEY negotiation. > > I thought the point of TKEY was to upgrade from slow public key > authentication to fast secret key authentication, i.e. that you would > start off by authenticating the client with SIG(0). TKEY should work with SIG(0), but I don't have any code to show you that generates SIG(0)-signed TKEY requests -- keycreate.c in the test suite uses TSIG, so I adapted the recipe to that. (Unless some other DNS implementation provides a tool for this purpose? If you know of one, please let me know.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
high volume from outside our networks question
Currently our ISP's bind9 server is experiencing a lot of traffic. It looks like we are being used to attack ip addresses. We do have our own domains that host as well as resolving for our customers. I have an acl for our subnets and we allow-recursion and allow-query-cache for those subnets. The IP's of the abusing servers are outside of our networks. My assumption was that if the query came from outside our networks and it wasn't for one of our domains then there wouldn't be a response, but this isn't the case. If I go outside our network and do a "dig google.com @ourDNSserver" I get: ; <<>> DiG 9.6.-ESV-R3 <<>> google.com @ns1. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23403 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;google.com.IN A ;; AUTHORITY SECTION: com.172800 IN NS a.gtld-servers.net. com.172800 IN NS h.gtld-servers.net. com.172800 IN NS l.gtld-servers.net. com.172800 IN NS d.gtld-servers.net. com.172800 IN NS c.gtld-servers.net. com.172800 IN NS i.gtld-servers.net. com.172800 IN NS m.gtld-servers.net. com.172800 IN NS b.gtld-servers.net. com.172800 IN NS j.gtld-servers.net. com.172800 IN NS f.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. com.172800 IN NS g.gtld-servers.net. com.172800 IN NS k.gtld-servers.net. ;; ADDITIONAL SECTION: a.gtld-servers.net. 172800 IN A 192.5.6.30 a.gtld-servers.net. 172800 IN 2001:503:a83e::2:30 b.gtld-servers.net. 172800 IN A 192.33.14.30 b.gtld-servers.net. 172800 IN 2001:503:231d::2:30 c.gtld-servers.net. 172800 IN A 192.26.92.30 d.gtld-servers.net. 172800 IN A 192.31.80.30 e.gtld-servers.net. 172800 IN A 192.12.94.30 f.gtld-servers.net. 172800 IN A 192.35.51.30 g.gtld-servers.net. 172800 IN A 192.42.93.30 h.gtld-servers.net. 172800 IN A 192.54.112.30 i.gtld-servers.net. 172800 IN A 192.43.172.30 j.gtld-servers.net. 172800 IN A 192.48.79.30 k.gtld-servers.net. 172800 IN A 192.52.178.30 l.gtld-servers.net. 172800 IN A 192.41.162.30 ;; Query time: 2 msec ;; SERVER: xxx.xxx.xxx.xxx#53(xxx.xxx.xxx.xxx) ;; WHEN: Wed Jan 30 14:50:32 2013 ;; MSG SIZE rcvd: 500 Is it supposed to work like this? We are getting 100-600 of these a second. Most are looking up isc.org. They are more then likely spoofed IP's and someone is using our servers to attack people. I spent some time doing google searches and mostly found that you need to make sure you are only doing recursive lookups for your network, but that hasn't solved our issue if we are still sending out responses. -- Richard Carroll richcarr...@gmail.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: high volume from outside our networks question
So the response you received wasn't recursed ";; WARNING: recursion requested but not available", so at least that ACL is holding up, but it could be that the response you got is still being served from your DNS server's cache. Can you share the exact configuration statements you have implemented for allow-recursion and allow-query-cache and are these options in the view stanza or in the global options? Best practice is that authoritative and recursive DNS servers should be completely separate. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: high volume from outside our networks question
acl "trusted" {
xxx.xxx.xxx.0/20;
xxx.xxx.xxx.0/23;
xxx.xxx.xxx.0/22;
xx.xxx.xxx.0/23;
xx.xxx.xxx.0/23;
xx.xxx.xxx.0/23;
x.xx.xxx.0/21;
x.xx.xx.0/24;
xxx.xxx.xxx.0/24;
localhost;
localnets;
};
options {
// Relative to the chroot directory, if any
directory"/etc/namedb";
pid-file"/var/run/named/pid";
dump-file"/var/dump/named_dump.db";
statistics-file"/var/stats/named.stats";
allow-recursion { "trusted"; };
allow-query{ any; };
allow-query-cache { "trusted"; };
Its standard conf with the default stuff in it as well as a 24 zones or so
in it.
On Wed, Jan 30, 2013 at 3:30 PM, Steven Carr wrote:
> So the response you received wasn't recursed ";; WARNING: recursion
> requested but not available", so at least that ACL is holding up, but
> it could be that the response you got is still being served from your
> DNS server's cache. Can you share the exact configuration statements
> you have implemented for allow-recursion and allow-query-cache and are
> these options in the view stanza or in the global options?
>
> Best practice is that authoritative and recursive DNS servers should
> be completely separate.
>
> Steve
>
--
Richard Carroll
richcarr...@gmail.com
785-288-1144
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: high volume from outside our networks question
In message
, rich carroll writes:
>
> acl "trusted" {
> xxx.xxx.xxx.0/20;
> xxx.xxx.xxx.0/23;
> xxx.xxx.xxx.0/22;
> xx.xxx.xxx.0/23;
> xx.xxx.xxx.0/23;
> xx.xxx.xxx.0/23;
> x.xx.xxx.0/21;
> x.xx.xx.0/24;
> xxx.xxx.xxx.0/24;
> localhost;
> localnets;
> };
>
> options {
> // Relative to the chroot directory, if any
> directory"/etc/namedb";
> pid-file"/var/run/named/pid";
> dump-file"/var/dump/named_dump.db";
> statistics-file"/var/stats/named.stats";
> allow-recursion { "trusted"; };
> allow-query{ any; };
> allow-query-cache { "trusted"; };
>
> Its standard conf with the default stuff in it as well as a 24 zones or so
> in it.
>
>
>
> On Wed, Jan 30, 2013 at 3:30 PM, Steven Carr wrote:
>
> > So the response you received wasn't recursed ";; WARNING: recursion
> > requested but not available", so at least that ACL is holding up, but
> > it could be that the response you got is still being served from your
> > DNS server's cache. Can you share the exact configuration statements
> > you have implemented for allow-recursion and allow-query-cache and are
> > these options in the view stanza or in the global options?
> >
> > Best practice is that authoritative and recursive DNS servers should
> > be completely separate.
> >
> > Steve
>
>
>
> --
> Richard Carroll
> richcarr...@gmail.com
> 785-288-1144
You should be getting "REFUSED" responses. With the following
acls named returns REFUSED.
allow-recursion { localhost; 2001:470:1f00:820::/64; };
allow-query-cache { localhost; 2001:470:1f00:820::/64; };
/usr/local/bin/dig -4 .com @drugs
; <<>> DiG 9.9.2-P1 <<>> -4 .com @drugs
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 44936
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.com. IN A
;; Query time: 71 msec
;; SERVER: 192.168.191.223#53(192.168.191.223)
;; WHEN: Thu Jan 31 08:51:58 2013
;; MSG SIZE rcvd: 37
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: high volume from outside our networks question
I'm not entirely sure about the "allow-query { any; };" option you
have configured in the main options section, by default bind allows
queries from all anyway, try removing this and see if that fixes the
issue, it could be having that set is somehow overriding some of the
other statements.
Steve
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: high volume from outside our networks question
I think this is one of those reasons why mixing caching/recursion with
authoritative is bad.
I think the option needed is 'additional-from-cache no;', but its only
effective if 'recursion no' is done in global options ... or in a view?
Hmm, wonder if view is the answerperhaps try something like:
view "trusted" {
match-clients { trusted; };
recursion yes;
allow-recursion { trusted; };
#allow-query-cache is then defaulted to same match as allow-recursion
}
view "untrusted" {
match-clients { any; }
recursion no;
additional-from-cache no;
}
- Original Message -
> acl "trusted" {
> xxx.xxx.xxx.0/20;
> xxx.xxx.xxx.0/23;
> xxx.xxx.xxx.0/22;
> xx.xxx.xxx.0/23;
> xx.xxx.xxx.0/23;
> xx.xxx.xxx.0/23;
> x.xx.xxx.0/21;
> x.xx.xx.0/24;
> xxx.xxx.xxx.0/24;
> localhost;
> localnets;
> };
> options {
> // Relative to the chroot directory, if any
> directory "/etc/namedb";
> pid-file "/var/run/named/pid";
> dump-file "/var/dump/named_dump.db";
> statistics-file "/var/stats/named.stats";
> allow-recursion { "trusted"; };
> allow-query { any; };
> allow-query-cache { "trusted"; };
> Its standard conf with the default stuff in it as well as a 24 zones
> or so in it.
> On Wed, Jan 30, 2013 at 3:30 PM, Steven Carr < sjc...@gmail.com >
> wrote:
> > So the response you received wasn't recursed ";; WARNING: recursion
>
> > requested but not available", so at least that ACL is holding up,
> > but
>
> > it could be that the response you got is still being served from
> > your
>
> > DNS server's cache. Can you share the exact configuration
> > statements
>
> > you have implemented for allow-recursion and allow-query-cache and
> > are
>
> > these options in the view stanza or in the global options?
>
> > Best practice is that authoritative and recursive DNS servers
> > should
>
> > be completely separate.
>
> > Steve
>
> --
> Richard Carroll
> richcarr...@gmail.com
> 785-288-1144
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Senior Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
Snail: Computing and Telecommunications Services (CTS)
Kansas State University, 109 East Stadium, Manhattan, KS 66506-3102
Phone: (785) 532-4916 - Fax: (785) 532-3515 - Email: lkc...@ksu.edu
Web: http://www-personal.ksu.edu/~lkchen - Where: 11 Hale Library
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: high volume from outside our networks question
One very simple question - do you filter spoofed IPs
at your firewalls?
And, BTW, a lot of other must be stuff, like ports 135-139 ...
(but that's another story)
Personally I reject spoofed IPs even without logging.
They are more then likely spoofed IP's and
someone is using our servers to attack people.
rich carroll wrote:
acl "trusted" {
xxx.xxx.xxx.0/20;
xxx.xxx.xxx.0/23;
xxx.xxx.xxx.0/22;
xx.xxx.xxx.0/23;
xx.xxx.xxx.0/23;
xx.xxx.xxx.0/23;
x.xx.xxx.0/21;
x.xx.xx.0/24;
xxx.xxx.xxx.0/24;
localhost;
localnets;
};
options {
// Relative to the chroot directory, if any
directory"/etc/namedb";
pid-file"/var/run/named/pid";
dump-file"/var/dump/named_dump.db";
statistics-file"/var/stats/named.stats";
allow-recursion { "trusted"; };
allow-query{ any; };
allow-query-cache { "trusted"; };
Its standard conf with the default stuff in it as well as a 24 zones or so
in it.
On Wed, Jan 30, 2013 at 3:30 PM, Steven Carr wrote:
So the response you received wasn't recursed ";; WARNING: recursion
requested but not available", so at least that ACL is holding up, but
it could be that the response you got is still being served from your
DNS server's cache. Can you share the exact configuration statements
you have implemented for allow-recursion and allow-query-cache and are
these options in the view stanza or in the global options?
Best practice is that authoritative and recursive DNS servers should
be completely separate.
Steve
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Best regards,
Dmitri Tarkhov
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
