RIPE 75 DNS Working Group Minutes

Wednesday, 25 October 2017, 14:00 - 15:30
WG Co-Chairs: Shane Kerr, David Knight
Scribe: Fergal Cunningham
Status: Draft

A: Administrivia

There were no changes to the agenda. The minutes from RIPE 74 were approved.

B. DNS Working Group Chair Replacement

Working group co-chair Shane Kerr said that Jaap Akkerhuis was standing down as co-chair of the working group. Shane thanked him for his many years of great service to the DNS Working Group. He also informed the working group that João Damas would be a co-chair from the working group after RIPE 75.

C. Review of Outstanding WG actions

54.1 – Update RIPE 203 along lines of previous presentation brought to working group

Shane said that this was a long-standing action and there has recently been progress made on the mailing list.

Peter Koch, DENIC, said that he and Carsten Schiefner had re-opened discussion of the document on recommended SOA values on the list and there were some comments from engineers. He asked that people talk to him or Carsten, or continue discussion on the mailing list. Shane said he didn’t see too much feedback but he would encourage people to get involved to get this moving again.

D. RIPE NCC Report by Anand Buddhdev, RIPE NCC

The presentation is available at:
https://ripe75.ripe.net/presentations/125-RIPE75_AnandBuddhdev_DNS_Update-copy.pdf

João Damas, APNIC, said he was happy to see the RIPE NCC considering not using HSMs because looking at the system as a whole, they appear little more than devices to cover your back and there are also problems such as vendor lock. He asked that the RIPE NCC let the working group know what steps it took when looking at vendors and what questions it asked them.

Benno Overeinder, NLnetLabs, commented on how grateful the community is to the RIPE NCC for testing software and products in the way it does and making the information available to the community

Stefan Jakob, DENIC, said he liked the 10G upgrades on the network side but asked how it was scaled on the server compute side. Anand said the idea with the 10G was to be able to absorb large numbers of queries coming in. He said it also helps to filter queries considered to be attack queries. Anand said he would be happy to talk about this more once the work here is further along.

Christian Petrasch, DENIC, said they didn’t get rid of HSMs because storing the key was complicated and he asked Anand if there were approaches to solving this. Anand said this was on their list to explore and they are also looking at the Cryptech project to help with this.

Shane asked about the RIPE NCC’s relationship with ccTLDs.

Anand said this is a difficult and an ongoing challenge but the new process of evaluating them has improved contact with them all. He said ICANN and AFRINIC helped as did other contacts in community. He said they are signing an MoU with them to formalise arrangements, and they will evaluate relationships on a periodic basis.

Romeo Zwart, RIPE NCC, said the advice at RIPE 73 was to evaluate the relationships on a yearly basis. He said it can’t be done on a yearly basis but every three years and this gives a good trade-off between effectiveness and the resources available to the team.

E. CDNSKEY Implementation with Automated KSK Rollover in Know DNS and the FRED Registry by Jaromír Talír, CZ.NIC

The presentation is available at:
https://ripe75.ripe.net/presentations/123-CDNSKEY-FRED-KNOT-RIPE75.pdf

Dmitry Kohmanyuk, Hostmaster Ltd., said FRED was very good and asked what they do when they email staff of domain owners and they don’t see it or reply.

Jaromír said they were working to make it easier to figure out whether to email the domain owner or technical contact and therefore make it less confusing.

Marcos Sanz Grosson, DENIC, said he likes it very much and asked if they were bootstrapping DNSSEC information. He said that is data where you can’t validate the chain of trust and he had concerns over this.

Jaromír said you can’t trust in that way which is why they implemented three things – the TCP connection to the authoritative name server; notifying the technical contacts; and maintaining the scanning for seven days. He said the combination of these three approaches should be enough to prove the intention of the real owner of the domain.

Marcos also asked if the data came to Jaromír in a trusted or untrusted way and Jaromír confirmed they were able to separate out the untrusted data.

Arsen Stasic, ACOnet, asked if CDNSKEY Scanner and FRED-AKM are also open source, and Jaromír said they were and available from their website.  

F. Living on the Edge: (Re)focus DNS Efforts on the End-Points by Benno Overeinder, NLnet Labs

The presentation is available at:
https://ripe75.ripe.net/presentations/111-RIPE-75-DNS-on-the-End-Points.pdf

João Damas, APNIC, mentioned the KSK rollover and how we’re still stuck. He wondered if the IETF should take more responsibility and put clauses in RFCs saying that things don’t become active until certain conditions are met.

Jen Linkova, IPv6 Working Group co-chair, said she was surprised we appeared to be solving on the client side what should be solved on the server side. She said thanks for saying this to DNS people because they are not always the people deploying IPv6.

Benno asked if Jen didn’t want this kind of support in the library and Jen said they needed it but it’s a workaround solution and the proper solution should be to make services IPv-6-enabled.

Jim Reid said he was glad to see this work in encouraging uptake of DNSSEC validation but he wondered if it would help long-term. He said we’re entering troubled waters for DNS, especially with what’s happening at the IETF, and with this and other factors taken into account, he asked if there was a future for validating stub resolvers.

Benno said there were different signals coming from industry with interest from some in having a secure channel from their stub resolver to the resolver. Jim commented that it would be great to get that into an iPhone or an Android application, and Benno said this was being discussed as well as other large companies.

G. Why DNS Should be the Naming Service for the Internet of Things by Sandoche Balakrichenan from Afnic

The presentation is available at:
https://ripe75.ripe.net/presentations/122-RIPE-2017-Sandoche.pdf

Shane asked what the reception to this presentation was in other venues and Sandoche said there was some skepticism because the audience was from the telecoms industry. Shane said he recognised this because telecoms, vendors and even government seem keen to develop a naming system other than the DNS for a variety of reasons.

Jim Reid had a similar observation to Shane and said that although the DNS seems like it should be anchor for everything in this regard, that might not actually happen. He noted, in relation to ENUM, that we tried something similar in the past and it failed. And he added that some alternatives might have advantages that are not currently available in the DNS.

Peter Koch, DENIC, agreed with Jim and advised Sandoche not to fall victim to the idea that there is a different Internet – the IoT is still the Internet. He said there should be some appraisal of new applications or classes of objects before seeing if DNS is not sufficient.

Jelte Janssen, SIDN, agreed with Jim but thought the possibly of someone making a proprietary system to create an identifier market was a good idea to promote the DNS idea.  He also said that the examples presented by Sandoche were mostly registry examples, which has little to do with how things are deployed in real life. Two ways you can use DNS in the IoT and this example is mostly registry and this is not about how things are deployed or used in real life.

Sandoche replied that it is under the existing domain name space.

Dmitry said that in 2000, CZ.NIC tried a rough idea to put things in the DNS and this idea is  similar, so people should look at the previous example to see what happened.

Z. Any Other Business

There was no other business. Shane thanked everyone for participating and said he hoped to see everyone at RIPE 76 in Marseille.