Re: [DNSSEC] BIND validates but not Unbound: who is right?
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
[DNSSEC] BIND validates but not Unbound: who is right?
[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 ( AB057D7A9BBDB721EBD33FC64F3C6CC53D9020D12F18
Re: [DNSSEC] BIND validates but not Unbound: who is right?
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?
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 ( D21FC827CF4621DF88D06A8F6EA5F4B4DE72A362AB2E 03D440C315A9D8FE1407 ) cepn.asso.fr. 171998 IN DS 13585
Re: [DNSSEC] BIND validates but not Unbound: who is right?
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?
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?
In message 20150216212821.ga27...@nic.fr, Stephane Bortzmeyer writes: On Tue, Feb 17, 2015 at 07:34:37AM +1100, Mark Andrews ma...@isc.org 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?
On Tue, Feb 17, 2015 at 07:34:37AM +1100, Mark Andrews ma...@isc.org 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?
On Mon, Feb 16, 2015 at 11:34 AM, Stephane Bortzmeyer bortzme...@nic.fr 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: http://dnsviz.net/d/cepn.asso.fr/VOGwhA/dnssec/ 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=alla=8ds=allta=.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
Who is right?
dig ANY example.org @.. Google Public DNS: -- returns DS: no BIND 9.9.3-P2: -- returns DS: yes Unbound 1.4.20: --- returns DS: no Personally I don't care much, but perhaps someone on this list has a strong opinion about these differences that I should know about? Thank you. -- Marco 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: Who is right?
AFAIK dig any will return whatever might be in the cache at the time of the question. On 06/09/13 9:27, Marco Davids (SIDN) wrote: dig ANY example.org @.. Google Public DNS: -- returns DS: no BIND 9.9.3-P2: -- returns DS: yes Unbound 1.4.20: --- returns DS: no Personally I don't care much, but perhaps someone on this list has a strong opinion about these differences that I should know about? Thank you. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ 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: Who is right?
On 09/06/2013 08:27 AM, Marco Davids (SIDN) wrote: dig ANY example.org @.. ANY is a tricky record to send to a recursive server. Some DNS servers (e.g. bind) just return anything in-cache. Others (e.g. unbound) do things differently. In short: ANY is a debugging tool and can't be relied upon to behave consistently. You get marginally more predictable answers if you send to an authoritative server, but still... ___ 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
