Re: Selective forwarding?

[ObNox]

On 23/01/2019 06:45, Grant Taylor via bind-users wrote:

[...]
I think I'm now geared towards this solutions which seems to be the 
simpler one to implement.


I think it's at least worth playing out to see if it fails or if it 
works well enough for your needs.

[...]
Please share what you end up doing and why you chose it.  I'd like to 
learn from your efforts.  ():-)


Sorry for the late reply, busy as ever.

So, I started working on this matter and I decided to go on with Primary 
DNS as usual on Site1 and Secondaries on Site2/3 with DDNS forwarding.


I've setup a sandbox to play with and I'm facing a problem I can't 
explain at all.


To avoid confusion, I'll start a new thread on the matter.

--
ObNox
___
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: Selective forwarding?

[ObNox]

On 24/01/2019 10:26, Sam Wilson wrote:

Note:  I'm assuming a zone expiry of a week to a month.  I think that 
would accommodate most outages.


I thought of that too :-) A week would be far enough in my case.


Be careful of what you mean by "a week".  If a problem happens on a 
Friday just after you leave for a week's holiday/vacation then you need 
a 10-day timeout to be able to fix it on the Monday you come back.


Sorry for the late reply.

I really like how sysadmins think :-) I always take that into account. 
When I setup something to a "week" or a "month", in reality it's 
 + 2~3 days depending on the situation.


--
ObNox
___
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: DNS FlagDay bind version affected

[Mark Andrews]

Everyone please remember that no one can give you accurate answers without 
knowing the ACTUAL details. Both FIREWALL and NAMESERVER need to be tested 
TOGETHER.

Well if it is this set of servers below you either have a routing issue or a 
firewall which is blocking all DNS queries to 186.154.147.2 assuming that 
2001:470:4:41e::2 and 186.154.147.2 are actually the same machine.

ignios.net. @198.199.105.222 (ns.02.ignios.net.): dns=ok edns=ok edns1=ok 
edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok 
optlist=ok,expire,cookie,subnet signed=ok ednstcp=ok bind11=ok,cookie+badcookie
ignios.net. @2604:a880:1:20::2:6001 (ns.02.ignios.net.): dns=ok edns=ok 
edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok 
optlist=ok,expire,cookie,subnet signed=ok ednstcp=ok bind11=ok,cookie+badcookie
ignios.net. @190.85.201.42 (ns.01.ignios.net.): dns=ok edns=ok edns1=ok 
edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok 
optlist=ok,expire,cookie,subnet signed=ok ednstcp=ok bind11=ok,cookie
ignios.net. @2a03:b0c0:3:d0::26:2001 (ns.03.ignios.net.): dns=ok edns=ok 
edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok 
optlist=ok,expire,cookie,subnet signed=ok ednstcp=ok bind11=ok,cookie
ignios.net. @165.227.162.5 (ns.03.ignios.net.): dns=ok edns=ok edns1=ok 
edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok 
optlist=ok,expire,cookie,subnet signed=ok ednstcp=ok bind11=ok,cookie
ignios.net. @2400:6180:0:d0::94:5001 (ns.04.ignios.net.): dns=ok edns=ok 
edns1=ok edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok 
optlist=ok,cookie+badcookie,subnet signed=ok ednstcp=ok bind11=ok,cookie
ignios.net. @139.59.127.149 (ns.04.ignios.net.): dns=ok edns=ok edns1=ok 
edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok 
optlist=ok,cookie+badcookie,subnet signed=ok ednstcp=ok bind11=ok,cookie
ignios.net. @2001:470:4:41e::2 (ns.01.ignios.net.): dns=ok edns=ok edns1=ok 
edns@512=ok ednsopt=ok edns1opt=ok do=ok ednsflags=ok 
optlist=ok,expire,cookie,subnet signed=ok ednstcp=ok bind11=ok,cookie
ignios.net. @186.154.147.2 (ns.01.ignios.net.): dns=timeout edns=timeout 
edns1=timeout edns@512=timeout ednsopt=timeout edns1opt=timeout do=timeout 
ednsflags=timeout optlist=timeout signed=timeout ednstcp=timeout bind11=timeout

Mark


> On 29 Jan 2019, at 4:46 am, German Molano  wrote:
> 
> Hi to all.
> 
> Checking on the website (https://dnsflagday.net/)  my domains are affected by 
> the EDNS compliance update. I use the RMPs provided by 510 SG 
> (https://www.five-ten-sg.com/mapper/bind) The last version is Bind 9.12.3-P1 
> this version is ok? Or there is something else that i have to fix on the 
> current setup?
> 
> 
> Atentamente. 
> 
> German Molano 
> IgniOS Corp. 
> Cel: +57-3005706799 
> PBX: +57-8-2762624 
> Skype: ignios.corp
> ___
> 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: DNS Re-binding Attack Prevention with BIND

[Grant Taylor via bind-users]

On 01/28/2019 02:22 AM, Blason R wrote:
Can someone guide me on prevention and possible configuration in BIND 
from DNS Re-bind attack?


Please clarify what you mean by "rebinding" and what you're trying to 
protect against.


From one of you other messages, you indicate that you are already using 
Response Policy Zone(s).  I would think that it would be trivial to 
create RPZ entries to filter out specific answers or query names.  What 
are you wanting to do that you aren't already doing with RPZ?


I asked for clarification on what you mean by "rebinding" because (I 
think) it's relatively easy to have RPZ filter replies with answers in 
any given prefix.  I've seen people implement filters for RFC 1918 and 
possibly RFC 3330.


But, to me, this is an incomplete solution because it assumes that the 
addresses being protected are within prefixes listed in RFC 1918 and / 
or RFC 3330.  I find that (what I believe to be an) assumption short 
sited and does nothing to protect companies that are using other non RFC 
3330 IP addresses.  I guess it's simple enough to add / adjust BIND's 
RPZ entries or deny-answer-addresses entries accordingly for such 
networks.  But I've seen too many other things that assume that only RFC 
1918, not even RFC 3330, is internal and needs protected.


So, I ask again, what /specifically/ does "rebinding" mean to you, in 
this context?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: DNS FlagDay bind version affected

[German Molano]

It's a custom message ;), the real versión is:

ns.01.ignios.net   9.11.4P1_1 FreeBSD
ns.02.ignios.net   9.11.2 Linux
ns.03.ignios.net   9.11.2 Linux
ns.04.ignios.net   9.11.2 Linux


Atentamente. 

German Molano 
IgniOS Corp. 
Cel: +57-3005706799 
PBX: +57-8-2762624 
Skype: ignios.corp

- Mensaje original -
De: "Reindl Harald" 
Para: "gmolano" , "bind-users" 
Enviados: Lunes, 28 de Enero 2019 12:54:48
Asunto: Re: DNS FlagDay bind version affected

i doubt that "IgniOS DNS v.1.0.3" is bind 9.12.3-P1

don't confuse rpm packages on your workstations with your authoritative
nameservers responsible for the domain to the outside world

Am 28.01.19 um 18:46 schrieb German Molano:
> Checking on the website (https://dnsflagday.net/)  my domains are affected by 
> the EDNS compliance update. I use the RMPs provided by 510 SG 
> (https://www.five-ten-sg.com/mapper/bind) The last version is Bind 9.12.3-P1 
> this version is ok? Or there is something else that i have to fix on the 
> current setup?

[harry@srv-rhsoft:~]$ dig @NS.01.IGNIOS.NET version.bind txt chaos
;; ANSWER SECTION:
version.bind.   0   CH  TXT "IgniOS DNS v.1.0.3"
___
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: DNS Re-binding Attack Prevention with BIND

[Grant Taylor via bind-users]

On 01/28/2019 04:13 AM, Blason R wrote:
Thanks for the revert however, in my scenario I have Windows AD server 
is being used as a Authoritative DNS for exmaple.local which has 
forwarding set to BIND acting as a RPZ and wanting to see if we can 
conceal this vulnerability on BIND.


Am I understanding you correctly in that you have a Windows DNS server 
that is both:


1) Authoritative for the example.local domain.
2) Configured to forward queries to a BIND DNS server that is applying 
Response Policy Zone filtering.


I'm guessing that BIND is functioning as a recursive resolver for Windows.

You don't currently have deny-answer-aliases enabled.

Is all of this correct?  (I'm assuming that it is unless / until you 
correct.)


Please clarify what vulnerability you are trying to conceal.

I think since BIND is not a NS for example domain even if I enable this 
protection on BIND not sure if that would take effect?


I don't see anything in the ARM talking about needing to be 
authoritative for the domain(s) in question.  So I don't see how BIND 
not having the example.local zone is a problem.


Even if BIND did filter queries for example.local, the Windows server 
shouldn't be sending queries for example.local because Windows is 
authoritative for example.local.


What am I missing / misunderstanding?

Finally, I would expect that you can use RPZ to do filtering that is 
comparable to "deny-answer-addresses {…};" and / or "deny-answer-aliases 
{…};".




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

DNS FlagDay bind version affected

[German Molano]

Hi to all.

Checking on the website (https://dnsflagday.net/)  my domains are affected by 
the EDNS compliance update. I use the RMPs provided by 510 SG 
(https://www.five-ten-sg.com/mapper/bind) The last version is Bind 9.12.3-P1 
this version is ok? Or there is something else that i have to fix on the 
current setup?


Atentamente. 

German Molano 
IgniOS Corp. 
Cel: +57-3005706799 
PBX: +57-8-2762624 
Skype: ignios.corp
___
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: Re: EDNS Compliance

[末松 慶文]

Hi Max

ALG seems to be managing sessions.
Specifically, if the DNS query packet is the first packet
After creating a session and receiving a DNS responce packet
The session seems to be closed with ALG.

It is thought that attention is needed when ALG is disable.
If ALG is disable, the session will be maintained until UDP timeout (1 minute).

I do not have any further information. If detailed information is necessary, I 
recommend that you contact Juniper support.

--
Yoshibumi Suematsu
QTnet, Inc.

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
nmaxpier...@gmail.com
Sent: Sunday, January 20, 2019 2:46 AM
To: Crist Clark mailto:cjc+bind-us...@pumpky.net>>
Cc: bind-users@lists.isc.org
Subject: [社外から受信](送信者確認)Re: EDNS Compliance

I just reconfigured our SRX and everything seems to be working now. I wasn’t 
aware that some alg’s were enabled by default so thank you for pointing that 
out.

Regards,
Max
--
Sent via mobile

On Jan 18, 2019, at 9:22 PM, Crist Clark 
mailto:cjc+bind-us...@pumpky.net>> wrote:
In SRX speak:

  # set security alg dns disable

To verify status of DNS and other ALGs:

  show security alg status

The DNS ALG is one of those enabled by default and must be explicitly disabled 
to turn it off.


On Fri, Jan 18, 2019 at 1:14 PM N. Max Pierson 
mailto:nmaxpier...@gmail.com>> wrote:
The 2 servers that pass the check are behind an old Cisco FWSM so I know it at 
least works. Hopefully that code carried over to the ASA and won't give us any 
problems but if it does, I have the option of moving these servers directly to 
the internet and I can configure iptables for any filtering we need.

As far as any option in the SRX, I do not see any configuration options to 
disable the version check for EDNS as you suggested. I have a couple of posts 
on Juniper forms/mailing lists to see if I get anyone familiar with these 
options but for the moment we are just using the SRX as a packet filter with no 
ALGs so we may be out of luck.

Regards,
Max

Regards,
Max

On Fri, Jan 18, 2019 at 3:07 PM Mark Andrews 
mailto:ma...@isc.org>> wrote:
I can’t remember if Cisco ASA has a similar issue.  Checkpoint does have similar
issues (EDNS version != 0 and EDNS flags) last time I checked.  Checkpoint were
thinking of changing the defaults.  You just need to turn off the setting on the
Juniper.  It really shouldn’t be on by default as it doesn’t do anything useful.

> On 19 Jan 2019, at 7:52 am, N. Max Pierson 
> mailto:nmaxpier...@gmail.com>> wrote:
>
> I was just trying to figure out how I could log this but since the logging 
> would only probably show if something didn't match udp 53 on the server IP it 
> probably wouldn't match the block-any catch-all log I configured. I will 
> certainly bring this up to our Juniper rep but in the meantime, I have a 
> spare Cisco ASA I am going to migrate these subnets to and see if that fixes 
> the timeouts we are experiencing.
>
>  Mark, thank you for your explanation. And if anyone knows someone at Juniper 
> you may want to mention this to them as if they do not fix it before flag 
> day, a lot of queries will be broken.
>
> Regards,
> Max
>
> On Fri, Jan 18, 2019 at 2:42 PM Mark Andrews 
> mailto:ma...@isc.org>> wrote:
> This is the signature of a Juniper firewall which drops EDNS version != 0 and
> packet with a NSID option present.  Dropping EDNS version != 0 just breaks
> future interoperability and as already impacted of EDNS development as the
> RFC 6891 would have included a EDNS version bump except for these stupid
> firewalls dropping EDNS version != 0.  NSID is used to identify a server
> in a anycast cluster and the information is not returned unless the operator
> has configured the server to return it.  There is no need for a firewall to
> drop queries with these properties.
>
> Please file a bug report with Juniper.
>
> Mark
___
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: DNS Re-binding Attack Prevention with BIND

[Tony Finch]

Blason R  wrote:
>
> not sure if that would take effect?

Based on your description, neither am I, I'm afraid.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Trafalgar: North or northwest 5 or 6. Moderate or rough. Showers. Good.
___
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: DNS Re-binding Attack Prevention with BIND

[Blason R]

Hi Tony,

Thanks for the revert however, in my scenario I have Windows AD server is
being used as a Authoritative DNS for exmaple.local which has forwarding
set to BIND acting as a RPZ and wanting to see if we can conceal this
vulnerability on BIND.

I think since BIND is not a NS for example domain even if I enable this
protection on BIND not sure if that would take effect?

Thanks and Regards,
Blason R

On Mon, Jan 28, 2019 at 4:05 PM Tony Finch  wrote:

> Blason R  wrote:
> >
> > Can someone guide me on prevention and possible configuration in BIND
> from
> > DNS Re-bind attack?
>
> Have a look for "rebinding" in
> https://ftp.isc.org/isc/bind9/9.12.0/doc/arm/Bv9ARM.ch06.html
>
> There is evidence that very few people are using `deny-answer-aliases`
> https://kb.isc.org/docs/aa-01639 though it's unclear to me whether that is
> also true for `deny-answer-addresses`.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> Thames, Dover: Northwest 6 to gale 8, decreasing 4 or 5, backing southwest
> later. Moderate or rough becoming slight or moderate. Showers. Good.
>
___
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: DNS Re-binding Attack Prevention with BIND

[Tony Finch]

Blason R  wrote:
>
> Can someone guide me on prevention and possible configuration in BIND from
> DNS Re-bind attack?

Have a look for "rebinding" in
https://ftp.isc.org/isc/bind9/9.12.0/doc/arm/Bv9ARM.ch06.html

There is evidence that very few people are using `deny-answer-aliases`
https://kb.isc.org/docs/aa-01639 though it's unclear to me whether that is
also true for `deny-answer-addresses`.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Thames, Dover: Northwest 6 to gale 8, decreasing 4 or 5, backing southwest
later. Moderate or rough becoming slight or moderate. Showers. Good.
___
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: DNS-FLAG-Day

[Matus UHLAR - fantomas]

On 28.01.19 13:28, Umut Arus wrote:

Don't forget check your IPS. Some IPS rules and tcp ACL can block the
requests. For example, our Checkpoint IPS stopped the requests.


were they requests from you as client or to you as server?


On Mon, Jan 28, 2019 at 1:14 PM Matus UHLAR - fantomas via bind-users <
bind-users@lists.isc.org> wrote:


On 28.01.19 09:25, MEjaz wrote:
>For the upcoming DNS Flag Day on February 1st, 2019.  Is there any
>impact on the user whose using bind name servers.
>
>
>
>As per the infoblox DNS service, they  will not be impacted on DNS Flag
>day.  So Do I need configure support for EDNS0 standards?  In bind if
>yes how to do that.

EDNS0 is compiled and supported in BIND by default.
You only need to check if your settings or firewalls don't block DNS
without
EDNS0

you can test your zones on https://ednscomp.isc.org/ednscomp

according to information https://dnsflagday.net/, your client should not
be blocked from sending EDNS queries.



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Saving Private Ryan...
Private Ryan exists. Overwrite? (Y/N)
___
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: DNS-FLAG-Day

[Umut Arus]

Hi,

Don't forget check your IPS. Some IPS rules and tcp ACL can block the
requests. For example, our Checkpoint IPS stopped the requests.

regards.

On Mon, Jan 28, 2019 at 1:14 PM Matus UHLAR - fantomas via bind-users <
bind-users@lists.isc.org> wrote:

> On 28.01.19 09:25, MEjaz wrote:
> >For the upcoming DNS Flag Day on February 1st, 2019. Is there any impact
> on
> >the user whose using bind name servers.
> >
> >
> >
> >As per the infoblox DNS service, they  will not be impacted on DNS Flag
> day.
> >So Do I need configure support for EDNS0 standards? In bind if yes how to
> do
> >that.
>
> EDNS0 is compiled and supported in BIND by default.
> You only need to check if your settings or firewalls don't block DNS
> without
> EDNS0
>
> you can test your zones on https://ednscomp.isc.org/ednscomp
>
> according to information https://dnsflagday.net/, your client should not
> be
> blocked from sending EDNS queries.
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Windows 2000: 640 MB ought to be enough for anybody
> ___
> 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
>


-- 
*Umut Arus*
Information Technology
Sabancı University
___
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: DNS-FLAG-Day

[Matus UHLAR - fantomas via bind-users]

On 28.01.19 09:25, MEjaz wrote:

For the upcoming DNS Flag Day on February 1st, 2019. Is there any impact on
the user whose using bind name servers.



As per the infoblox DNS service, they  will not be impacted on DNS Flag day.
So Do I need configure support for EDNS0 standards? In bind if yes how to do
that.


EDNS0 is compiled and supported in BIND by default.
You only need to check if your settings or firewalls don't block DNS without
EDNS0 


you can test your zones on https://ednscomp.isc.org/ednscomp

according to information https://dnsflagday.net/, your client should not be
blocked from sending EDNS queries.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows 2000: 640 MB ought to be enough for anybody
___
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

DNS Re-binding Attack Prevention with BIND

[Blason R]

Hi Team,

Can someone guide me on prevention and possible configuration in BIND from
DNS Re-bind attack?

Thanks and Regards,
Blason R
___
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: bind 9.12 rpm dependency problem

[Michał Kępień]

Hi Daniel,

> Error: Package: 1:nfs-utils-1.3.0-0.61.el7.x86_64 (@anaconda)
>Requires: libevent-2.0.so.5()(64bit)
>Removing: libevent-2.0.21-4.el7.x86_64 (@anaconda)
>libevent-2.0.so.5()(64bit)
>Updated By: libevent-2.1.8-3.el7.x86_64 (isc-bind)
>   ~libevent-2.1.so.6()(64bit)
> Error: Package: libverto-libevent-0.2.5-4.el7.x86_64 (@anaconda)
>Requires: libevent-2.0.so.5()(64bit)
>Removing: libevent-2.0.21-4.el7.x86_64 (@anaconda)
>libevent-2.0.so.5()(64bit)
>Updated By: libevent-2.1.8-3.el7.x86_64 (isc-bind)
>   ~libevent-2.1.so.6()(64bit)

There are libevent 2.1.x packages available in the BIND Copr repository,
but you appear to have other packages on the host in question that
depend on libevent 2.0.x and thus yum is refusing to update it.

Since libevent is not a runtime BIND dependency, as a temporary
workaround you can try adding the following line to the BIND Copr
repository configuration in /etc/yum.repos.d:

exclude=libevent*

In the long run, we plan to move to Software Collections, which would
solve problems like this for good, but unfortunately I am unable to
provide you with any estimates as to when exactly that might happen,
sorry.

Hope this helps,

-- 
Best regards,
Michał Kępień
___
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

bind 9.12 rpm dependency problem

[Ambauen Daniel (ID NET)]

Dear list

I tried the new ISC bind BIND 9.12 Packages repo with a vanilla centos7 
installation.  
https://copr.fedorainfracloud.org/coprs/isc/bind/

[root@ict-networks-010-000-002-015 ~]# yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.init7.net
 * extras: mirror.init7.net
 * updates: mirror.init7.net
Resolving Dependencies
--> Running transaction check
---> Package libevent.x86_64 0:2.0.21-4.el7 will be updated
--> Processing Dependency: libevent-2.0.so.5()(64bit) for package: 
libverto-libevent-0.2.5-4.el7.x86_64
--> Processing Dependency: libevent-2.0.so.5()(64bit) for package: 
1:nfs-utils-1.3.0-0.61.el7.x86_64
---> Package libevent.x86_64 0:2.1.8-3.el7 will be an update
--> Finished Dependency Resolution
Error: Package: 1:nfs-utils-1.3.0-0.61.el7.x86_64 (@anaconda)
   Requires: libevent-2.0.so.5()(64bit)
   Removing: libevent-2.0.21-4.el7.x86_64 (@anaconda)
   libevent-2.0.so.5()(64bit)
   Updated By: libevent-2.1.8-3.el7.x86_64 (isc-bind)
  ~libevent-2.1.so.6()(64bit)
Error: Package: libverto-libevent-0.2.5-4.el7.x86_64 (@anaconda)
   Requires: libevent-2.0.so.5()(64bit)
   Removing: libevent-2.0.21-4.el7.x86_64 (@anaconda)
   libevent-2.0.so.5()(64bit)
   Updated By: libevent-2.1.8-3.el7.x86_64 (isc-bind)
  ~libevent-2.1.so.6()(64bit)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

Is this dependency problem well known? 


Regards
Daniel





___
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

bind 9.12 rpm dependency problem

[Ambauen Daniel (ID NET)]

Dear list

I tried the new ISC bind BIND 9.12 Packages repo with a vanilla centos7 
installation.  
https://copr.fedorainfracloud.org/coprs/isc/bind/

[root@ict-networks-010-000-002-015 ~]# yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.init7.net
* extras: mirror.init7.net
* updates: mirror.init7.net
Resolving Dependencies
--> Running transaction check
---> Package libevent.x86_64 0:2.0.21-4.el7 will be updated
--> Processing Dependency: libevent-2.0.so.5()(64bit) for package: 
libverto-libevent-0.2.5-4.el7.x86_64
--> Processing Dependency: libevent-2.0.so.5()(64bit) for package: 
1:nfs-utils-1.3.0-0.61.el7.x86_64
---> Package libevent.x86_64 0:2.1.8-3.el7 will be an update
--> Finished Dependency Resolution
Error: Package: 1:nfs-utils-1.3.0-0.61.el7.x86_64 (@anaconda)
  Requires: libevent-2.0.so.5()(64bit)
  Removing: libevent-2.0.21-4.el7.x86_64 (@anaconda)
  libevent-2.0.so.5()(64bit)
  Updated By: libevent-2.1.8-3.el7.x86_64 (isc-bind)
 ~libevent-2.1.so.6()(64bit)
Error: Package: libverto-libevent-0.2.5-4.el7.x86_64 (@anaconda)
  Requires: libevent-2.0.so.5()(64bit)
  Removing: libevent-2.0.21-4.el7.x86_64 (@anaconda)
  libevent-2.0.so.5()(64bit)
  Updated By: libevent-2.1.8-3.el7.x86_64 (isc-bind)
 ~libevent-2.1.so.6()(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

Is this dependency problem well known? 


Regards
Daniel





___
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