Re: Forward zone not working

[sthaug]

> >Ideally every machine should be registering its own PTR record in
> >the DNS and addresses without machines shouldn't have PTR records.
> >The only reason ISP did this is that they were too lazy to manage
> >PTR records for their customers.
> 
> And because no ISP wants "you.suck.isp.com" to show up in their DNS.
> 
> Same fight, different address space.

Agreed. Nice in theory, not going to happen in practice for the ISP
where I'm working.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
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: Shared libraries loaded after chroot

[Marc Haber]

On Mon, May 16, 2016 at 12:23:30PM +0100, Tony Finch wrote:
> Marc Haber  wrote:
> > in Debian, the bind9 packages have recently started to trouble me in
> > chrooted environments since some cryptographic libraries are loaded
> > after bind has chrooted itself, which results - in the case of a
> > minimal chroot - in a fatal run-time error:
> 
> Debian has a patch which initializes OpenSSL before chrooting, which is
> supposed to fix this problem -
> http://anonscm.debian.org/cgit/users/lamont/bind9.git/commit/?h=stable/v9.10.3&id=60cf6b37caf48bd3270aa2b7b8af5ebc47396dce
> https://sources.debian.net/src/bind9/1:9.10.3.dfsg.P4-10/debian/patches/28_prechroot_init.diff/

Thanks for the pointer. I have added this to the Debian bug that led
to this patch and have put Ben on cc.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
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: Shared libraries loaded after chroot

[Marc Haber]

On Mon, May 16, 2016 at 08:09:05AM -0400, Matthew Pounsett wrote:
> On 16 May 2016 at 04:38, Marc Haber  wrote:
> > I have filed Debian Bug #820974 (http://bugs.debian.org/820974)
> > accordingly. The Debian bind people suggest that I copy the respective
> > libraries to the chroot so that bind can find them.
> >
> 
> Yeah, this has been the fix on a lot of systems since GOST was included in
> OpenSSL.  It's something to do with the GOST algorithm being implemented
> differently from everything else... as a plugin instead of a module, if
> memory serves (it probably doesn't).IMHO it's a bug in OpenSSL, not
> BIND.
> 
> Another option is to compile BIND with GOST support disabled... but that is
> awkward for a lot of people using binary package distribution from the OS
> vendor.

I think I'll go for a locally built package.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
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: Shared libraries loaded after chroot

[Marc Haber]

On Mon, May 16, 2016 at 08:51:41PM -0400, Paul Kosinski wrote:
> I have avoided the problem chroot causes in a fairly general fashion by
> using "mount --bind". For example:
> 
>   /bin/mount --bind /lib /chroot/dns/lib
> 
> will make the entire /lib directory available to the chrooted BIND,
> assuming the path /chroot/dns is created beforehand to serve as the
> chroot base for running BIND.

This is a wrong and dangerous "fix" since it exposes the parent
system's /lib to the chroot. Preventing this exposure is the reason
for chroot in the first place.

> I have heard that chroot does not provide unbreakable isolation, and,
> of course, many extra files are made available to the chrooted process
> compared to copying the minimum number of individual files.

This is much worse than copying the minimum number of individual files
since it allows the chrooted root account to _directly_ _change_ the
files of the parent system. You can run unchrooted without much more
danger.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
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: New type of DDoS? Anyone saw it?

[Marek Królikowski]

Hello,
I was thinking to block only client who do attacks something like this:
/sbin/iptables --insert INPUT -s IP-ADDRESS-CLIENT-WHO-ATTACK -p udp --dport 
53 -m string --from 40 --to 80 --algo bm --hex-string '|somethinghere|' -j 
DROP -m comment --comment "DROP DNS  DDoS"


Anyone know how must look proper iptables --hex-string to block all  
with IP address: AAA.BBB.CCC.DDD


Best Regards
Marek



In message , "John W. 
Blue" writes:


Hello Marek,

Do you have an IPv6 assignment?  If not, there is really no need to even
be resolving  records.  An overly simplistic description of a
potential solution could be to just drop the incoming  request via
its hex value in much the same way rate limiting is done for the "any"
query:

-hex-string '|FF0001|'

I don't know off hand what the hex value for  is but it should not be
too hard to find.

John


Just dropping  queries is a bad idea as most machines actually
have a  addresses (loopback and linklocal) so just about every
application makes  queries.  If you drop  queries you slow
up every address lookup in your network.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at 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: Shared libraries loaded after chroot

[Paul Kosinski]

I have avoided the problem chroot causes in a fairly general fashion by
using "mount --bind". For example:

  /bin/mount --bind /lib /chroot/dns/lib

will make the entire /lib directory available to the chrooted BIND,
assuming the path /chroot/dns is created beforehand to serve as the
chroot base for running BIND.

N.B. The "--bind" option to mount has nothing to do with BIND or DNS.
 (Look at the 'mount' manual for more details.)

This can be made as specific as desired by using multiple "mount --bind"
commands as needed for example:

  /bin/mount --bind /usr/bin   /chroot/dns/usr/bin
  /bin/mount --bind /usr/lib   /chroot/dns/usr/lib
  /bin/mount --bind /usr/lib64 /chroot/dns/usr/lib64

This is a lot easier than figuring out what files to copy, and all that
is needed after an update is to re-issue all the relevant "mount --bind"
commands.

I have heard that chroot does not provide unbreakable isolation, and,
of course, many extra files are made available to the chrooted process
compared to copying the minimum number of individual files. But I have
more than 500 separate "mount --bind" instances on one of my Linux
machines, setting up multiple chroot environments, and have not seen
any problems.

___
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: Forward zone not working

[Mark Andrews]

In message , Alan Clegg writes:
> On 5/16/16, 6:30 PM, "Mark Andrews"  wrote:
> 
> >Ideally every machine should be registering its own PTR record in
> >the DNS and addresses without machines shouldn't have PTR records.
> >The only reason ISP did this is that they were too lazy to manage
> >PTR records for their customers.
> 
> And because no ISP wants "you.suck.isp.com" to show up in their DNS.
> 
> Same fight, different address space.

Which almost no one would ever see.  If they were really worried
about this ISP's would have raised enough noise to prevent registries
accepting microsoft.com.sucks.example.net.

If they do get you.suck.isp.com then the ISP really should be
thinking about why one of their customers thinks they suck so badly
that they are willing to name their machines with you.suck.isp.com.

Additionally you.suck.isp.com is unlikely to make it into logs as
most logging software actually does a forward checks which would
fail leaving just the raw IP address to be logged.  Additionally
it would also tend to restrict access to sites which care about PTR
records existing as they do check the forward name to see a address
matches with the PTR record.

In reality this is just a lame excuse to not do the right thing
which doesn't stand up to scruntiny.

Mark

> AlanC
> 
> 
> ___
> 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
-- 
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: Logging question about message 'update-security: error: client update denied'

[Matthew Pounsett]

On 16 May 2016 at 19:03, Josh Nielsen  wrote:

> Thank you for the response Mark. I'm still a little confused at what this
> might mean though. Clearly the originating address is my slave DNS server
> (every single one of the messages say "error: client 10.20.0.101").
>
> Are you saying that some process other than named on the same server
> (10.20.0.101) is responsible for these messages (and is there a 'for
> instance' of what could do such a thing?), or that somehow other hosts are
> relaying their update requests (again: from what possible processes?)
> through my slave dns server? What can I look for to figure this out on my
> network?
>

Your DHCP daemon would be one thing that could be generating those
messages.  Often it's configured to update the DNS with the addresses it's
handing out (either forward, reverse, or both).
___
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: Logging question about message 'update-security: error: client update denied'

[Josh Nielsen]

Could it maybe be dhcp related?

On Mon, May 16, 2016 at 6:03 PM, Josh Nielsen 
wrote:

> Thank you for the response Mark. I'm still a little confused at what this
> might mean though. Clearly the originating address is my slave DNS server
> (every single one of the messages say "error: client 10.20.0.101").
>
> Are you saying that some process other than named on the same server
> (10.20.0.101) is responsible for these messages (and is there a 'for
> instance' of what could do such a thing?), or that somehow other hosts are
> relaying their update requests (again: from what possible processes?)
> through my slave dns server? What can I look for to figure this out on my
> network?
>
> Thanks in advance for any clarifications.
>
> -Josh
>
> On Mon, May 16, 2016 at 4:24 PM, Mark Andrews  wrote:
>
>>
>> In message > fxwgrhl5yssg0ear_fnnpyudzjcdy...@mail.gmail.com>, Josh Nielsen writes:
>> > Hello,
>> >
>> > I have a message that has been showing up in my master DNS server's log
>> > over the past few weeks and I am wondering if I can find more verbose
>> > specifics from debugging messages in BIND somehow.
>> >
>> > The messsage looks like this:
>> >
>> > May 16 10:52:16 dns01 named[2591]: 16-May-2016 10:52:16.844
>> > update-security: error: client 10.20.0.101#34148: update 'my.domain/IN'
>> > denied
>>
>> It a UPDATE request being denied.  It will be some process other
>> than named sending the request unless you have configured named to
>> forward updates.
>>
>> In the best of worlds every machine would be updating its own PTR
>> records and keep its own addresses in the DNS up to date.
>>
>> Mark
>>
>> > The frequency of the messages is sporadic. Sometime two or three time
>> in an
>> > hour, sometimes once each hour, sometimes 2-3 hours go by before I see
>> one,
>> > but I get multiple a day.
>> >
>> > I take it that this means that for some reason the slave is trying to
>> > update the master with some entry, even though I haven't explicitly set
>> up
>> > my slave server to be capable of doing so (that I know of). I intended
>> to
>> > have the slaves only receive changes coming down from the master but
>> not to
>> > try pushing changes up.
>> >
>> > Here is the zone block for the domain in question in the master and
>> slave
>> > servers' /etc/named.conf:
>> >
>> > Master (10.20.0.110):
>> >
>> > zone "my.domain" in {
>> > type master;
>> > file "db.my.domain";
>> > allow-transfer {
>> > 10.20.0.100/32;
>> > 10.20.0.101/32;
>> > };
>> > allow-update {
>> > key "xcat_key";
>> > };
>> > notify yes;
>> > also-notify {10.20.0.100; 10.20.0.101;};
>> > };
>> >
>> > Slave #2 (10.20.0.101):
>> >
>> > zone "my.domain" in {
>> > type slave;
>> > file "slaves/db.my.domain";
>> > masters {10.20.0.110;};
>> > };
>> >
>> > There are no complaints about Slave #1 in the master's log, though it is
>> > basically a clone of Slave #2. They provide name resolution for a
>> compute
>> > cluster and the cluster nodes point to both of them in their resolv.conf
>> > but in alternating order for load balancing purposes. Is there a way
>> that I
>> > can get more detail of what specifically the DNS slave server is trying
>> to
>> > update the master with (maybe via more verbose output on the slave
>> itself)?
>> >
>> > Master BIND version: BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
>> > Slave BIND version: BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6
>> >
>> > Thanks,
>> > Josh
>> --
>> 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: Logging question about message 'update-security: error: client update denied'

[Josh Nielsen]

Thank you for the response Mark. I'm still a little confused at what this
might mean though. Clearly the originating address is my slave DNS server
(every single one of the messages say "error: client 10.20.0.101").

Are you saying that some process other than named on the same server
(10.20.0.101) is responsible for these messages (and is there a 'for
instance' of what could do such a thing?), or that somehow other hosts are
relaying their update requests (again: from what possible processes?)
through my slave dns server? What can I look for to figure this out on my
network?

Thanks in advance for any clarifications.

-Josh

On Mon, May 16, 2016 at 4:24 PM, Mark Andrews  wrote:

>
> In message  fxwgrhl5yssg0ear_fnnpyudzjcdy...@mail.gmail.com>, Josh Nielsen writes:
> > Hello,
> >
> > I have a message that has been showing up in my master DNS server's log
> > over the past few weeks and I am wondering if I can find more verbose
> > specifics from debugging messages in BIND somehow.
> >
> > The messsage looks like this:
> >
> > May 16 10:52:16 dns01 named[2591]: 16-May-2016 10:52:16.844
> > update-security: error: client 10.20.0.101#34148: update 'my.domain/IN'
> > denied
>
> It a UPDATE request being denied.  It will be some process other
> than named sending the request unless you have configured named to
> forward updates.
>
> In the best of worlds every machine would be updating its own PTR
> records and keep its own addresses in the DNS up to date.
>
> Mark
>
> > The frequency of the messages is sporadic. Sometime two or three time in
> an
> > hour, sometimes once each hour, sometimes 2-3 hours go by before I see
> one,
> > but I get multiple a day.
> >
> > I take it that this means that for some reason the slave is trying to
> > update the master with some entry, even though I haven't explicitly set
> up
> > my slave server to be capable of doing so (that I know of). I intended to
> > have the slaves only receive changes coming down from the master but not
> to
> > try pushing changes up.
> >
> > Here is the zone block for the domain in question in the master and slave
> > servers' /etc/named.conf:
> >
> > Master (10.20.0.110):
> >
> > zone "my.domain" in {
> > type master;
> > file "db.my.domain";
> > allow-transfer {
> > 10.20.0.100/32;
> > 10.20.0.101/32;
> > };
> > allow-update {
> > key "xcat_key";
> > };
> > notify yes;
> > also-notify {10.20.0.100; 10.20.0.101;};
> > };
> >
> > Slave #2 (10.20.0.101):
> >
> > zone "my.domain" in {
> > type slave;
> > file "slaves/db.my.domain";
> > masters {10.20.0.110;};
> > };
> >
> > There are no complaints about Slave #1 in the master's log, though it is
> > basically a clone of Slave #2. They provide name resolution for a compute
> > cluster and the cluster nodes point to both of them in their resolv.conf
> > but in alternating order for load balancing purposes. Is there a way
> that I
> > can get more detail of what specifically the DNS slave server is trying
> to
> > update the master with (maybe via more verbose output on the slave
> itself)?
> >
> > Master BIND version: BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
> > Slave BIND version: BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6
> >
> > Thanks,
> > Josh
> --
> 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: Forward zone not working

[Alan Clegg]

On 5/16/16, 6:30 PM, "Mark Andrews"  wrote:

>Ideally every machine should be registering its own PTR record in
>the DNS and addresses without machines shouldn't have PTR records.
>The only reason ISP did this is that they were too lazy to manage
>PTR records for their customers.

And because no ISP wants "you.suck.isp.com" to show up in their DNS.

Same fight, different address space.

AlanC


___
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: Forward zone not working

[Mark Andrews]

In message 
, 
MegaBrutal writes:
> 2016-05-16 19:45 GMT+02:00 Alan Clegg :
> > On 5/16/16, 1:30 PM, "MegaBrutal"  > behalf of megabru...@gmail.com> wrote:
> >
> >>I want to have valid reverse & forward hostnames set up
> >>for this /64 subnet.
> >
> > This is silly.  Don't do this.
> 
> Why?
> 
> Most ISPs set up reverse & forward domain names for pool addresses.
> OK, I'm not an ISP, but it really seems to be a widely accepted and
> endorsed policy, to the point that addresses not having a reverse DNS
> often treated as suspicious.
> 
> 
> 2016-05-16 22:50 GMT+02:00 Mark Andrews :
> >
> > If you want to delegate space to another server DELEGATE it.  Add
> > NS records for the other server.  Forward "zones" are NOT designed
> > to do this.  Doing actual delegations is *not* hard and works with
> > every server in the world.
> 
> What is the acceptable use case for forward zones, then?
> 
> See, ideally the zone should be served by my BIND server, it should be
> authoritative for the zone. Why I can't use it as the authoritative
> server for the zone is that BIND does not have a feature that the
> other DNS server has (on-the-fly generation of IPv6 reverse & forward
> records, without the need to store 2 * 2 ^ 64 records in zone files).

Ideally every machine should be registering its own PTR record in
the DNS and addresses without machines shouldn't have PTR records.
The only reason ISP did this is that they were too lazy to manage
PTR records for their customers.

We have had the tools for machines to be able to update their own
PTR records for nearly 2 decades now and only the reluctance of
ISP's to allow their clients to update the PTR records for their
own addresses has lead to this.

zone 2.0.192.in-addr.arpa {
type master;
file "2.0.192.in-addr.arpa";
update-policy {
grant * tcp-self * PTR;
};
};

And on the client side a tool that does the equivalent of this
when a address is obtained.

nsupdate -V << EOF
local 192.0.2.1
update delete 1.2.0.192.in-addr.arpa IN PTR
update add 1.2.0.192.in-addr.arpa 3600 IN PTR host.example.net
send
EOF

Even better would be

zone 2.0.192.in-addr.arpa {
type master;
file "2.0.192.in-addr.arpa";
update-policy {
grant * tcp-self * KEY;
grant * selfsub *;
};
};

and then use SIG(0) to update the PTR record after installing a KEY
record.  This allows the client to cleanup records after it has
been renumbered.

Mark
-- 
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: Forward zone not working

[Alan Clegg]

On 5/16/16, 5:35 PM, "MegaBrutal"  wrote:

>2016-05-16 19:45 GMT+02:00 Alan Clegg :
>> On 5/16/16, 1:30 PM, "MegaBrutal" > behalf of megabru...@gmail.com> wrote:
>>
>>>I want to have valid reverse & forward hostnames set up
>>>for this /64 subnet.
>>
>> This is silly.  Don't do this.
>
>Why?

Because it's too f'n big and nobody cares about PTR records if they aren't
associated with an address that is actively doing something (i.e., outbound
e-mail service).

>Most ISPs set up reverse & forward domain names for pool addresses.

In IPv4 space, sure.

>OK, I'm not an ISP, but it really seems to be a widely accepted and
>endorsed policy, to the point that addresses not having a reverse DNS
>often treated as suspicious.

I promise that the 18,446,744,073,709,551,616 addresses in your /64
aren't doing anything interesting enough for a PTR record to matter.

AlanC


___
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: Forward zone not working

[MegaBrutal]

2016-05-16 19:45 GMT+02:00 Alan Clegg :
> On 5/16/16, 1:30 PM, "MegaBrutal"  behalf of megabru...@gmail.com> wrote:
>
>>I want to have valid reverse & forward hostnames set up
>>for this /64 subnet.
>
> This is silly.  Don't do this.

Why?

Most ISPs set up reverse & forward domain names for pool addresses.
OK, I'm not an ISP, but it really seems to be a widely accepted and
endorsed policy, to the point that addresses not having a reverse DNS
often treated as suspicious.


2016-05-16 22:50 GMT+02:00 Mark Andrews :
>
> If you want to delegate space to another server DELEGATE it.  Add
> NS records for the other server.  Forward "zones" are NOT designed
> to do this.  Doing actual delegations is *not* hard and works with
> every server in the world.

What is the acceptable use case for forward zones, then?

See, ideally the zone should be served by my BIND server, it should be
authoritative for the zone. Why I can't use it as the authoritative
server for the zone is that BIND does not have a feature that the
other DNS server has (on-the-fly generation of IPv6 reverse & forward
records, without the need to store 2 * 2 ^ 64 records in zone files).
___
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: Logging question about message 'update-security: error: client update denied'

[Mark Andrews]

In message 
, Josh 
Nielsen writes:
> Hello,
> 
> I have a message that has been showing up in my master DNS server's log
> over the past few weeks and I am wondering if I can find more verbose
> specifics from debugging messages in BIND somehow.
> 
> The messsage looks like this:
> 
> May 16 10:52:16 dns01 named[2591]: 16-May-2016 10:52:16.844
> update-security: error: client 10.20.0.101#34148: update 'my.domain/IN'
> denied

It a UPDATE request being denied.  It will be some process other
than named sending the request unless you have configured named to
forward updates.

In the best of worlds every machine would be updating its own PTR
records and keep its own addresses in the DNS up to date.

Mark

> The frequency of the messages is sporadic. Sometime two or three time in an
> hour, sometimes once each hour, sometimes 2-3 hours go by before I see one,
> but I get multiple a day.
> 
> I take it that this means that for some reason the slave is trying to
> update the master with some entry, even though I haven't explicitly set up
> my slave server to be capable of doing so (that I know of). I intended to
> have the slaves only receive changes coming down from the master but not to
> try pushing changes up.
> 
> Here is the zone block for the domain in question in the master and slave
> servers' /etc/named.conf:
> 
> Master (10.20.0.110):
> 
> zone "my.domain" in {
> type master;
> file "db.my.domain";
> allow-transfer {
> 10.20.0.100/32;
> 10.20.0.101/32;
> };
> allow-update {
> key "xcat_key";
> };
> notify yes;
> also-notify {10.20.0.100; 10.20.0.101;};
> };
> 
> Slave #2 (10.20.0.101):
> 
> zone "my.domain" in {
> type slave;
> file "slaves/db.my.domain";
> masters {10.20.0.110;};
> };
> 
> There are no complaints about Slave #1 in the master's log, though it is
> basically a clone of Slave #2. They provide name resolution for a compute
> cluster and the cluster nodes point to both of them in their resolv.conf
> but in alternating order for load balancing purposes. Is there a way that I
> can get more detail of what specifically the DNS slave server is trying to
> update the master with (maybe via more verbose output on the slave itself)?
> 
> Master BIND version: BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
> Slave BIND version: BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6
> 
> Thanks,
> Josh
-- 
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: Forward zone not working

[MegaBrutal]

Temporarily I enabled recursion on the server and then the forward
zone worked well.
Now, if I could enable recursion for a specific zone only, then I won.

Do you have an idea how to do this? I only see options to restrict
recursion for clients. Now I want to control recursion by query (which
domain is being queried), not by client addresses.
___
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: New type of DDoS? Anyone saw it?

[Mark Andrews]

In message , "John W. Blue" 
writes:
> Apologies.  The intent is to drop inbound  queries from the internet.

Which is just as bad if they are pointing to a delegated server or
are replies to queries from your recursive server.  You slow up
people trying to reach you or slow up outbound connections.

Mark
-- 
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: Forward zone not working

[Mark Andrews]

If you want to delegate space to another server DELEGATE it.  Add
NS records for the other server.  Forward "zones" are NOT designed
to do this.  Doing actual delegations is *not* hard and works with
every server in the world.

Mark
-- 
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: New type of DDoS? Anyone saw it?

[John W. Blue]

Apologies.  The intent is to drop inbound  queries from the internet.

Sent from Nine

From: Mark Andrews 
Sent: May 16, 2016 3:41 PM
To: John W. Blue
Cc: bind-users@lists.isc.org
Subject: Re: New type of DDoS? Anyone saw it?


In message , "John W. Blue" 
writes:
>
> Hello Marek,
>
> Do you have an IPv6 assignment?  If not, there is really no need to even
> be resolving  records.  An overly simplistic description of a
> potential solution could be to just drop the incoming  request via
> its hex value in much the same way rate limiting is done for the "any"
> query:
>
> -hex-string '|FF0001|'
>
> I don't know off hand what the hex value for  is but it should not be
> too hard to find.
>
> John

Just dropping  queries is a bad idea as most machines actually
have a  addresses (loopback and linklocal) so just about every
application makes  queries.  If you drop  queries you slow
up every address lookup in your network.

Mark
--
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: New type of DDoS? Anyone saw it?

[Mark Andrews]

In message , "John W. Blue" 
writes:
>
> Hello Marek,
>
> Do you have an IPv6 assignment?  If not, there is really no need to even
> be resolving  records.  An overly simplistic description of a
> potential solution could be to just drop the incoming  request via
> its hex value in much the same way rate limiting is done for the "any"
> query:
>
> -hex-string '|FF0001|'
>
> I don't know off hand what the hex value for  is but it should not be
> too hard to find.
>
> John

Just dropping  queries is a bad idea as most machines actually
have a  addresses (loopback and linklocal) so just about every
application makes  queries.  If you drop  queries you slow
up every address lookup in your network.

Mark
-- 
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

Logging question about message 'update-security: error: client update denied'

[Josh Nielsen]

Hello,

I have a message that has been showing up in my master DNS server's log
over the past few weeks and I am wondering if I can find more verbose
specifics from debugging messages in BIND somehow.

The messsage looks like this:

May 16 10:52:16 dns01 named[2591]: 16-May-2016 10:52:16.844
update-security: error: client 10.20.0.101#34148: update 'my.domain/IN'
denied

The frequency of the messages is sporadic. Sometime two or three time in an
hour, sometimes once each hour, sometimes 2-3 hours go by before I see one,
but I get multiple a day.

I take it that this means that for some reason the slave is trying to
update the master with some entry, even though I haven't explicitly set up
my slave server to be capable of doing so (that I know of). I intended to
have the slaves only receive changes coming down from the master but not to
try pushing changes up.

Here is the zone block for the domain in question in the master and slave
servers' /etc/named.conf:

Master (10.20.0.110):

zone "my.domain" in {
type master;
file "db.my.domain";
allow-transfer {
10.20.0.100/32;
10.20.0.101/32;
};
allow-update {
key "xcat_key";
};
notify yes;
also-notify {10.20.0.100; 10.20.0.101;};
};

Slave #2 (10.20.0.101):

zone "my.domain" in {
type slave;
file "slaves/db.my.domain";
masters {10.20.0.110;};
};

There are no complaints about Slave #1 in the master's log, though it is
basically a clone of Slave #2. They provide name resolution for a compute
cluster and the cluster nodes point to both of them in their resolv.conf
but in alternating order for load balancing purposes. Is there a way that I
can get more detail of what specifically the DNS slave server is trying to
update the master with (maybe via more verbose output on the slave itself)?

Master BIND version: BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1
Slave BIND version: BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6

Thanks,
Josh
___
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: New type of DDoS? Anyone saw it?

[bert hubert]

On Mon, May 16, 2016 at 09:20:17PM +0200, Marek Królikowski wrote:
> Hello
> I just call to one of the client who do this DDoS and he confirm, he use UBI
> devices
> Anyone know how to block all  query like this: "query 331.206.372.214 IN
> " with random AAA.XXX.YYY.ZZZ address?

Marek, I don't know if BIND does this natively, but the following dnsdist
statement implements this:

addAction(RegexRule("^[0-9]{3}\\.[0-9]{3}\\.[0-9]{3}\\.[0-9]{3}$"), 
DropAction())

If you want you could also do:

addAction(AndRule{QTypeRule(pdns.), 
RegexRule("^[0-9]{3}\\.[0-9]{3}\\.[0-9]{3}\\.[0-9]{3}$")}, DropAction())

Which limits it to . 

The only other things you need to do are setACL() so dnsdist allows access
to the right IP addresses and newServer("192.168.1.2") to set the IP address
of your actual BIND server.

This would also get you a whole bunch of cool statistics on how well your
server is doing. For more on dnsdist, see http://dnsdist.org/

Bert
___
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: New type of DDoS? Anyone saw it?

[Marek Królikowski]

Hello
I just call to one of the client who do this DDoS and he confirm, he use UBI
devices
Anyone know how to block all  query like this: "query 331.206.372.214 IN
" with random AAA.XXX.YYY.ZZZ address?

Best Regards
Marek


-Original Message-
From: bert hubert [mailto:bert.hub...@netherlabs.nl] 
Sent: Monday, May 16, 2016 5:45 PM
To: Marek Królikowski 
Cc: bind-users@lists.isc.org
Subject: Re: New type of DDoS? Anyone saw it?

On Mon, May 16, 2016 at 05:03:01PM +0200, Marek Królikowski wrote:
> Today i saw my bind eat almost 90% of RAM when i check logs I find 
> interesting DDoS on my DNS Cluster today:
> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#44968: query: 
> 323.016.231.212 IN  + (8X.1X0.Y.Y)

This may be related to
http://community.ubnt.com/t5/airMAX-General-Discussion/Virus-attack-URGENT-U
BNT/td-p/1562940
where there is talk of a Ubiquity exploit which is reported (elsewhere) to
generate such queries.

Bert


> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#44968: slip response to
> 8X.1X0.33.0/24 for . IN   ()
> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#38600: query: 
> 235.326.031.064 IN  + (8X.1X0.Y.Y)
> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#38600: drop response to
> 8X.1X0.33.0/24 for . IN   ()
> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#51399: query: 
> 331.206.372.214 IN  + (8X.1X0.Y.Y)
> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#51399: slip response to
> 8X.1X0.33.0/24 for . IN   ()
> 
> Looks like IN  query about wrong IPv4 address... i got almost 
> 5000/sec Anyone saw this too?
> 
> Best Regards
> Marek
> 
> 
> ___
> 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

___
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: Forward zone not working

[Woodworth, John R]

> -Original Message-
> From: bind-users-boun...@lists.isc.org 
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of MegaBrutal
> Sent: Monday, May 16, 2016 1:31 PM
> To: bind-users@lists.isc.org
> Subject: Forward zone not working
>
> Hi all,
>
> I have an IPv6 reverse PTR zone for a /48 subnet delegated to my BIND
> server, and one of its /64 subnets are used with SLAAC + Privacy Extensions.
> I want to have valid reverse & forward hostnames set up for this /64 subnet.
> Generating 2 ^ 64 reverse & forward records for BIND would be wasteful if
> not impossible, so I found out that another DNS server, AllKnowingDNS
> [http://all-knowing-dns.zekjur.net/] is built for this particular purpose.
> So far so good, I set up an AllKnowingDNS on another IP address, and delegated
> the /64's PTR zone for it.
>
> It seemed to work at first, but then I discovered that PTR resolutions are
> not reliable. Some services are unable to resolve my reverse PTRs.
> You know, in 2016, I assumed that the majority of recursive DNS servers are
> IPv6-ready (especially those that deal with IPv6 reverse PTRs – I thought
> services those see my IPv6 address and want to reverse-resolve it, most
> probably have access to IPv6-enabled recursive NS-es), so I didn't see any
> problem with having only an IPv6 address for my AllKnowingDNS server. I was 
> wrong.
>
> So let's see my options:
> 1. Reserve a public static IPv4 address for my AllKnowingDNS server. I simply
> can't afford that. IPv4 addresses are expensive.
> 2. Configure my BIND to forward the reverse PTR requests for the reverse /64
> zone to the AllKnowingDNS server, and directly answer queries on its behalf.
> Since my BIND is dual-stack, it would have no problem with receiving requests
> on its IPv4 interface and forwarding them on IPv6. Dnsmasq can easily do that
> (to forward requests for specific zones to specific NS servers), but I don't
> have public Dnsmasq anywhere around, all my authoritative name servers are 
> BIND.
>
> So this how I came around to try a forward-type zone:
>
> zone "y.y.y.y.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" {
> type forward;
> forward only;
> forwarders { ::; }; // IPv6 address of AllKnowingDNS.
> };
>
> Where x substitutes digits of my /48, y substitutes digits of my /64, and z
> substitutes digits of the AllKnowingDNS IPv6 address.
>
> It simply doesn't work. In query logs, I see BIND treats requests for the zone
> as if they were requests for recursion, thus rejects them appropriately. DiG
> backs this up with "status: REFUSED". It doesn't seem like if BIND does any
> effort in forwarding the zone, it just treats it as non-authoritative, which
> would need recursion, and of course recursion is very properly disabled. It's
> like the zone entry weren't even there.
>
> Does anyone have any insights or suggestions?
>
> Thanks in advance!
>

MegaBrutal,

Unfortunately, I don't have an answer for "how to do this today" but I have an
I-D in the works targeting the scalability of large datasets with an emphasis on
the IPv6 namespace (http://tools.ietf.org/html/draft-woodworth-bulk-rr-01).

We've spent a lot of time and effort developing our solution and hope to gain
some traction so for others that might ask this next year I can have an answer.

We are also working on our own implementation for bind and unbound which I would
be glad to share once it is mature enough.


Regards,
John

>
> MegaBrutal
> ___
> 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
>
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.
___
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: Forward zone not working

[Alan Clegg]

On 5/16/16, 1:30 PM, "MegaBrutal"  wrote:

>I want to have valid reverse & forward hostnames set up
>for this /64 subnet.

This is silly.  Don't do this.

AlanC


___
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: Forward zone not working

[/dev/rob0]

On Mon, May 16, 2016 at 07:30:30PM +0200, MegaBrutal wrote:
> zone "y.y.y.y.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" {
> type forward;
> forward only;
> forwarders { ::; }; // IPv6 address of AllKnowingDNS.
> };
> 
> Where x substitutes digits of my /48, y substitutes digits of my 
> /64, and z substitutes digits of the AllKnowingDNS IPv6 address.
> 
> It simply doesn't work. In query logs, I see BIND treats requests 
> for the zone as if they were requests for recursion, thus rejects 
> them appropriately. DiG backs this up with "status: REFUSED". It 
> doesn't seem like if BIND does any effort in forwarding the zone, 
> it just treats it as non-authoritative, which would need recursion, 
> and of course recursion is very properly disabled. It's like the 
> zone entry weren't even there.
> 
> Does anyone have any insights or suggestions?

A query will only be forwarded if RD is set and recursion is 
permitted for that client, as you have already discovered.

Perhaps a zone of type "stub" or "static-stub" would do the job?
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
___
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

Forward zone not working

[MegaBrutal]

Hi all,

I have an IPv6 reverse PTR zone for a /48 subnet delegated to my BIND
server, and one of its /64 subnets are used with SLAAC + Privacy
Extensions. I want to have valid reverse & forward hostnames set up
for this /64 subnet. Generating 2 ^ 64 reverse & forward records for
BIND would be wasteful if not impossible, so I found out that another
DNS server, AllKnowingDNS [http://all-knowing-dns.zekjur.net/] is
built for this particular purpose. So far so good, I set up an
AllKnowingDNS on another IP address, and delegated the /64's PTR zone
for it.

It seemed to work at first, but then I discovered that PTR resolutions
are not reliable. Some services are unable to resolve my reverse PTRs.
You know, in 2016, I assumed that the majority of recursive DNS
servers are IPv6-ready (especially those that deal with IPv6 reverse
PTRs – I thought services those see my IPv6 address and want to
reverse-resolve it, most probably have access to IPv6-enabled
recursive NS-es), so I didn't see any problem with having only an IPv6
address for my AllKnowingDNS server. I was wrong.

So let's see my options:
1. Reserve a public static IPv4 address for my AllKnowingDNS server. I
simply can't afford that. IPv4 addresses are expensive.
2. Configure my BIND to forward the reverse PTR requests for the
reverse /64 zone to the AllKnowingDNS server, and directly answer
queries on its behalf. Since my BIND is dual-stack, it would have no
problem with receiving requests on its IPv4 interface and forwarding
them on IPv6. Dnsmasq can easily do that (to forward requests for
specific zones to specific NS servers), but I don't have public
Dnsmasq anywhere around, all my authoritative name servers are BIND.

So this how I came around to try a forward-type zone:

zone "y.y.y.y.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" {
type forward;
forward only;
forwarders { ::; }; // IPv6 address of AllKnowingDNS.
};

Where x substitutes digits of my /48, y substitutes digits of my /64,
and z substitutes digits of the AllKnowingDNS IPv6 address.

It simply doesn't work. In query logs, I see BIND treats requests for
the zone as if they were requests for recursion, thus rejects them
appropriately. DiG backs this up with "status: REFUSED". It doesn't
seem like if BIND does any effort in forwarding the zone, it just
treats it as non-authoritative, which would need recursion, and of
course recursion is very properly disabled. It's like the zone entry
weren't even there.

Does anyone have any insights or suggestions?

Thanks in advance!


MegaBrutal
___
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: New type of DDoS? Anyone saw it?

[bert hubert]

On Mon, May 16, 2016 at 05:03:01PM +0200, Marek Królikowski wrote:
> Today i saw my bind eat almost 90% of RAM when i check logs I find
> interesting DDoS on my DNS Cluster today:
> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#44968: query: 323.016.231.212
> IN  + (8X.1X0.Y.Y)

This may be related to
http://community.ubnt.com/t5/airMAX-General-Discussion/Virus-attack-URGENT-UBNT/td-p/1562940
where there is talk of a Ubiquity exploit which is reported (elsewhere) to
generate such queries.

Bert


> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#44968: slip response to
> 8X.1X0.33.0/24 for . IN   ()
> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#38600: query: 235.326.031.064
> IN  + (8X.1X0.Y.Y)
> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#38600: drop response to
> 8X.1X0.33.0/24 for . IN   ()
> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#51399: query: 331.206.372.214
> IN  + (8X.1X0.Y.Y)
> 16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#51399: slip response to
> 8X.1X0.33.0/24 for . IN   ()
> 
> Looks like IN  query about wrong IPv4 address... i got almost 5000/sec
> Anyone saw this too?
> 
> Best Regards
> Marek
> 
> 
> ___
> 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
___
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: New type of DDoS? Anyone saw it?

[John W. Blue]

Hello Marek,

Do you have an IPv6 assignment?  If not, there is really no need to even be 
resolving  records.  An overly simplistic description of a potential 
solution could be to just drop the incoming  request via its hex value in 
much the same way rate limiting is done for the "any" query:

–hex-string '|FF0001|'

I don't know off hand what the hex value for  is but it should not be too 
hard to find.

John

Sent from Nine

From: Marek Królikowski 
Sent: May 16, 2016 10:04 AM
To: bind-users@lists.isc.org
Subject: New type of DDoS? Anyone saw it?

Hello,
Today i saw my bind eat almost 90% of RAM when i check logs I find
interesting DDoS on my DNS Cluster today:
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#44968: query: 323.016.231.212
IN  + (8X.1X0.Y.Y)
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#44968: slip response to
8X.1X0.33.0/24 for . IN   ()
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#38600: query: 235.326.031.064
IN  + (8X.1X0.Y.Y)
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#38600: drop response to
8X.1X0.33.0/24 for . IN   ()
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#51399: query: 331.206.372.214
IN  + (8X.1X0.Y.Y)
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#51399: slip response to
8X.1X0.33.0/24 for . IN   ()

Looks like IN  query about wrong IPv4 address... i got almost 5000/sec
Anyone saw this too?

Best Regards
Marek


___
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
___
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

New type of DDoS? Anyone saw it?

[Marek Królikowski]

Hello,
Today i saw my bind eat almost 90% of RAM when i check logs I find
interesting DDoS on my DNS Cluster today:
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#44968: query: 323.016.231.212
IN  + (8X.1X0.Y.Y)
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#44968: slip response to
8X.1X0.33.0/24 for . IN   ()
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#38600: query: 235.326.031.064
IN  + (8X.1X0.Y.Y)
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#38600: drop response to
8X.1X0.33.0/24 for . IN   ()
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#51399: query: 331.206.372.214
IN  + (8X.1X0.Y.Y)
16-May-2016 16:47:47.467 client 8X.1X0.3Y.40#51399: slip response to
8X.1X0.33.0/24 for . IN   ()

Looks like IN  query about wrong IPv4 address... i got almost 5000/sec
Anyone saw this too?

Best Regards
Marek


___
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: Shared libraries loaded after chroot

[Matthew Pounsett]

On 16 May 2016 at 04:38, Marc Haber  wrote:

> I have filed Debian Bug #820974 (http://bugs.debian.org/820974)
> accordingly. The Debian bind people suggest that I copy the respective
> libraries to the chroot so that bind can find them.
>

Yeah, this has been the fix on a lot of systems since GOST was included in
OpenSSL.  It's something to do with the GOST algorithm being implemented
differently from everything else... as a plugin instead of a module, if
memory serves (it probably doesn't).IMHO it's a bug in OpenSSL, not
BIND.

Another option is to compile BIND with GOST support disabled... but that is
awkward for a lot of people using binary package distribution from the OS
vendor.


>
> This, however, would take possibly security relevant libraries from
> the automated update mechanisms of the distributions, and would
> therefore greatly reduce ease of upgrades. It is also not mentioned in
> Chapter 6 of the ARM.
>
> What is the official upstream remedy to this situation?
>
> Frankly, I think this is a bug in bind 9.10, it should load all
> necessary libraries before chrooting itself. I am aware that this
> would probably need parsing of the configuration before chrooting.
>
> What is the recommended way to run bind 9.10 in a chroot?
>
> Greetings
> Marc
>
> --
>
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
> ___
> 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
>
___
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: Shared libraries loaded after chroot

[Tony Finch]

Marc Haber  wrote:
>
> in Debian, the bind9 packages have recently started to trouble me in
> chrooted environments since some cryptographic libraries are loaded
> after bind has chrooted itself, which results - in the case of a
> minimal chroot - in a fatal run-time error:

Debian has a patch which initializes OpenSSL before chrooting, which is
supposed to fix this problem -
http://anonscm.debian.org/cgit/users/lamont/bind9.git/commit/?h=stable/v9.10.3&id=60cf6b37caf48bd3270aa2b7b8af5ebc47396dce
https://sources.debian.net/src/bind9/1:9.10.3.dfsg.P4-10/debian/patches/28_prechroot_init.diff/

So there has been a regression in this patch. Clearly something about
crypto initialization has become more lazy, but I don't know if the extra
laziness is on BIND or in OpenSSL.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/  -  I xn--zr8h punycode
Biscay: Variable 3 or 4. Slight. Fair. Moderate or good, occasionally poor.
___
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

Shared libraries loaded after chroot

[Marc Haber]

Hi,

in Debian, the bind9 packages have recently started to trouble me in
chrooted environments since some cryptographic libraries are loaded
after bind has chrooted itself, which results - in the case of a
minimal chroot - in a fatal run-time error:

May 14 21:57:17 fan named[28066]: starting BIND 9.10.3-P4-Debian  
-f -u bind -t /var/local
/chroot/bind
May 14 21:57:17 fan named[28066]: built with '--prefix=/usr' 
'--mandir=/usr/share/man' '--libdir=/usr/
lib/x86_64-linux-gnu' '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' 
'--with-python=python3' '--
localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' 
'--enable-shared' '--enable-
static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' 
'--with-geoip=/usr' '--with-atf=no'
 '--enable-ipv6' '--enable-rrl' '--enable-filter-' '--enable-native-pkcs11' 
'--with-pkcs11=/usr/li
b/x86_64-linux-gnu/softhsm/libsofthsm2.so' 'CFLAGS=-g -O2 -fPIE 
-fstack-protector-strong -Wformat -Wer
ror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks 
-DNO_VERSION_DATE' 'LDFLAGS=-
fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 
-DDIG_SIGCHASE'
May 14 21:57:17 fan named[28066]: 

May 14 21:57:17 fan named[28066]: BIND 9 is maintained by Internet Systems 
Consortium,
May 14 21:57:17 fan named[28066]: Inc. (ISC), a non-profit 501(c)(3) 
public-benefit
May 14 21:57:17 fan named[28066]: corporation.  Support and training for BIND 9 
are
May 14 21:57:17 fan named[28066]: available at https://www.isc.org/support
May 14 21:57:17 fan named[28066]: 

May 14 21:57:17 fan named[28066]: adjusted limit on open files from 4096 to 
1048576
May 14 21:57:17 fan named[28066]: found 6 CPUs, using 6 worker threads
May 14 21:57:17 fan named[28066]: using 3 UDP listeners per interface
May 14 21:57:17 fan named[28066]: using up to 4096 sockets
May 14 21:57:17 fan named[28066]: ENGINE_by_id failed (crypto failure)
May 14 21:57:17 fan named[28066]: error:25070067:DSO support 
routines:DSO_load:could not load the shared library:dso_lib.c:233:
May 14 21:57:17 fan named[28066]: error:260B6084:engine 
routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:467:
May 14 21:57:17 fan named[28066]: error:2606A074:engine 
routines:ENGINE_by_id:no such engine:eng_list.c:390:id=gost
May 14 21:57:17 fan named[28066]: initializing DST: crypto failure
May 14 21:57:17 fan named[28066]: exiting (due to fatal error)

I have filed Debian Bug #820974 (http://bugs.debian.org/820974)
accordingly. The Debian bind people suggest that I copy the respective
libraries to the chroot so that bind can find them.

This, however, would take possibly security relevant libraries from
the automated update mechanisms of the distributions, and would
therefore greatly reduce ease of upgrades. It is also not mentioned in
Chapter 6 of the ARM.

What is the official upstream remedy to this situation?

Frankly, I think this is a bug in bind 9.10, it should load all
necessary libraries before chrooting itself. I am aware that this
would probably need parsing of the configuration before chrooting.

What is the recommended way to run bind 9.10 in a chroot?

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
___
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