 And this is promising to be a really interesting session. Q came up with a solution for a problem that I personally have. I run quite a few websites. And I always go to one of those commercial registrars. And of course, they sell out. They sell out to larger firms doing the same stuff. And then they triple or quadruple the prices. And it's pretty hard to get away from that because you've invested quite a bit into what's running there. And I always hate that. And I didn't find a solution for that. And she did. So that's why we're here. But if I read this correctly, Q, then that means that I'm still happy and just a bit an old grumpy man complaining about commercial stuff. Sorry, that's grumpy old man for you. But you actually found a solution. But I'm not sure if I read this description with all the extremely cursed details of how exactly one sells and manages a domain, if that got you really happy. So I'm really curious about that. So without further ado, people, Q. Morning, everyone. It's a surprising amount of people here for 10 o'clock on a Saturday. I presume you either all went to bed at a reasonable time or aren't really awake right now. There are two options. I'm suspecting most of you aren't really awake right now. So you've all come to a talk on internet infrastructure. So prepare for some cursed details. This is a tweet I saw a couple of weeks ago. If you can't read it, I'll read it out. The first tweet was, someone asked me what's behind all the doors in the locomotive. So I started opening all the doors and explaining it to them until they asked me to stop. And then the quote tweet is, me, when someone innocently asked how the internet works. And this is what you've all done today. You've innocently turned up to a talk about how the internet works, and I promised you will have knowledge you wish you didn't have at the end. So to start, we're talking about a domain registrar. But really, we have to first define what even is a domain. I mean, you probably all have bought the domains in the past and have an idea of what is a domain, but there's a lot more to a domain than may appear from first impressions. Because you're buying an entry in the DNS root, not in the DNS root zone, but in the IANA DNS system. But you will need a lot more data to go with it to manage all the business processes of who owns that identifier in the domain name system. So even though you think, oh, it's just my identifier on the internet, there's a lot more that happens in the background that needs to happen to be able to keep this system functioning at the scale that it does. Although sometimes I question how it functions, given how some of this works. So starting at the top for how a domain works, you have ICANN and IANA. IANA is a division of ICANN, but didn't use to be some very complicated history behind this. But they manage various different assignments on the internet. One that are relevant to us today are DNSSEC and the DNS root. And ICANN through IANA delegates the DNS root to different providers, which are called top-level domains. They're generally managed by for-profit entities called registries. They don't sell directly to customers, and you have to go via registrar. So you can't just go straight up to Verisign, who own .com, and say, hello, Verisign, can I have a .com? They won't do that. They'll just ghost you. You have to go there. There are very strict processes for who you have to go through to get an entry in DNS for what you want. The registrars, which is what I am and what I'm here to talk about, sell domains from multiple registries. They often bundle other services with the domain. And this is the primary customer-facing view of the domain name system. So you probably know the likes of GoDaddy, Namecheap, whatever. And you've probably all used at least one of them to go buy a domain. And so you've seen how registrars interact with customers. But why even bother with a registrar if you could just go straight to Verisign or whoever else controls whichever TLD you want and buy the domain you want? The main reasons are the registries are lazy and don't want to deal with customers. So they offload customer service to the registrars. And secondly, customers are stupid. They have no concept of how this works. So in general, someone buying a domain they don't need to know how this whole chain of icon to the registries to the registrar works. They can just go to their web hosting provider and buy a domain. And then their registrar can talk to all the registries they need for the various top-level domains they want. So it consolidates everything in one place and keeps all the customer service in one place. And then icon and the registries are left to do their important technical work of maintaining the internet. How do you keep track of all these relationships? Well, there's a system called Whois, which you've probably, I'm guessing, most people here are familiar with Whois. If you aren't, it's cursed. It's a terrible protocol. We're kind of slowly getting rid of it. But there's very little standardization. But it's effectively just a query language to a database where you can send one string of text and get back some more text. And this is until relatively recently how we've kept track of all these relationships between the different entities in owning a domain. But we're working on it now as the domain. We're working on replacing it with something called RDAAP. So as the icon community, I guess is the phrase, we're working on replacing Whois. But because it's proving so incredibly difficult to keep track of this complicated chain of relationships with the Whois protocol, which wasn't designed for this. It was designed in the 70s. And it scaled surprisingly well, but hasn't quite scaled well enough. So how did we get to this ludicrously complicated situation? So history time. Back in 1991, or before 1991, when it was still ARPANET and the project of the US government and Department of Defense, the whole domain name system was managed by one guy called John Postel at the Stanford Research Institute. The way this was managed is documented in RFC 920. If you'd like some further reading on how the domain system used to work and how we ended up with the situation that we're in, it's a good place to start to see how we ended up today. But this was getting, by the 1990s, the internet was growing massively commercially. And this was getting impractical for one person at one university to manage the entire domain name system. So then in 1991, network solutions was given a contract by the Department of Defense to run internet, which was the first internet numbers and names registry. So they pretty much did everything that ICANN and the registry and the registrars do today. They just ran the whole system. And then you could ask for domains from them. And they were free in those days because the Department of Defense funded this because this was still the US government project. In 1995, the growth of domain names in the commercial area outside of military applications was significant. It was so large that the Department of Defense decided they can no longer fund registrations outside of .mil. So only military people get free domains now. And that's why you have to pay for all your domains. And I'm sure you have a load of domains that you pay for that you absolutely intend to use for projects in future. And I slowly draining your bank account. That's not the Department of Defense's bank account now. And then in 1998, this was again, didn't scale well. So we had to try again. And ICANN was created. And this ended the monopoly of one company on all domain names because ICANN managed the DNS root zone and then delegated to different companies to manage the registry and registrars. And from 1998 until about 2013 is how we designed the model that we've ended up with today of the three-tier system of how a domain name is managed. In 2016, the Department of Commerce as had taken over the Department of Defense contract ended its contract with ICANN, so completely handing over control of the internet to the private sector. Some people don't realize that the US government was involved in internet policy until relatively recently, 2016. But that's, I guess, how weird history things hang around until someone realizes, oh, we should probably fix that. And a subnote to all of this, country co-top level domains have been doing their own thing since the beginning because these were always delegated to the country and not to specific companies, although the country often then delegates it on to a company. So country co-top level domains are things like .de.ll.uk instead of the generic top level domains like .com, .net, .org, whatever, which are entirely privately run, whereas country co-top level domains are often sometimes privately run, sometimes run by the government, sometimes run at cost by a private entity for the government. It's a bit of a mess. Every CCTLD has its own rules, and it's very annoying to deal with. So back in about the start of 2020 in the lockdown, I had nothing to do. And I thought, ha, I wonder if I could start my own domain registrar and then went and did that. This was a mistake. It's taken up so much of my time, and I've enjoyed it, but I recommend don't do it yourself. It can get very unfun at times. So step one is get a company, which is thankfully quite easy in the UK. Most registrars, registries, won't talk to you unless you are a company. Some will take individuals, and at the end, they'll get on to how you might be able to do this yourself if you'd like to. But in general, you need a company. Thankfully, it's easy in the UK. I send about 12 pounds to the government, and then a few hours later, a company exists. So then I can start getting access to registries. This is annoying bit, because this isn't documented anywhere how you get access to registries. You just have to look up, say, whoowns.com, and try and find an email address for them, and then just say, hello, can I sell domains from you? And sometimes they don't respond to it. Sometimes they do. Sometimes they have weird requirements for what you have to do. And it takes weeks, months sometimes to just sort this out. This is the really boring business stuff that has to happen before any money or anything can change hands to actually register a domain name. This is a slightly redacted copy of the contract between me and Verisign for .cc and .tv. I have hundreds of pages of these for every single top level domain I have to sell. They're really annoying to read. They're just, ah, I hate this. It's the worst to deal with. And it just keeps getting worse, because then once you've actually negotiated access to the registries, most of them require you to do some form of testing to show you are competent in the protocols that they use to manage domain names. Each of these tests generally takes between an hour and six hours to complete. And most of them have to be done manually if they can't exactly be automated because every single registry has their own testing system and they want to test different bits. So this isn't standardized. You just have to sit down and throw commands at them and then email them to say, we did these commands. Here's the responses that we got. And then they say, OK, looks like you know what you're doing. And then they let you actually have access to the registry. This is a first page of the testing document for Switch, which is the Swiss Institute that sells .ch and .li domain names. This is actually public on their website if you'd like to go read it. I can't exactly say it's a fun read, but it's suddenly interesting. And then after this, consider your actions because only now did I realize how much of a big task I'd got into because once I got access to everything, then I was sent all the manuals for how things work and how absolutely cursed every element of managing a domain name is. There's one of these kind of manuals for every single extension. They're between about 100 and 300 pages long, and you need to read them before you're able to actually properly sell a domain name and you need to implement all the processes in this manual into your system before you can actually manage them. So for example, here is a simplified diagram of a domain name lifecycle. Let's see if I can use my mouse as a pointer. So it starts off in available because nobody's registered it. And then you can register a domain name and it goes into the add grace period, which is usually about five days. And then if you delete a domain name in there, you're refunded the cost of the domain name and it's immediately available to register again. I'm not entirely sure why this exists as a system. I think it's a, oh, I didn't mean to register that. Let me undo it. Although no registrar tends to expose this to their customers because there's generally a limit of, I think, 90% of your domains you have to register. You have to keep. You can only use the grace period on about 10% of them. And registrars wouldn't want to offer that to their clients because then people would just keep buying domain names for random things and canceling them before they'd have to pay. And that would eat into their 10% buffer of accidental registrations or whatever. And then after five days of the add grace period, it goes into the normal registered state, which is the default state of domain name is in 98% of the time. You can then renew it. And it goes into the renewal grace period. And after five days goes back into the registered period. If you delete it on renewal, then you get refunded the cost of renewal. Or if it gets transferred after you've explicitly renewed it, you also get refunded the cost of the renewal because the transfer includes, by default, one year of renewal. You can do more. Sometimes this isn't supported. But when you transfer a domain name from one registrar to the other, you have to pay the cost of one year's renewal. This is mostly, I believe, so the registrar can pick up a bit of a margin on that renewal to cover the cost of dealing with the transfer. There's also the whole transfer system is complicated because you can transfer from both sides. So either you can push it to you from the old registrar to the new registrar, or the new registrar can pull it from the old registrar. And sometimes ICANN does a transfer themselves when you're doing bulk transfers between registries or registrars. So say someone's been a sub-registrar of someone else and then started their own registrar, ICANN might force over all the domains from the old registrar to the new registrar without any involvement of the other two parties. So that gets easily complicated. And then right at the end, there's this weird redemption grace period thing where if you delete a domain, it's not actually deleted until 45 days later. And you can pay a usually quite substantial charge of about 10 times the yearly fee of the domain to restore it back to the normal registered state. This is, again, mostly just a way to extract money from people who accidentally delete domains that they didn't intend to. And then after the redemption grace periods, it then goes into pending delete where you can't do anything with it for five days. Back to available to register. This is for normal TLDs. There are TLDs that are different, which is most of them because, of course, there are. So there's a few examples here, but it's mostly the country codes domains which are different because the generic top-level domains have explicit contracts with ICANN, which specify a lot of how this has to work, whereas country code domains have no formal relationship with ICANN at all, so it can do whatever they want. .ke, I know, for example, processes updates manually. So when you send them an update command, that then just gets logged as an email for someone to go update the zone file. This has resulted in mistakes in the zone file multiple times for me, where they've typo the name server or something, and then I have to email someone to say, what have you done? .ch and .li don't actually support explicit renewal. They'll just renew automatically unless you delete. .uk doesn't let you delete domains. You just have to let them expire. .de is weird in every single way. .is doesn't really do the whole registrar thing, but you kind of can do it if you do some weird things. But they also, some of the commands rely on emails coming back and forth. So in one of my pieces of code, it sends a command to the .is registry who then sends an email back to me, and then I have to have something go read the email and pull a link out and navigate to that link for the command that I've sent to them to get actually complete, which this is very not, well, what's the word? This breaks easily. And all the other domains are slightly weird. .eu keeps different kinds of contacts for different things. So normally you can create one contact in the domain name system and then use that for every single contact field, like the admin, the technical, the billing contact. .eu requires you create different kinds of contact for every single thing that you want to put in, which completely breaks standard. And so education is everywhere. So enough about the business processes. How do you actually talk to a registry? Most, if not all, there are exceptions. Use the extensible provisioning protocol, which is a wacky XML-based over raw TLS spec for managing objects. It's designed for domains, but also designed in a way that you could use it for any other database objects, which means it's got some weird things in there and it's not simple to implement at all. There are many RFCs. These are just the ones that are registered with IANA. There are also everyone has their own extensions that are usually poorly documented or conflict with other people's extensions. So the main EPP is internet standard number 69, which combines RFC 5730 to 5734. And then there are various extensions for things like the registration grace period, DNS sec mapping, launch phase mapping, change poll extensions, fee extensions, login security extensions, and maintenance notifications. So you can get over the EPP session non things which aren't related directly to a domain. So you can get a notification from the registry saying, hey, we'll be doing maintenance at this time. I know of one registry that implements it, which is GoDaddy registry. It would be really nice if all the other registries implemented it so I don't have to manually pass all their emails to put the maintenance into a calendar. EPP is a cursed protocol. You just open a TLS session, then spew two bytes of length, and then XML. You just throw XML over raw TLS, because apparently that's the same way of doing things. But with a tiny little bit of binary encoding, just to mess with things even more. It's not raw. It's not just text. Every message is preceded with a few bytes that you have to deal with manually. Of course, this is completely unlike any other wrapping format that exists, because, of course, we had to go invent our own. So let's have a look at how an EPP session might work. So when you first connect, you get the greeting from the server, which tells you which server you've connected to and what time the server thinks it is. So you can see if your clock is in sync with the server or if the server is wildly misbehaving or something. Then you get a list of objects you are out, your eyes, or yes, object namespace, your eyes. These are the objects which the server says, you can manage these types of objects over this EPP session. So here we have a relatively standard one which just says you can manage domains, contacts, and hosts, which are name servers. And then you also have a list of extensions which can be used on these objects. And this server supports DNSSEC, the registration grace period, launch phase of two different versions, internationalized domain names, which we'll get on to later, and the fee extension. So you can query how much a domain will cost you to register, because not all domains under a TLD have the same price. Some of them, like if they're two characters or something, they might put up the price, because that's a more desirable domain name. So you need a way to query how much that costs. Then to log in, you send a login command with your client ID and a password. This is the only authentication. It's just username passwords to access the whole thing. As long as you know the server you're talking to, you don't need any fancy authentication to talk to most registries. Some of them do mutual TLS, but not most of them. Most of them will just accept any certificate, whereas a select few will require that you have the specific certificate issued to you. This isn't very secure, because the password is also limited to eight characters by standard. So yay. And then you send, here are the objects I would like to manage on this session. So then the server knows what to expect from you and whether you've accidentally sent something malformed. It'll know, well, I wasn't told that we were going to be managing this object, so I'll assume this was an error. And then because this is a command and not just the greeting, it comes with a client transaction identifier. This is how you identify responses to your commands, because it's just a TCP session that you're sending XML back and forth over, and you can send multiple commands in one go and then wait for all of them to get a response. You don't have to send a command, wait for a response. You can send five and get five responses. So every command has a client transaction identifier, so you can identify in response to which command did this response come from. And then hopefully, if you've got your login right, you get a 100 error code, no, 1,000 error code, and command completes successfully. And you've logged in, and now you can manage domains. And here you've got the client transaction identifier that you sent back and the server transaction identifier, which you can log, say, if you sent a command and it didn't do what you expected, you'd then be able to contact the registry and say, hey, this server transaction identifier, what happened here? Something weird happened. You can also get messages from the registry, so they can notify you about things, such as, oh, this domain was renewed, or this domain is requested to be transferred out, or we updated this domain from our end. Please update your records accordingly. And you do that by sending a poll command with request, and then you either get a 1,300 or 1,301. A 1,300 is, there are no messages for you. 1,301 is, there are messages, and the messages included within it. So yeah, 1,301. And then you get a message, which says, there's one message in the queue. This is the identifier. This is when it was put in the queue, so you can see how old the message is. And then in this example, I've put a change poll in, which is switch telling me that they've updated the DNSSEC settings on the domain automatically via the DNSSEC extension. It says, we've added these DNSSEC keys to your domain for you. For some reason, EPP calls DNSSEC-SEC-DNS. I have no idea why. Someone at Verisign decided that about 10 years ago, and that's what stuck. So moving on with DNSSEC, this is very complicated to get right. And it's even more complicated when you're dealing with the CURSE protocols that manage a domain name. Everyone, I'm sure, has accidentally broken something by just deploying incorrect DNS or incorrect DNSSEC. Then you have to wait for the time is to expire, and all the signatures to expire, and then things work again, and there's not much you can do. So for those unaware, DNSSEC is a way of chaining trust from between name servers. So you have up here the root zone key, which is managed by IANA. And that's the trust anchor. And then via various keys and records, you can build trust from the root to .NET to your website. But you need to set up this DS record, which says, oh, yeah, this DNS key here for this zone, this is the DNS key that should be trusted to be authoritative from this zone, and then that's signed by the parent zone. But if you put any typos or any mistakes in these, then everything breaks because everyone thinks, oh, this server is impersonating the domain and ignores the records. So there's a way to manage this, which is relatively recent in the domain registrar space, which is a CDS. So you have a DS record, which looks like this, which contains the key ID, the algorithm, and the hash. And then you can... But that goes in the parent zone, like an NS record would, whereas a CDS goes in the child zone, hence child at the start. And you can just publish this in your DNS zone, and then your registrar can pick up on this record published in your DNS zone and automatically configure DNSSEC for you. The hope is that bind and not and the various authoritative domain servers will automatically start inserting CDS records, so then all you have to do is tell your DNS server, enable DNSSEC, and then the DNS server can sort out configuring everything for you automatically. There are a few problems with CDS, notably the first being, how do you know that the request is legitimate? Because the zone isn't signed yet, so it's not clear, it's not obvious that the request to add this signature to the zone is legitimate. It could be someone trying to impersonate that name server and saying, oh yeah, add this signature to the zone, and then someone else has control of the DNSSEC keys for your zone, and there's nothing you can do about it. The RFC on this offers a few solutions. There's accept policy via authenticated channel, which is you publish a CDS record, and then you can tell the registry, I've just published one, go fetch it now, instead of them constantly trying to find one and just in putting in any one they find. There's accept with extra checks, which can be, say, checking that all the name servers respond or checking the name server globally to see if it's a local hijack that could impact this, except after delay. So you might notice the CDS policy, send an email to the registered domain holder and say, oh, we're about to update your DNSSEC in five days with this new policy, which is what that earlier message from Switch saying, we've updated your DNSSEC policy, but you do get one earlier saying, we're about to update your policy. Then there's also accept with challenge, where they will send you an email saying, we found this DNSSEC policy, would you like to add it and won't do anything until you explicitly click yes? And then there's also accept from inception, which is you set up the DNS zone on your server before you buy the domain, and then they look immediately when you buy the domain for a CDS policy and apply that, so then the domain is never insecure. There's also this wonderfully named ITF draft, they can never come up with short names for this, for DNSSEC bootstrapping, where you can put a copy of the CDS record in a special signaling zone on the name servers. So if you wanted to set up, say, DNSSEC for Glauco.space, but the name servers are NS1 and NS2.as217.960.net, you can add the CDS records into Glauco.space and add a copy of them into underscore dsboot.thedomain.signal.thenameserver, and then because this is a signed, you have the signatures, the RR6 here, which signs these, you know that this is trusted because the domains, the name servers that are registered with the domain have their own DNSSEC chain of trust and have signed the CDS records to say, yes, I do actually want these CDS records to be put into DNSSEC. So then hopefully, once all these things have been standardized, you'll be able to just, DNSSEC should, just automatically enable itself on all your domains, hopefully. Now moving on to UTF-8 domains because the internet was designed by a load of Americans who did not have much consideration for internationalization. So we have to do some weird things to get a UTF-8 character into a domain name because the standards quite explicitly say for DNS that you can't have anything above ASCII 127 in the domain. Despite technically allowing that, it causes problems. So we decided against putting Unicode straight in the domain name system. So there's a system which goes via various names. It has too many names, but you probably know it's either Ponycode or IDNA or internationalized domain names and applications. This is an older standard than you think. It was first properly supported around 2003 in these now ancient pieces of software. Who would have thought Internet Explorer 7 would be a forward-thinking piece of software and supporting Unicode, but there you go. So this is how a record is encoded in a domain name packet and it's length delimited. So you have like eight characters and then the character string and then three characters and then the character string for the next label. The dots you type in when you type in the domain name never make it into the DNS packet because it's length delimited. So in theory, you could put Unicode in here, but too many systems take this and turn it back into ASCII and then just blindly assume it's ASCII and that would break things because of course it would because nobody actually obeys the standard correctly of this is just some byte strings. Everyone just assumes it's text because that's all anyone has ever seen it has. So let's look at how you encode a domain name as UTF-8. So let's say I have this domain name. First, we split it into the labels because that's how they're transmitted on the wire. So the actual dots aren't in there. We split it into the labels that will be transmitted in the DNS packet. Then if something's ASCII only, we just leave it alone, don't do any processing. Then if something does have Unicode in, we have to actually do something to it. First step is to normalize it using the very long preparation, enforcement and comparison of internationalized strings and applications protocol. This just makes sure that whatever someone has typed in, it always results in the same domain name lookup. So you wouldn't have being able to type in one string one way and it would come out to a different website than typing it in the other way. In this case, all it does is lower case is the B, but in some of the cases, it actually makes more use, it actually does things differently. So there are two ways you could say type this character. You could just type in U plus E7, Latin small letter C with Sedilia, or you could put in a C and the combining character. Both of these are valid and will render identically and it's impossible to tell them apart unless you actually look at the Unicode byte string. So depending on how someone's typed it in on their keyboard, it could be one of these two ways. Then you need to normalize it to be able to get a consistent domain name at the end. Once you've normalized it, then you can actually start encoding it, which uses something called ASCII-compatible encoding. So first you add the prefix Xn dash dash, which can never appear at the starter domain name normally, so that tells the system this is a Unicode domain treat it differently. Then you put everything that's already ASCII in place and store everything that isn't ASCII elsewhere. This is done for efficiency reasons because it is longer to encode every character differently than it is just to put the character in place it was already valid. And then you put another dash at the end, which is the basic code point segregated. The basic code points are ASCII, everything else is Unicode and is encoded differently. So then we have to put code point 252 in position one, which gives us a delta of 745. I have some slides to explain how this works, but you just calculate the length of the string times the code point minus x80 because that's where ASCII stops. So you don't have to encode, so it starts encoding at 128 instead of having to skip through all the first 127 characters because you know they won't be in the bit afterwards and then position one, so add a one at the end. So the way this works is best to look at from the viewpoint of the decoder. The decoder will step through every possible spot in the domain and see, could I insert a Unicode character here? So it starts on iteration zero and the test code point is 128 because it's zero plus x80, which is where non-ASCII starts and it sees do I insert it in position zero or do I insert it in position one, two, et cetera? And then the delta is how many iterations of this has the decoder gone through? So then it has to go through, it will just keep going through many different code points until you get up to eventually iterate delta 744 and then delta 745 and you see the delta we calculated earlier is that delta. So it says, ah, we put this character in there and then, so that's what the delta means and then you use something called base 36, generalized variable length integers to encode all the deltas you calculated for the different characters at the end. So in this case, 745 gets encoded as KVA. I couldn't come up with the decent way to explain how generalized variable length integers work. There are docs on the internet. I struggle to understand them but effectively you can put together just characters and it's possible to tell where a set of numbers stops. So you don't have, it's because you could, like if you have 11 and 11 and you put them together that could be the two 11s or 1,111 and it's not possible with normal integers to tell apart where one integer ends and the next starts with variable length integers, it is possible. So it's not quite base 36 but it's mostly just base 36 encoding of the list of deltas at the end of the domain name and then you can join it all up and you end up with this at the bottom which is what actually gets registered as the domain name. Right. So now some more on the whole move from who is to Rdap. What's wrong with who is? It was designed by English people so has no provision for anything other than English. It doesn't specify character set. It doesn't specify anything to signal what encoding anything is in. Everyone just assumes it's ASCII although sometimes it isn't and there's no standardization on how to do this so it's a pain to deal with. The who is protocol has absolutely no provisions for security which is great when you're dealing with people's personal data. The Rdap protocol does add in security and ways to authenticate requests but it's still a work in progress on how this works. Who is just blindly and well until GDPR really just blindly throughout everyone's personal information for every single domain name in the world. It's also really difficult to pass because these are two different example who is responses, one from Denick and one from Verisign. There's no format standardization between the two of how to do this and this is just tax. It's easy enough to read but good luck getting a computer to pass that. So recently we've been moving towards Rdap for this which is based on REST and JSON which, yeah, JSON's all right. I mean it's passable and has some semblance of security. So then you can just make a HTTP request to the Rdap server and use all the authentications that stuff that you can normally use with Rdap and just get back an easily passable JSON which contains all the data you want structured which is much nicer for everyone and means we don't have to deal with weird data errors when something isn't in the format we expect. So Rdap isn't perfect though. As mentioned, the security elements are still a work in progress. It's a bit difficult to figure out how this whole business structure of ICANN and the registries and the registrars works out so they can authenticate to each other over Rdap and also law enforcement, of course, they like to get involved and they want access to this information. So ICANN is trying to figure out a way to allow them to authenticate and get the more private Rdap information. Rdap also just uses vCards which is another standard which isn't very passable but is vCards represented as JSON. There's a move to move to something called jCards which is much more structured towards how JSON should work, vCards are just a nightmare to pass. And finally, how can you do this yourself? If after all of this you would like to run your own domain registrar or just have greater control over your own domains and maybe do this for a few friends, how can you do it yourself? First of all, don't, but here's how you can. So generic top-level domains require ICANN accreditation. So this is anything that isn't a country code domain. ICANN accreditation is generally quite expansive on the order of maybe 5,000 US dollars a year to maintain accreditation and you need to provide pages and pages documentation of how your business operates and how you keep your data secure. And it's all very sensible stuff because they don't want someone selling domains and then going out of business and suddenly, oh, no, where have all the domains gone? But it's not really manageable as an individual to do this. CCTLDs generally accept anyone. Some of them are a bit weird, but here are a few that will accept anyone no matter the volume they're selling. Verisign for .cc and .tv, .uk for nominates. Nominates is really friendly to individuals having their own accounts. So that's a great place to start. .ch and .li, which is switch. The Finnish one, the Montenegren one, which is ran by Affilius, not the Montenegren government for some reason, and .is for Iceland. These are great registries if you'd like to, there's a great place to start and they're generally quite okay with small businesses or individuals doing this. If you'd like more information about who to contact at these places to do things, come talk to me afterwards. There's also the software that I use to talk EPP. You probably don't want to have to deal with EPP yourself, so I open sourced my software. It exposes all the EPP stuff as nice GRPC, so you don't have to deal with all the XML stuff. You can just send relatively sane commands to the server and it deals with all the negotiating back and forth between the registry and you to get this working. It's on GitHub. There are docs. If you'd like more help with getting this started, I can also help. So I think that's everything. Come talk to me afterwards. If you have any questions or would like to do this yourself or just anything in general, I'm happy to talk about it. I hope you've enjoyed. Wow, that was insane. That is a great start to a great morning, isn't it? Let me check to the signal angel. We got no questions from around the world. We do have time for a few questions. I can take questions now, yeah? You can take questions. So questions on the mic in the middle, please. If the mic in the middle is on, could you just keep on talking? We'll check. Yeah, well, yeah, great, nice. Actually, I have two questions. Okay. I live in Holland, so I'm only interested for my own projects in the .nl. How feasible would it be for hobby projects to become an own rigid star? Yes, for just only one TLB. That's easily done. There are a few companies that only do one TLB. I believe .nl has the problem of there's a minimum charge of 40 euros a month. So unless you have 40 euros a month of domain names renewing, then it's more expensive to get an account directly with them. It may be that you just want to do this anyway and you can find that money, but they're generally okay about it. They just much prefer people with higher volumes, so we'll put a minimum charge on your accounts if you don't meet that volume. All right. And I'm not allowing a follow-up question. Sorry, because we have five people standing here and we have four minutes. All right, come talk to me later. Come afterwards, yeah, please. Thank you, Kiu, for the nice presentation. I used to work for a domain registrar. I was in charge of the DNSSEC rollout. And one of the things I had to look at was moving DNSSEC signed domains to another registrar. And it was mostly a theoretical exercise back then in 2018. And what we had to do was we had to figure out how to exchange public keys with the other registrar and then they had to include it in something. They had to include a new public key in the zone and have it signed and then move it that way. Is it still done like this way? Is it being used in practice? Well, so the difficulty comes, there's a difference between DNS and the domain name system. So if you're not changing DNS provider when you transfer a domain, there's nothing to do because the DNSSEC records will stay with the domain when you transfer it. The problem is most people also use DNS provided by their domain registrar. So what generally needs to happen is this is where CDS comes in because you could switch over DNS first and signal with CDS that you'd like these new DS records to be inserted into the parent zone and then later transfer over the domain name to, so because there's already a wait of about five days for a domain to transfer because the transfer can be revoked. So you could at the start of the transfer move over the name servers and you see the asset set up DNSSEC and then hopefully by the end of the five day transfer period all the DNSSEC will have sorted it out and it should work. This is again still very theoretical. I'm not aware of anyone who's managed to pull it off perfectly yet. Moving between name servers with DNSSEC is always a problem and this is why we're working on it but it's still not quite perfect. Multi theoretical, okay, thank you. Yes, first of all, thanks a lot for the presentation. We previously discussed a few other TLDs that had a horrible method of managing name servers and personal information by means of some shoddy word prescite or something. Are there other TLDs that still do this or is EPP the absolute bare minimum that you would be able to expect from a... You can pretty much expect EPP from anything that really matters. It's the small TLDs that do their own thing although most of them are moving to EPP now because it's been a standard for over a decade so people are finally starting to properly adopt it everywhere but 98% of the time EPP is what you'll be dealing with. Thanks. Hi Hugh and thanks for the talk. You mentioned earlier that EPP only allows for eight character passwords. Yes. What does it mean specifically? I'm assuming that you cannot put... You do not get from the registry eight arbitrary bytes. No, it has to be encodable in XML which generally means no weird... You can't even sometimes registries don't let you put the back tick in the password because that's an XML character. Even though you could technically encode it, sometimes it doesn't work. So the security here is less than ideal. Yeah, okay. Thank you for your questions and thank you for answering so concise. I'm sorry, I sent the others who had questions. There was a long queue of people with questions but I have to send them away because of that but please people, another big hand for Hugh.