You are here: Home > Participate > Join a Discussion > RIPE Forum > DNS Working Group > [dns-wg] automatic DS record updates in the RIPE database
RIPE Forum v1.4

DNS Working Group

Threaded
Collapse

[dns-wg] automatic DS record updates in the RIPE database

Tony Finch

2018-10-17 16:51:27 CET

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 _at_ dotat _dot_ 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.

Jim Reid

2018-10-17 17:08:29 CET

> On 17 Oct 2018, at 15:51, Tony Finch <dot _at_ dotat _dot_ 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.


User Image

Ondřej Caletka

2018-10-17 18:40:43 CET

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.

A. Schulze

2018-10-18 07:26:58 CET

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



Tony Finch

2018-10-22 15:58:30 CET

Ondřej Caletka <Ondrej.Caletka _at_ cesnet _dot_ 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 _at_ dotat _dot_ 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.
User Image

Ondřej Caletka

2018-10-22 16:40:19 CET

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

Tony Finch

2018-10-22 18:27:49 CET

Ondřej Caletka <Ondrej.Caletka _at_ cesnet _dot_ 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 _at_ dotat _dot_ at>  http://dotat.at/
Thames: Northwest 4, backing west 5 to 7. Moderate, becoming rough in north.
Fair. Good.

Tony Finch

2018-11-14 12:39:27 CET

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 _at_ dotat _dot_ at>  http://dotat.at/
oppose all forms of entrenched privilege and inequality

A. Schulze

2018-11-14 21:29:14 CET


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

User Image

Shane Kerr

2018-11-26 15:04:32 CET

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

Tony Finch

2018-11-26 16:43:04 CET

Shane Kerr <shane _at_ time-travellers _dot_ 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 _at_ dotat _dot_ at>  http://dotat.at/
Fisher: Variable 3 or 4, becoming southeast 4 or 5 later. Slight. Fair. Good.

User Image

Petr Špaček

2018-11-29 17:36:23 CET

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