Request to provide procedure for bind upgrade

2015-02-16 Thread Sundram Bharti 

Hi Team,

My DNS current version is "BIND 9.8.4-P1" and OS is "Fedora Core release 
6 (Zod)".


So could you let me know.

"_yum update named_" works for upgrade to current version, if yes then 
what will be the fall back procedure of upgrade fails?


--
BR//
Sundram Bharti
+919717977886

___
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: Request to provide procedure for bind upgrade

2015-02-16 Thread Lightner, Jeff 
The package is “bind” not “named”.   The daemon is called “named”.   You can 
type “rpm –qf $(which named)” to determine which package installed that daemon. 
  (Likely it was bind.)

Also if you’re running the chroot’ed version you’d want the package 
“bind-chroot”.

I’d suggest you run “rpm –qa |grep –i bind” to see what BIND packages you have 
installed.   Note you should ignore things like “ypbind” if installed as that 
is part of NIS rather than BIND.

You can then do “yum list ” against packages to see if there are newer 
versions without installing them.

e.g.  if you saw things like bind-libs, bind-utils, bind, system-config-bind, 
bind-chroot in the output of “rpm –qa” (it will also show version on these)

Do “yum list bind-libs bind-utils bind system-config-bind bind-chroot” which 
will show you both the installed versions you have and the latest available 
packages for update in the repository.

Ideally you have more than one DNS server and would only update one, test it to 
be sure everything is working, then update the next one.



From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Sundram Bharti
Sent: Monday, February 16, 2015 10:17 AM
To: bind-users@lists.isc.org
Subject: Request to provide procedure for bind upgrade

Hi Team,

My DNS current version is "BIND 9.8.4-P1" and OS is "Fedora Core release 6 
(Zod)".

So could you let me know.

"yum update named" works for upgrade to current version, if yes then what will 
be the fall back procedure of upgrade fails?



--

BR//

Sundram Bharti

+919717977886
___
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: Request to provide procedure for bind upgrade

2015-02-16 Thread Novosielski, Ryan 
This is a question about the operating system, not BIND.

There are a number of ways. You can enable rollbacks in RPM, you can keep 
snaphots... you're not going to run into incompatible upgrades in BIND during a 
simple patching.

--
 *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
 || \\UTGERS  |-*O*-
 ||_// Biomedical | Ryan Novosielski - Senior Technologist
 || \\ and Health | novos...@rutgers.edu - 973/972.0922 (2x0922)
 ||  \\  Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
  `'

From: bind-users-boun...@lists.isc.org [bind-users-boun...@lists.isc.org] On 
Behalf Of Sundram Bharti [sundram.bha...@ericsson.com]
Sent: Monday, February 16, 2015 10:16 AM
To: bind-users@lists.isc.org
Subject: Request to provide procedure for bind upgrade

Hi Team,

My DNS current version is "BIND 9.8.4-P1" and OS is "Fedora Core release 6 
(Zod)".

So could you let me know.

"yum update named" works for upgrade to current version, if yes then what will 
be the fall back procedure of upgrade fails?


--
BR//
Sundram Bharti
+919717977886


___
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: Request to provide procedure for bind upgrade

2015-02-16 Thread Chuck Anderson 
Fedora Core 6 is no longer supported.  It went End-Of-Life in 2007:

http://en.wikipedia.org/wiki/Fedora_%28operating_system%29#Releases

On Mon, Feb 16, 2015 at 10:16:37AM -0500, Sundram Bharti wrote:
> Hi Team,
> 
> My DNS current version is "BIND 9.8.4-P1" and OS is "Fedora Core
> release 6 (Zod)".
> 
> So could you let me know.
> 
> "_yum update named_" works for upgrade to current version, if yes
> then what will be the fall back procedure of upgrade fails?
___
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: Request to provide procedure for bind upgrade

2015-02-16 Thread Lightner, Jeff 
Good point.

Fedora isn't really a good choice for Production systems - it is bleeding edge 
with short life cycle (usually new version is out 6 months later and they only 
support the most recent 2.)

Fedora is used as a test bed for what ends up in RHEL later.   RHEL has much 
longer life cycle but requires a paid subscription for updates.   CentOS is a 
binary recompile from RHEL sources that doesn't require a paid subscription.   
The question is whether you need vendor support for the OS.  If yes then RHEL 
would be the way to go.  If not CentOS would work.

Note that RHEL6 and CentOS6 are NOT the same as Fedora 6 - they are much later. 
  Also RHEL7 and CentOS7 are out so if you're reloading to new OS you should 
start with those rather than RHEL6/CentOS6.


-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chuck Anderson
Sent: Monday, February 16, 2015 11:17 AM
To: Sundram Bharti
Cc: bind-users@lists.isc.org
Subject: Re: Request to provide procedure for bind upgrade

Fedora Core 6 is no longer supported.  It went End-Of-Life in 2007:

http://en.wikipedia.org/wiki/Fedora_%28operating_system%29#Releases

On Mon, Feb 16, 2015 at 10:16:37AM -0500, Sundram Bharti wrote:
> Hi Team,
> 
> My DNS current version is "BIND 9.8.4-P1" and OS is "Fedora Core 
> release 6 (Zod)".
> 
> So could you let me know.
> 
> "_yum update named_" works for upgrade to current version, if yes then 
> what will be the fall back procedure of upgrade fails?
___
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

[DNSSEC] BIND validates but not Unbound: who is right?

2015-02-16 Thread Stephane Bortzmeyer 
[The domain has recently changed its configuration so do not test it.]

With Unbound, I get a SERVFAIL:

% dig DNSKEY cepn.asso.fr

; <<>> DiG 9.9.5-8-Debian <<>> DNSKEY cepn.asso.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62442
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;cepn.asso.fr.  IN DNSKEY

;; Query time: 21 msec
;; SERVER: ::1#53(::1)
;; WHEN: Mon Feb 16 16:57:58 CET 2015
;; MSG SIZE  rcvd: 41

But BIND accepts it (and so does Google Public DNS):

% dig @relay1.nic.fr DNSKEY cepn.asso.fr

; <<>> DiG 9.9.5-8-Debian <<>> @relay1.nic.fr DNSKEY cepn.asso.fr
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30861
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;cepn.asso.fr.  IN DNSKEY

;; ANSWER SECTION:
cepn.asso.fr.   7808 IN DNSKEY 257 3 5 (
AwEAAaBtXBNAyFHVvRBB4K9z79+1YRXkUDyycyCzPRpm
Xi9lhB0Eg5vM3XlaS6OuN0dnFHItpZFNIDBDrPsN1OCf
1ULKWpD3KDl1mE7zRK2W0HXeu4WOoFpUcC/1h06W26DT
CkisntU9L8JfPi9osmI+CuzWZhdmyZt+hPvMpjmDthyh
MZpb//kNv7+TUeczCo4MExHxjHHIVH0vRmhfyo/J1KBe
6eS3G5lDbJEEFUdxuLyGQLaG2f6wlQxoHGnzvM+V/Mj8
yGHae//7Z5rMCdaiLJy03u5+l2WVVy954dsrFC6mkB5s
M4n8nvbo1d5ap7cI76dJi9X0IUJQohZk5b5eef0=
) ; KSK; alg = RSASHA1; key id = 36778
cepn.asso.fr.   7808 IN DNSKEY 256 3 5 (
AwEAAc6AqnBoi+hfxMqtb0eokyqWT46Os5N6ZYoFm8Gb
t90EF3hTpuwDClEsulKSckhr4zFTDj3SvHc9krzeQEl5
UNCqmmZeMo/wsxKHTzIVU75fPrs1zOuM9m9zRNV4q9eG
Y0+I2h4D7E/WlPE7n57E0lmPOxK9g46xE8p9eX3bWVVK
FSm60VvginZfTzN3Zgt+peecrboEZnSzWvDVcHY2dq+o
w0UEekI1+nfwcIgEOn0Wh8B5Gx3pG5XkV3QvHVN514FH
eJLdsk0iFPHv1Xc0rLYWssFVS9s7Z8u0tEju6LshGaPQ
+zrQr54RMD9IecwbMCERcrjV2Dm5CZq+Jf53pGc=
) ; ZSK; alg = RSASHA1; key id = 54030
cepn.asso.fr.   7808 IN RRSIG DNSKEY 5 3 10800 (
20250115124200 20150216080551 36778 
cepn.asso.fr.
fc1YnbjbglVC8alL9NN9LUo54kUODgk6gblFt+CjDJ4+
0i9HqEdbbW/49wksEMkFySPf24yRaswbf9W/OHeJtXid
6CEcVdZiHfPuTzxBelQVfPiIQreJ9yvxBF1z/pmTBf0X
o8TEMUjaV4f2c5eqELKdZ986RRk6J35tDd0w3cbeHGV1
mnAagjT+SOLlmF8mx6MZkgsgFylBIt0MfEaX1ZS4PfAh
TCIXi6shM0KcwZ7rI24nVGcu6wDfxdiwUZ5lJ6KWFBsM
pC0beLiKRYlqnQidkech+dlSHQGj0DXAINi6ZrS+iRhv
mCLlId4oezMaxx8P3dLo71cAqPGNBwM62A== )
cepn.asso.fr.   7808 IN RRSIG DNSKEY 5 3 10800 (
20250115124200 20150216080551 54030 
cepn.asso.fr.
v1b7K0jZ4WH1yMCvJHOkxWp7EUHtsFPpKjwplu8EhqDs
WAwB0ORSFMN6Y0PDMfSydXeSwn3+L75OKk1Ne6VNaE5E
jeYi7BEChE0wZH1L6/qyIHgw0YCDfQN4HuG005RFRKgi
p1t06h3iKnVHFzduSxSby5Oq3iZgbyaSPeAhDa/LZPXv
oNb1cVmVrPKTIhZqSxKNC0t4XQ3iUffgrLvq1ErFeuut
QQeD3uzwWXCUkZA5rK7fp9eKKlSOJpP3na2r8cEy0WlC
jZ2HNPA6pIUnq+w7eD0oGp0aukJ1C85TeE1a8cr3Luf8
LnSXm7cIxSWOdw9GZEjaavWFfpYdguFxQQ== )

;; Query time: 1 msec
;; SERVER: 2001:67c:2218:9::4:162#53(2001:67c:2218:9::4:162)
;; WHEN: Mon Feb 16 17:01:03 CET 2015
;; MSG SIZE  rcvd: 1193

I also tested with OARC's ODVR service which confirmed that there is a
difference between BIND and Unbound. 

At the time of the test, the DS were:


% dig DS cepn.asso.fr

; <<>> DiG 9.9.5-8-Debian <<>> DS cepn.asso.fr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6975
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;cepn.asso.fr.  IN DS

;; ANSWER SECTION:
cepn.asso.fr.   171998 IN DS 36778 5 2 (
D21FC827CF4621DF88D06A8F6EA5F4B4DE72A362AB2E
03D440C315A9D8FE1407 )
cepn.asso.fr.   171998 IN DS 13585 8 2 (
AB057D7A9BBDB721EBD33FC64F3C6CC53D90

Re: [DNSSEC] BIND validates but not Unbound: who is right?

2015-02-16 Thread Mukund Sivaraman 
Hi Stephane

On Mon, Feb 16, 2015 at 05:34:53PM +0100, Stephane Bortzmeyer wrote:
> DNSviz, like Unbound, says the domain is broken:
> 
> http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/

DNSviz complains about missing RRs, but shows "status:SECURE" in
epn.asso.fr. with green outlines for DNSKEY, SOA, MX unlike for a bad
zone where it would show "status:INSECURE".

DNSviz also has explanation for why the green shapes are secure.

There was a DS with algorithm=8 in the parent (fr.), but no
corresponding DNSKEYs in the child zone. But there is a valid
authentication chain through the algorithm=5 keys.

I skimmed through this and haven't looked at any fields of the RRs;
maybe there is a different reason from the above why Unbound doesn't
validate, or rather returns SERVFAIL.

Mukund


pgpThA82V9IYo.pgp
Description: PGP 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: [DNSSEC] BIND validates but not Unbound: who is right?

2015-02-16 Thread Mukund Sivaraman 
On Mon, Feb 16, 2015 at 10:39:52PM +0530, Mukund Sivaraman wrote:
> DNSviz also has explanation for why the green shapes are secure.

(1) There is one item that bothers me:

"fr. to cepn.asso.fr.: The DS RRset for the zone included algorithm 5
(RSASHA1), but no key with algorithm 5 was found signing the zone's
DNSKEY RRset. (195.68.96.3, 217.70.177.40)"

I don't know what causes this message (the same message is shown when
hovering on the arrow between the "fr." zone and "cepn.asso.fr." zone
boxes.

(2) I wonder if Unbound is unusually strict in checking that different
DS algorithms have corresponding DNSKEYs at the child, to avoid
downgrade attacks. In the case of an RRSIG, this is a "MUST"
requirement, that signatures exist for different DNSKEY algorithms to
prevent downgrade attacks.  (RFC 5702 sec. 8.2; RFC 4035 sec. 2.2)

But while RFC 4509 sec. 6 talks about this issue in the case of DS with
SHA-2 algorithms, there is no requirement there.

Mukund


pgp0sPCu0dmjg.pgp
Description: PGP 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: [DNSSEC] BIND validates but not Unbound: who is right?

2015-02-16 Thread Mukund Sivaraman 
On Mon, Feb 16, 2015 at 11:19:51PM +0530, Mukund Sivaraman wrote:
> But while RFC 4509 sec. 6 talks about this issue in the case of DS with
> SHA-2 algorithms, there is no requirement there.

There is this nugget here:

> Implementations MUST support the use of the SHA-256 algorithm in DS
> RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
> digests if DS RRs with SHA-256 digests are present in the DS RRset.

Perhaps this is why Unbound fails validation.

We should discuss this in the BIND context. Immediately upon reading
this, I thought this probably means "SHOULD ignore authentication chains
through SHA-1 if an authentication chain through SHA-256 exists." But
that invites downgrade attacks.

Mukund


pgpHFjN4E_DFV.pgp
Description: PGP 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: [DNSSEC] BIND validates but not Unbound: who is right?

2015-02-16 Thread Mukund Sivaraman 
On Mon, Feb 16, 2015 at 11:26:00PM +0530, Mukund Sivaraman wrote:
> On Mon, Feb 16, 2015 at 11:19:51PM +0530, Mukund Sivaraman wrote:
> > But while RFC 4509 sec. 6 talks about this issue in the case of DS with
> > SHA-2 algorithms, there is no requirement there.
> 
> There is this nugget here:
> 
> > Implementations MUST support the use of the SHA-256 algorithm in DS
> > RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
> > digests if DS RRs with SHA-256 digests are present in the DS RRset.
> 
> Perhaps this is why Unbound fails validation.
> 
> We should discuss this in the BIND context. Immediately upon reading
> this, I thought this probably means "SHOULD ignore authentication chains
> through SHA-1 if an authentication chain through SHA-256 exists." But
> that invites downgrade attacks.

UGH that's the DS digest, not algorithm. This is no bug in BIND. I'm
sorry.

Mukund


pgpOlPuccf3gQ.pgp
Description: PGP 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: [DNSSEC] BIND validates but not Unbound: who is right?

2015-02-16 Thread Mukund Sivaraman 
On Mon, Feb 16, 2015 at 05:34:53PM +0100, Stephane Bortzmeyer wrote:
> ;; ANSWER SECTION:
> cepn.asso.fr. 171998 IN DS 36778 5 2 (
>   D21FC827CF4621DF88D06A8F6EA5F4B4DE72A362AB2E
>   03D440C315A9D8FE1407 )
> cepn.asso.fr. 171998 IN DS 13585 8 2 (
>   AB057D7A9BBDB721EBD33FC64F3C6CC53D9020D12F18
>   BCEFC696494C9F9D6111 )

It's still not clear whether one should be preferred over the other in
the case:

1. DS RR algorithm=RSASHA1, digest=SHA-1
2. DS RR algorithm=RSASHA256, digest=SHA-256

But in the case of the DS RRs of cepn.assoc.fr. above, both are SHA-256
digests. So there's an authentication chain through alg=5 digest=2.

Mukund


pgpmeBfUDLHSU.pgp
Description: PGP 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: [DNSSEC] BIND validates but not Unbound: who is right?

2015-02-16 Thread Mark Andrews 

In message <20150216163453.ga...@nic.fr>, Stephane Bortzmeyer writes:
> [The domain has recently changed its configuration so do not test it.]
> 
> With Unbound, I get a SERVFAIL:
> 
> % dig DNSKEY cepn.asso.fr
> 
> ; <<>> DiG 9.9.5-8-Debian <<>> DNSKEY cepn.asso.fr
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62442
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;cepn.asso.fr.IN DNSKEY
> 
> ;; Query time: 21 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Mon Feb 16 16:57:58 CET 2015
> ;; MSG SIZE  rcvd: 41
> 
> But BIND accepts it (and so does Google Public DNS):
> 
> % dig @relay1.nic.fr DNSKEY cepn.asso.fr
> 
> ; <<>> DiG 9.9.5-8-Debian <<>> @relay1.nic.fr DNSKEY cepn.asso.fr
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30861
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;cepn.asso.fr.IN DNSKEY
> 
> ;; ANSWER SECTION:
> cepn.asso.fr. 7808 IN DNSKEY 257 3 5 (
>   AwEAAaBtXBNAyFHVvRBB4K9z79+1YRXkUDyycyCzPRpm
>   Xi9lhB0Eg5vM3XlaS6OuN0dnFHItpZFNIDBDrPsN1OCf
>   1ULKWpD3KDl1mE7zRK2W0HXeu4WOoFpUcC/1h06W26DT
>   CkisntU9L8JfPi9osmI+CuzWZhdmyZt+hPvMpjmDthyh
>   MZpb//kNv7+TUeczCo4MExHxjHHIVH0vRmhfyo/J1KBe
>   6eS3G5lDbJEEFUdxuLyGQLaG2f6wlQxoHGnzvM+V/Mj8
>   yGHae//7Z5rMCdaiLJy03u5+l2WVVy954dsrFC6mkB5s
>   M4n8nvbo1d5ap7cI76dJi9X0IUJQohZk5b5eef0=
>   ) ; KSK; alg = RSASHA1; key id = 36778
> cepn.asso.fr. 7808 IN DNSKEY 256 3 5 (
>   AwEAAc6AqnBoi+hfxMqtb0eokyqWT46Os5N6ZYoFm8Gb
>   t90EF3hTpuwDClEsulKSckhr4zFTDj3SvHc9krzeQEl5
>   UNCqmmZeMo/wsxKHTzIVU75fPrs1zOuM9m9zRNV4q9eG
>   Y0+I2h4D7E/WlPE7n57E0lmPOxK9g46xE8p9eX3bWVVK
>   FSm60VvginZfTzN3Zgt+peecrboEZnSzWvDVcHY2dq+o
>   w0UEekI1+nfwcIgEOn0Wh8B5Gx3pG5XkV3QvHVN514FH
>   eJLdsk0iFPHv1Xc0rLYWssFVS9s7Z8u0tEju6LshGaPQ
>   +zrQr54RMD9IecwbMCERcrjV2Dm5CZq+Jf53pGc=
>   ) ; ZSK; alg = RSASHA1; key id = 54030
> cepn.asso.fr. 7808 IN RRSIG DNSKEY 5 3 10800 (
>   20250115124200 20150216080551 36778 
> cepn.asso.fr.
>   fc1YnbjbglVC8alL9NN9LUo54kUODgk6gblFt+CjDJ4+
>   0i9HqEdbbW/49wksEMkFySPf24yRaswbf9W/OHeJtXid
>   6CEcVdZiHfPuTzxBelQVfPiIQreJ9yvxBF1z/pmTBf0X
>   o8TEMUjaV4f2c5eqELKdZ986RRk6J35tDd0w3cbeHGV1
>   mnAagjT+SOLlmF8mx6MZkgsgFylBIt0MfEaX1ZS4PfAh
>   TCIXi6shM0KcwZ7rI24nVGcu6wDfxdiwUZ5lJ6KWFBsM
>   pC0beLiKRYlqnQidkech+dlSHQGj0DXAINi6ZrS+iRhv
>   mCLlId4oezMaxx8P3dLo71cAqPGNBwM62A== )
> cepn.asso.fr. 7808 IN RRSIG DNSKEY 5 3 10800 (
>   20250115124200 20150216080551 54030 
> cepn.asso.fr.
>   v1b7K0jZ4WH1yMCvJHOkxWp7EUHtsFPpKjwplu8EhqDs
>   WAwB0ORSFMN6Y0PDMfSydXeSwn3+L75OKk1Ne6VNaE5E
>   jeYi7BEChE0wZH1L6/qyIHgw0YCDfQN4HuG005RFRKgi
>   p1t06h3iKnVHFzduSxSby5Oq3iZgbyaSPeAhDa/LZPXv
>   oNb1cVmVrPKTIhZqSxKNC0t4XQ3iUffgrLvq1ErFeuut
>   QQeD3uzwWXCUkZA5rK7fp9eKKlSOJpP3na2r8cEy0WlC
>   jZ2HNPA6pIUnq+w7eD0oGp0aukJ1C85TeE1a8cr3Luf8
>   LnSXm7cIxSWOdw9GZEjaavWFfpYdguFxQQ== )
> 
> ;; Query time: 1 msec
> ;; SERVER: 2001:67c:2218:9::4:162#53(2001:67c:2218:9::4:162)
> ;; WHEN: Mon Feb 16 17:01:03 CET 2015
> ;; MSG SIZE  rcvd: 1193
> 
> I also tested with OARC's ODVR service which confirmed that there is a
> difference between BIND and Unbound. 
> 
> At the time of the test, the DS were:
> 
> 
> % dig DS cepn.asso.fr
> 
> ; <<>> DiG 9.9.5-8-Debian <<>> DS cepn.asso.fr
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6975
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 4096
> ;; QUESTION SECTION:
> ;cepn.asso.fr.IN DS
> 
> ;; ANSWER SECTION:
> cepn.asso.fr. 171998 IN DS 36778 5 2 (
>

Re: [DNSSEC] BIND validates but not Unbound: who is right?

2015-02-16 Thread Stephane Bortzmeyer 
On Tue, Feb 17, 2015 at 07:34:37AM +1100,
 Mark Andrews  wrote 
 a message of 171 lines which said:

> The validator is *not* supposed to *check* if the zone has been
> signed with all the alogorithms in the DS RRset.  It is supposed to
> keep trying all RRSIG/DS/DNSKEY combinations until it succeeds.

For the record, the relevant RFC seems to be RFC 6840, section 5.11,
"A signed zone MUST include a DNSKEY for each algorithm present in the
zone's DS RRset and expected trust anchors for the zone.  The zone
MUST also be signed with each algorithm (though not each key) present
in the DNSKEY RRset."

It seems that the zone violated the first requirment (there was an
alg. 8 in the DS RRset but not in the DNSKEY RRset) but not the second
(there was only alg. 5 in the DNSKEY RRset).


___
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: [DNSSEC] BIND validates but not Unbound: who is right?

2015-02-16 Thread Mark Andrews 

In message <20150216212821.ga27...@nic.fr>, Stephane Bortzmeyer writes:
> On Tue, Feb 17, 2015 at 07:34:37AM +1100,
>  Mark Andrews  wrote 
>  a message of 171 lines which said:
> 
> > The validator is *not* supposed to *check* if the zone has been
> > signed with all the alogorithms in the DS RRset.  It is supposed to
> > keep trying all RRSIG/DS/DNSKEY combinations until it succeeds.
> 
> For the record, the relevant RFC seems to be RFC 6840, section 5.11,
> "A signed zone MUST include a DNSKEY for each algorithm present in the
> zone's DS RRset and expected trust anchors for the zone.  The zone
> MUST also be signed with each algorithm (though not each key) present
> in the DNSKEY RRset."

That is a instruction to the signer.  It is NOT a instuction to the
validator to check.
 
> It seems that the zone violated the first requirment (there was an
> alg. 8 in the DS RRset but not in the DNSKEY RRset) but not the second
> (there was only alg. 5 in the DNSKEY RRset).
> 
> 
-- 
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: [DNSSEC] BIND validates but not Unbound: who is right?

2015-02-16 Thread Casey Deccio 
On Mon, Feb 16, 2015 at 11:34 AM, Stephane Bortzmeyer 
wrote:

> With Unbound, I get a SERVFAIL:
>
> ...


> But BIND accepts it (and so does Google Public DNS):
>
> ...

DNSviz, like Unbound, says the domain is broken:
>
> 


"Broken" is a loaded term.  There are definitely errors with cepn.asso.fr,
namely that because both algorithms 5 and 8 show up in the DS RRset, the
zone MUST be signed with both, i.e., RRSIGs for each algorithm should be
MUST accompany any RRset in the response.  This is specified in RFC 4035,
Sec 2.2.

However, this requirement is clarified in RFC 6840, Sec. 5.11 as follows:

   This requirement applies to servers, not validators.  Validators
   SHOULD accept any single valid path.  They SHOULD NOT insist that all
   algorithms signaled in the DS RRset work, and they MUST NOT insist
   that all algorithms signaled in the DNSKEY RRset work.

Thus, as Mark pointed out, these particular errors should not affect the
validation of cepn.asso.fr, for validators that understand both algorithms
5 and 8.

Note that DNSViz handles such cases by displaying the errors (i.e., with
the red error sign), but still showing the validation status of the RRsets
as "secure" (denoted by the blue-ish color).

http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/

However, you can "see" the reason for the requirement of the signer (i.e.,
that it contains RRSIGs for each algorithm in the DS) in the following
example.  Suppose a validator does not support algorithm 5 (e.g., due to
implementation deficiency, administrative policy, or because algorithm has
been declared obsolete for some reason).  The chain of trust now looks like
this:

http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/?rr=all&a=8&ds=all&ta=.&ta=dlv.isc.org.&tk=

As far as the validator is concerned, there should be a secure path for
both algorithms (as indicated by the algorithms in the DS records).  It
can't choose one or the other because algorithm 5 is not an option.  So it
turns to algorithm 8.  However, because there is no path for algorithm 8,
the chain is broken.

Cheers,
Casey
___
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

SMIMEA TLS

2015-02-16 Thread John Allen 
Does anybody now if there are any developments in this standard and its 
implementation. Particular reference to email.

___
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