automatic DS record updates in the RIPE database
At the end of his talk at the RIPE meeting this morning, Ondřej Caletka mentioned his work on automated updates to DNSSEC delegations using CDS records: https://ripe77.ripe.net/programme/meeting-plan/dns-wg/ I commented at the mic to say that this is something I am very keen on. I wrote `dnssec-cds` (an implementation of RFC7344 and section 4 of RFC8078) to help improve DNSSEC automation, and it is included in BIND 9.12 and later. https://ftp.isc.org/isc/bind9/9.12.0/doc/arm/man.dnssec-cds.html Ondřej's setup uses a special `mntner` with RIPE database API access to indicate which zones should have their DS records updated automatically. This is a nice way to control permissions when the update process is running outside the RIPE database, but I expect it can be made neater if it is integrated more closely. I would like to help get RFC 7344 support into the RIPE database, so what do we need to do next to make it happen? Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Hebrides, Bailey: Westerly backing southerly later, 5 to 7, occasionally gale 8 at first in north Bailey. Rough or very rough, occasionally high at first in north Bailey. Showers, rain later. Good, occasionally moderate.
On 17 Oct 2018, at 15:51, Tony Finch <dot@dotat.at> wrote:
I would like to help get RFC 7344 support into the RIPE database, so what do we need to do next to make it happen?
You probably should start a conversation in this WG about what needs to be done -- problem statement, possible solutions, etc. Once there's consensus on that the WG would punt the request for a new/changed database object to the Database WG. That's likely to be the formal way to proceed. There a lot of people at RIPE77 who you could talk to over beer or coffee and help make things happen.
Hi Tony, Jim, all, thank you for your interest in automatic updates of DS records in the RIPE database. My piece of (slightly) running code is growing here: https://github.com/oskar456/ripe_db_ds_updater As I said, it is a very early version, not even alpha, but hopefully it will evolve in the future. In my opinion, the implementation of RFC 7344 in RIPE DB should follow similar principles like this tool, that means: - opt-in basis – we expect some level of knowledge for DNSSEC reverse zones operators; scanning the whole delegation space regularly would be pretty futile job, at least with the current status of DNSSEC in the reverse address space* - no support for insecure to secure bootstrapping (RFC 8078) - if this automatic management is opt-in, during opting in, the user should also bootstrap the first DS The exact procedure of opting in is an implementation detail. I personally pretty like the idea of special mntner, because it also stresses the fact that actual object can be modified without of the consent of the regular mntner. Other solution would be to move automatically-managed data out of the database, so the database object would not get modified with every DS update. -- Best regards Ondřej Caletka *) I don't have any numbers, but I expect the adoption ratio is pretty low.
Ondřej Caletka <Ondrej.Caletka@cesnet.cz> wrote:
- opt-in basis
I would like to make this as light-weight as possible. There are already one or two levels of opt-in: uploading DS records to the RIPE database, and publishing CDS records (tho the latter is completely automatic with Knot DNS).
- no support for insecure to secure bootstrapping (RFC 8078) - if this automatic management is opt-in, during opting in, the user should also bootstrap the first DS
That makes sense.
I personally pretty like the idea of special mntner, because it also stresses the fact that actual object can be modified without of the consent of the regular mntner.
Yes, and it addresses Anand's comment that RIPE does not normally update users' objects. But I'm a bit worried that it might be too obscure. If it can't be eliminated entirely, perhaps it can be addressed by hints in the web user interface? Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Tyne, Dogger: West 5 or 6, increasing 6 to gale 8. Moderate or rough, becoming very rough in northeast Dogger. Fair. Good.
Dne 22.10.2018 v 15:58 Tony Finch napsal(a):
Yes, and it addresses Anand's comment that RIPE does not normally update users' objects. But I'm a bit worried that it might be too obscure. If it can't be eliminated entirely, perhaps it can be addressed by hints in the web user interface?
What about some semi-automated solution like this: 1. RIPE NCC would scan all the secure delegations for CDS records 2. if CDS is found and it differs from ds-rdata attribute in the database, then: 3a. if special maintainer is there, do the update 3b. if special maintainer in not there, send an e-mail to zone-c saying: "Hey, we've noticed you would like to change the DS records for your zone 2.0.192.in-addr.arpa. Please update your delegation in the RIPE database here (link). If you want to have updates done automatically, add this mnt-by: attribute to your domain object" -- Ondřej Caletka
Ondřej Caletka <Ondrej.Caletka@cesnet.cz> wrote:
What about some semi-automated solution like this:
1. RIPE NCC would scan all the secure delegations for CDS records 2. if CDS is found and it differs from ds-rdata attribute in the database, then: 3a. if special maintainer is there, do the update 3b. if special maintainer in not there, send an e-mail to zone-c saying:
"Hey, we've noticed you would like to change the DS records for your zone 2.0.192.in-addr.arpa. Please update your delegation in the RIPE database here (link). If you want to have updates done automatically, add this mnt-by: attribute to your domain object"
That has the advantage of picking up old delegations by people who do not use webupdates very often :-) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Thames: Northwest 4, backing west 5 to 7. Moderate, becoming rough in north. Fair. Good.
OK, now we have got the ICANN and IETF meetings out of the way, what are the next steps to make progress on this? Do we need a formal proposal and if so is there an example I can clone and hack? Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ oppose all forms of entrenched privilege and inequality
Am 14.11.18 um 12:39 schrieb Tony Finch:
OK, now we have got the ICANN and IETF meetings out of the way, what are the next steps to make progress on this? Do we need a formal proposal and if so is there an example I can clone and hack?
Hello, I've no proposal but like to announce support. I've some networks I could use to test hacked stuff :-) Andreas
Tony, On 14/11/2018 12.39, Tony Finch wrote:
OK, now we have got the ICANN and IETF meetings out of the way, what are the next steps to make progress on this? Do we need a formal proposal and if so is there an example I can clone and hack? Thank you for pushing this forward!
I can't think of any examples of such a request exactly, but I am happy to be corrected. Generally we leave the details of exactly how stuff works up to the RIPE NCC, and I think that makes sense for any request about RFC 7344 support. My own thinking is that we can request update & deletion support immediately, since those are clearly specified, but that we need to think a bit about what recommendations we can make for bootstrapping adding DS records, if we want that at all (I think we do, but reasonable people may disagree). Perhaps the RIPE NCC can use RIPE Atlas to get a widely distributed view of a given domain to ensure that any new CDS records are the same across the entire delegation, and if those stay stable for a while (72 hours? a week?) then create a new DS record? Cheers, -- Shane
Shane Kerr <shane@time-travellers.org> wrote:
Generally we leave the details of exactly how stuff works up to the RIPE NCC, and I think that makes sense for any request about RFC 7344 support.
That makes things easier for me :-)
My own thinking is that we can request update & deletion support immediately, since those are clearly specified, but that we need to think a bit about what recommendations we can make for bootstrapping adding DS records, if we want that at all (I think we do, but reasonable people may disagree).
I would be happy with just RFC 7344 updates and RFC 8078 deletion, but I agree RFC 8078 bootstrapping should be a goal. The implementations at CZ.NIC and SWITCH have full RFC 7344 and RFC 8078 support. https://www.nic.ch/export/shared/.content/files/SWITCH_CDS_Manual_en.pdf https://ripe75.ripe.net/presentations/123-CDNSKEY-FRED-KNOT-RIPE75.pdf The timings are different, though: SWITCH requires consistent results for 3 days in all cases; for bootstrapping they also require consistent results over TCP from all nameservers. CZ.NIC does updates as soon as a daily scan finds CDS/CDNSKEY recrods requesting a change; bootstrapping requires 7 days of consistent results over TCP from all nameservers. (I think I prefer the CZ.NIC timings.) The usual RIPE database change notification emails should occur for CDS changes - cf. the CZ.NIC notifications. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Fisher: Variable 3 or 4, becoming southeast 4 or 5 later. Slight. Fair. Good.
Tony Finch:
I would like to help get RFC 7344 support into the RIPE database, so what do we need to do next to make it happen?
I would also like to help. I added ds-rdata for one of our networks into ripe-db. but as I need full write access to the objects, our ripe people where not amused. So CDNSKEY seem to me a more convinient way. Andreas
On 17. 10. 18 16:51, Tony Finch wrote:
At the end of his talk at the RIPE meeting this morning, Ondřej Caletka mentioned his work on automated updates to DNSSEC delegations using CDS records:
https://ripe77.ripe.net/programme/meeting-plan/dns-wg/
I commented at the mic to say that this is something I am very keen on. I wrote `dnssec-cds` (an implementation of RFC7344 and section 4 of RFC8078) to help improve DNSSEC automation, and it is included in BIND 9.12 and later.
https://ftp.isc.org/isc/bind9/9.12.0/doc/arm/man.dnssec-cds.html
Ondřej's setup uses a special `mntner` with RIPE database API access to indicate which zones should have their DS records updated automatically. This is a nice way to control permissions when the update process is running outside the RIPE database, but I expect it can be made neater if it is integrated more closely.
I would like to help get RFC 7344 support into the RIPE database, so what do we need to do next to make it happen?
BTW scanner tool (for registry side) is available from https://github.com/CZ-NIC/fred-cdnskey-scanner -- Petr Špaček @ CZ.NIC
participants (6)
-
A. Schulze -
Jim Reid -
Ondřej Caletka -
Petr Špaček -
Shane Kerr -
Tony Finch