 Excellent. So welcome once again. I'm still Petr Szpaczek still work for CZNIC. No change in last half hour. I hope as far as I know. And this is yet another DNSSEC talk. So why we care about DNSSEC? Nobody's using it, right? Not really. It turns out that according to measurements from APNIC, about 19% of clients, DNS clients worldwide, is behind a DNSSEC validating resolver, which is quite good finally. In Europe, it's even better. It's like 24% of European clients. And I came from Czech Republic and in Czech Republic. We are very happy because we are at 63% of validating clients. And more than half of the authoritative or zones is signed as well. So we now say in Czech Republic that it's normal to have DNSSEC. So it's abnormal to not have it. Okay, so where is the problem? Why we are here? In DNSSEC, you sign your zone somehow. That's one part of the problem because the signatures have a lifetime in it. And it's in absolute value. So you have to update the signature so it doesn't expire. That's one problem. And the other problem is keys because you sign the zone and then you have to get the key to the parent zone somehow. And that's the difficult part. So where we are? Maintenance. Oh no, no, please don't add any maintenance to my workflow. I'm DNS operator and don't want to touch it. I have some good news. In 2019, it looks very good for signatures and updating the expiration and so on. It's very good because basically all the common software can handle it for you. I'm not sure about Microsoft DNS, but I assume that they can do it. I think that they can do that as well, but I haven't seen it in years. So basically anything you pick can take care of signatures. It will just work. That's fine. But then there is the other part of the problem which is more difficult. With signatures itself contain problem. You update your own data. That's it with keys. The problem is basically the communication because we have the child zone down there. That's us as operators. And then we have the parent zone, which is registered typically and we somehow get to somehow we have to find a way to get a public key from the child zone to the parent zone, which involves communication between like across the administrative boundary, I should say, which is always a problem because now it's a politics. It's not a technical problem, right? It gets even harder when there is three parties because you are the owner of the zone. Then there is the zone operator, which is like third party like web hosting company or something and the registry and typically the DNS operator, the third party DNS operator doesn't have any relationship with the registry like contractual. So the registry has no way how to verify that. Okay, they should upload this record or not and so on. So it was a nightmare, but in 2019 final things are improving even on this front. So standards to the rescue. It took some time because the root zone was signed in I think 2010, right? So like it took four years to or five years to realize that we should do something about actually making DNS like usable, but we are here almost. So can you see the cursor? Oh, yeah, never mind. I will describe. So the problem is that in the child zone, we have the public key, which is in form of hash of the public, sorry, once again, public key in child zone is in form of DNS key record. It gets hashed and the hash is in DS record, which needs to be put into the parent zone. So the new RFC or new from 2014 says that you can put the hash also in the child zone and then magic happens and the parent zone will take the value and install it into the registry. That's basically what RFC describes. So the idea is that now the child contains the DNS key, which is the full public key and the hash as well. And eventually the parent zone using some mechanism depending on implementation will take the public key and install it up. So the current process which actually works in practice looks like this. Thank you Cloudflare for the picture. I stole it from their block. So someone be domain owner or doesn't matter practically says I want to enable DNS. That's the number one. Then there is the DNS operator, the third party. The DNS operator will sign the zone or generate the key, sign the zone, generate the hash of the public key and publish this hash inside the child zone. It doesn't need to go to some weird in over some weird interface to the parent. It just puts a record in a zone. Then the registry which is the parent eventually finds out that there is the CDS record in the child zone. Do some registry specific validation and publish eventually the DS record in the parent zone, which means that now we solve the political problem using technical means. So we just published the record and the registry will do the right thing. Okay, so of course it needs support on the registry side. Right now it's fully supported by four registries. As far as I know, maybe there are some others I don't know of. It's CH, CR, CZ and LI. You can see that there is a cluster of TLE starting with C. So we hope to get more of these, especially one of them. More are coming, but at least at the DNS conferences, people from registry say, ah, we are looking at it and so on, but it takes time. If you want to say it, it wouldn't hurt if you email your registry and ask, well, what's your timeline for having this support? I have seen question. Go ahead. Okay, RFC, this one. Sorry, I have to repeat your question. What you should ask for? Ideally, if you email your registry, the text could be like, ah, I'm very pleased with your services, but it would be even better if you could enable my DNS deployment by supporting these two RFCs. You will find the numbers in slides. Okay, go ahead. Technically, it doesn't matter. It could be registry. It could be registrar, but from the TLEs listed here, the experience is that the registrars just don't care because it's more work for them. And if the registry does it, it's for free. They don't need to care. So the experience up until now says that it's easier for registry to do that. And registrars don't mind. Go ahead. Roy. Thank you. Could you go back to the second slide? Oh, second. Is it this one? No, no, no. The seventh. Sorry, the seventh. Oh, sorry. I misheard this. Yes. You say it's fully automated. And I like that. However, which of these do DNSSEC out of the box? So you have to configure it in order not to do DNSSEC. All right. The question is whether some of these software packages enable DNSSEC by default. And so you would have to actually disable it. As far as I know, none of them. You have to explicitly enable it, but it's like one switch. I will have it on the slide. Okay. Next question, please. I have a question regarding when you scan all your domains and you insert the DS record in the ZZ zone. Have you any complaints that somebody said, I just wanted to test it and you inserted it and I didn't want it? No. The question is whether there were some... Ah, you had a microphone. Sorry. No, I'm not aware of any, because you have to actively publish the record, right? And typically the process here when the registry or the parent is checking the child zone and in the box there is text verify ownership and validity of CDS, which is like super vague because it depends on implementation. But technically it means that the parent zone is using TCP to connect to all your authoritative servers to check that the CDS is actually there. It has consistent value and so on. And in ZZ we are doing this for one week in repeating the check. So, yeah, we think it's reasonably secure because if someone is faking TCP to all your authoritative servers for one week, you have bigger problems than this. It's like... A follow-up question. Do you also notify the owner of the domain that you have now enabled the NSSEC on your behalf? Yeah, we notify a technical owner because owner of the domain doesn't have any idea what the NSSEC is whatsoever. I mean, it's like one tenth of a percent maybe would know what the NSSEC is. And we were considering that and they were quite confused at the beginning, so we stopped doing that. And technical context know what's going on at least a little bit. They should. And a third question, and it would be my last one. Do we also use the CNS key or just CDS keys? Yeah, yeah, that's a very good question. Yes, I have CDS on slides, but you can publish also full public key in form of CDNS key. It's interchangeable as far as I know everyone is doing both because why not? It's like the same thing. So let's try to continue the presentation. But I encourage you to ask because then it makes way more sense, Aya. Implementation is software. Signing is solve problem or less. Implementation of the CDS like CDNS key support is differing in various software packages. Open the NSSEC as far as I know is planning to have it soon. Public DNS can do the first step. It will generate the key in the form of CDS keys and CDS records. And then you have to confirm, okay, now I feel strong enough to proceed with key all over and so on. Bind is basically the same. It will generate the public key in form of CDS record. And then you have to confirm, okay, I want to do the next step and generate new key and do all over and so on. In the DNS, which is my home authoritative server, we have the process fully automated, which is what I will be showing in the next slides. Okay, so how it works? The idea is that the authoritative server will automatically generate the key with parameters as configured or before once. And then it will periodically check the parent zone or resolve or whatever IP address you wanted to check. Whether the DS record was already installed by the parent. So you publish the CDS first, then the authoritative server is basically waiting, sitting there and waiting and repeatedly querying the parent side, whether the DS was installed already or not. And if it wasn't installed, it just waits and once it is installed, the clock will start ticking and it will roll over the key. So, okay, the configuration is quite simple. This I will try to... Okay, no, I can't handle Mac, sorry. So I will be pointing with the hand. So first option is DNSX signing on. That's all which is necessary to generate the keys, sign the zone and keep the signatures up to date. That's fully automated except this configuration. And then you need to specify the IP address which you consider trustworthy enough for you to give you the information whether the DS record was installed or not. So there is KSK submission upstream and the upstream is name of another configuration which is in here. And then there is a check interval. How often the authoritative server should check whether the DS is in place or not. And then there is a list, basically a list of IP addresses which should be checked. So we have auth, local and foreign. Auth could be, for example, IP address of your public-facing authoritative server. Local might be some local validating DNSX resolver. Foreign might be some other cloud resolver just as good measure. And the idea is that, okay, I didn't even need the pointer. So the thing is that you specify the IP addresses and then it will check all of them and all of them must match. Well, it will, let me explain. In log, it looks like this. You just enable the signing and then the first log line says KSK submission waiting for confirmation and at this point the authoritative server will start querying automatically the IP addresses and it is waiting until it gets the DS record which matches the data the server is expecting from the IP addresses. Once the DS is installed, it will wait for DST TLS measure, good measure and then it will log KSK submission confirmed and it will proceed. Typically, we have default policy which rolls the key every couple months. So if you configure this, you can forget about the NSA completely and it will do even the key rotation automatically because it can generate the key, new key, publish it, wait for it to be available to clients, then roll the key and so on and so on. Okay, other relevant features. The thing is that the very same process which is used to install the DS into the parent zone can be also used to remove the key from the parent zone. So you can publish CDS record with this structure with all zeros and eventually the parent zone will notice is that okay, there is this special CDS record and that's instruction for the parent to remove the DS record from the delegation. So you can go from DNSX sign to unsigned state using this and again, you don't need to click in any crazy web interface and send emails and so on. Of course, people have different requirements for key signing and monitoring and so on. So if implemented structured logging for key events, so if you have journal D from system to journal D or any other compatible logging system, it will spit out structured log events so you can have a script which is waiting for them and you will see, okay, this is new key. This new key was published in the zone. This new key was found in the parent zone. Finally, this new key is going to be retired and you can hook your own scripts using this logging feature. As I already mentioned, the keys are being rolled automatically because we can check that parent already have them so it's safe. Some future version will have the DNS update mechanism to push the DS records even sooner so which is not that useful for TLEs because they typically TLE doesn't accept DNS updates but if you are managing your own infrastructure inside your company and you want to sign the zones and you have a lot of delegations which is typical for universities or big setups, the DNS push or DNS update mechanism will help you with this so you don't need to implement the registry site and the authentic server will do everything. Okay, so in summary, there is really not a reason to scream because now everything is easily automatable. What we need is to get support in more software but that's on road maps so that's coming in couple months and of course the registries. So again, please try to your lovely registry thank them for their great service and demand implementation for these RFCs. So I hope we have some time for questions. Okay, so thank you for your attention. Question number four. So which TLDs which you have listed there also supported removal of DNS? I think all of them. Okay. But I'm not 100% sure but I think that the thing is that the RFCs are quite old. Let me find a slide. You can see that the first RFCs is from 2014 and the other is also two years old already. So when and all the TLDs or the feature did it recently. So they already implemented everything because it was standardised at that point. You mentioned that you have to provide the IP addresses of the zones to check why is this necessary? So wouldn't it be sufficient that not can find out itself who is the parent zone and query for the DS record? Let me turn the question to you. Would you as zone administrator would be comfortable with it? I mean if you tell me okay, we can implement it. Yes, so because you said now it's fully automatic but it is not automatic. The DNS operator still has to provide the zones which should be queried for the DS. Finding the parent zone is possible because every recursive does it and knows how it works. And using the standard system resolver of course this would work because this would find also the DS and the correct zone. The thing is that typically you want to do the NSS validation because you want to be sure that someone is not playing with answers for you otherwise the zone would break. And authoritative server is not the NSS validator unless it's bind. So that was the main reason why we went with this because it allows you to put validating resolver IP others in it and you don't need to get full DNS resolver implementation and validator into the... So you have to bundle it with a knot resolver with validation turned on and then you have to ask your bundled resolver. Yes, we don't like bind links. Actually that's what I did. I have an unbound running on local house with a TTL of 30 seconds and a queried for the DS of all the zones. I mean if you would be comfortable with querying just the authoritative it would be like okay-ish but still it requires some subset of recursive resolver right because the authoritative server doesn't know what's its parent right now because that's the job of the resolver. So now it would be more complex harder to debug and so on. So that was the main reason. Roy, please. Hi, similar to what I've asked before you basically are asking us to get in touch with our registries in order for them to implement this. I think that's a very good idea but I'm now reaching out to resolver operators, resolver developers and authoritative server developers to please switch on DNSSEC by default. Okay. That would tremendously help the deployment of DNSSEC everywhere and I understand the premise if one developer does this or one team does this then it's kind of a chicken and egg problem right if one developer does this then by default it will be slower because it now needs to do designing than every other. So maybe we should have a DNSSEC default flag day. And it is not just to you also to the other developers that are here ISC folk, Power DNS I don't know if you have device here I don't even know if it still exists but I think it's a good idea to start thinking about that. You have a point yes but it would help with DNSSEC adoption under the condition that the parents implemented this right otherwise the signatures would be just It's not a competition, you can do both at the same time. Yeah. I want to comment on the last question I think it's a terrible idea to turn on the DNSSEC by default in the authoritative service and I think you should do this if you want it, not by accident because this is a wonderful mechanism but it's very easy to turn the DNSSEC on but if you ever lose your keys you're screwed because then you're a user who doesn't know where the registry or registrar is and your zone is broken. Yes. And that's why I think it's bad to turn it on by default because it will ruin the name of the DNSSEC which is wonderful by the way. Okay. Thank you for your opinion. Roy would like to respond. Yes. That argument I've heard that many times if you happen to lose your keys well if you happen to lose access to your SSH server if you happen to lose this and if you happen to lose that if you happen to lose access to your keys maybe you shouldn't maybe you should switch DNSSEC off. The default I think still should be on. Anyway, we can argue until the... Yeah, we can have some fighting corner after the talk. It will be interesting. This is mostly a question about how the registries actually operate who do follow this. How do they do with the first key? It's not signed. Yes, with the first key this process checks for CDS for domain the number three on the picture is in our case which is CZ done by TCP we do TCP query to all the authoritative servers and we repeat the query for one week with some period and if it's there for one week we declare that it's good enough. Okay. Any other questions for Petter? Complaints, comments, no? Okay. Yeah, if maybe... You just connect from one place for one week so from the registry or you have like multiple IP addresses or multiple places where you check from? I'm not really sure about how it's implemented because I didn't do the implementation. Okay. I know that they were planning to do it from multiple sites but I'm not sure whether they actually do it. The code for it is open source in thread, right? Oh yeah, the registry software is called FRED and it's open source so look it up. You mentioned the algorithm roll over so how do you handle it exactly? Will you sign the whole zone completely with both algorithms? I don't remember details, sorry. That's so complicated that I'm not willing to give it off the top of my head. I'm pretty sure you have to. Oh, well not everybody does it right. Well yeah, it's done in a way which doesn't break validation but I'm sure of that but I'm not sure about the implementation details really. Oh, one more. Meanwhile, if there are operators with strong opinions whether the DNS signing should be on or off by default please let me know. Just a comment upon the algorithm roll over because I don't believe you have to but maybe if there's old software out there that require both algorithm change then you sort of have to. What we have in the DNS community is a liberal approach and a conservative approach and if you sure want to make sure that nothing breaks you'll take the conservative approach taking into account the old software that may be running and otherwise you can just do the liberal approach and switch the algorithms and you don't need full change for both of them. Thank you. Alright, thank you Petter. No strong opinions, thank you for your time.