WEBVTT 00:00.000 --> 00:10.000 This is the DNS developer room. 00:10.000 --> 00:13.000 I hope you know that. 00:13.000 --> 00:16.000 First speaker, Valentin, who will be talking about 00:16.000 --> 00:20.000 Get Other Info and other ways to resolve names. 00:20.000 --> 00:23.000 I hope you can hear from my heart. 00:23.000 --> 00:26.000 Hi everyone, welcome to my talk. 00:26.000 --> 00:30.000 Get Other Info sucks and everything else is much worse. 00:30.000 --> 00:33.000 First off, my name is Valentin Goshu. 00:33.000 --> 00:39.000 I'm a DNS enthusiast and developer on the networking team for Mozilla Firefox. 00:39.000 --> 00:43.000 I've been on the team for almost 11 years now. 00:43.000 --> 00:47.000 I spent a bunch of time maintaining our DNS stack, 00:47.000 --> 00:52.000 and especially working on our DNS over HTTPS implementation. 00:52.000 --> 00:56.000 I'm originally from Romania, but currently reside in Sweden. 00:56.000 --> 01:00.000 And you can reach me at any of these emails. 01:00.000 --> 01:05.000 As you'll see later, I'm a big fan of emojis. 01:05.000 --> 01:09.000 So, they're going to be a big part of the presentation. 01:09.000 --> 01:14.000 I'm also a natural introvert, so I'm not great at starting conversations. 01:14.000 --> 01:19.000 But if you have any questions, I'm quite friendly, so please come and say hi. 01:20.000 --> 01:24.000 Full disclosure. Yes, the title is clickbait. 01:24.000 --> 01:28.000 No yet, other Info doesn't really suck. 01:28.000 --> 01:33.000 Unless you want to use it for something that it can't really do. 01:33.000 --> 01:36.000 This talk might include some rent. 01:36.000 --> 01:39.000 And I really know what I'm doing. 01:39.000 --> 01:43.000 I'm just an user of these APIs that I'm going to talk about today. 01:43.000 --> 01:48.000 So some of you in this room may know a few things more than I do. 01:48.000 --> 01:52.000 And if I'm doing something wrong, just because I'm dumb. 01:52.000 --> 01:54.000 Don't be afraid to tell me. 01:54.000 --> 01:56.000 Yeah, so get other Info. 01:56.000 --> 01:59.000 It's been with us for a very long time. 01:59.000 --> 02:06.000 It originally was part of an IT people-edraft containing the socket extensions. 02:06.000 --> 02:13.000 And then it was imported in RFC 2021-33, and then updated a few times after that. 02:14.000 --> 02:17.000 Get other Info as a pretty simple API. 02:17.000 --> 02:26.000 These are the most important parts of it, apart from the stock adder struct. 02:26.000 --> 02:30.000 And so like what's great about adder info? 02:30.000 --> 02:32.000 First of all, it's simple. 02:32.000 --> 02:34.000 It follows the POSIX philosophy. 02:34.000 --> 02:36.000 It does one thing and one thing well. 02:36.000 --> 02:37.000 It works. 02:37.000 --> 02:39.000 It's well documented. 02:40.000 --> 02:45.000 And it's available on all platforms, and it works roughly the same on all platforms. 02:45.000 --> 02:48.000 Which is already quite amazing. 02:48.000 --> 02:53.000 As we'll see with some of the other APIs, when each OS does its own thing, 02:53.000 --> 03:00.000 you wind up with a variety of things with different levels of quality. 03:00.000 --> 03:06.000 Yeah, so like this prescriptive nature of the RFC, 03:07.000 --> 03:12.000 and the fact that these are included in libres of and libse and system libraries, 03:12.000 --> 03:16.000 meant that if you want to resolve the main name to an IP address, 03:16.000 --> 03:21.000 it is easy and straightforward on all operating system. 03:21.000 --> 03:27.000 And I think that's something we sometimes take for granted about yet other info. 03:27.000 --> 03:30.000 It really, really works. 03:30.000 --> 03:33.000 Now what sucks about yet other info? 03:33.000 --> 03:35.000 It's a synchronous API. 03:35.000 --> 03:38.000 That's sometimes good and sometimes bad. 03:38.000 --> 03:44.000 But the fact is that threads take up resources, not a lot, but enough. 03:44.000 --> 03:48.000 And I think API would have been nice to have. 03:48.000 --> 03:50.000 It is also very limited. 03:50.000 --> 03:54.000 As I said, it does one thing and does one thing well. 03:54.000 --> 03:57.000 It doesn't expose the full response details, 03:57.000 --> 04:01.000 so like some things that are missing, like the TTL, 04:01.000 --> 04:05.000 EDNS values, the actual code from the response, 04:05.000 --> 04:09.000 and the full C-name chain in the DNS response. 04:09.000 --> 04:12.000 These are things that would have been great to have sometimes, 04:12.000 --> 04:17.000 but if you need them, yet other info doesn't really have them. 04:17.000 --> 04:20.000 There are also minor implementation differences. 04:20.000 --> 04:24.000 For example, the Bionic implementation in Android 04:24.000 --> 04:27.000 fails if any of the domains in the C-name chain 04:27.000 --> 04:31.000 starts with a dash or an underscore. 04:31.000 --> 04:35.000 And that's something that works on other operating systems. 04:35.000 --> 04:38.000 So that's quite surprising sometimes. 04:38.000 --> 04:42.000 And there's no good way to control the request, 04:42.000 --> 04:46.000 so like if I want to bypass the cache or it is slash host. 04:46.000 --> 04:49.000 Yeah, it's not possible to do that. 04:49.000 --> 04:53.000 And sometimes that would be great to do. 04:54.000 --> 04:59.000 Now let's go over the Firefox implementation really quickly. 04:59.000 --> 05:04.000 In Firefox, we have a dedicated thread pool for DNS resolution, 05:04.000 --> 05:10.000 or NS host resolver class has a bunch of cues with different priorities. 05:10.000 --> 05:16.000 And then each thread looks in the priority cues, 05:16.000 --> 05:19.000 in order of priority, picks up one request, 05:19.000 --> 05:22.000 and then calls get the other info on them. 05:22.000 --> 05:24.000 Of course, there's also caching. 05:24.000 --> 05:28.000 So like if the domain name is already in the Firefox DNS cache, 05:28.000 --> 05:32.000 it never winds up in one of those priority cues. 05:32.000 --> 05:35.000 But it's like resolve immediately. 05:35.000 --> 05:39.000 And of course, there are multiple layers of caching. 05:39.000 --> 05:42.000 Like there's one in the Firefox DNS cache. 05:42.000 --> 05:46.000 There's the OS DNS cache, and there's the ISP DNS cache. 05:46.000 --> 05:51.000 So that's something that we also need to keep in mind. 05:52.000 --> 05:57.000 Yeah, and as I mentioned, get other info doesn't provide details. 05:57.000 --> 06:03.000 So Firefox had to do something about it. 06:03.000 --> 06:05.000 So like we were caching things, 06:05.000 --> 06:08.000 but we don't know for how long to cache those things. 06:08.000 --> 06:10.000 So if we only cache them for one minute, 06:10.000 --> 06:14.000 that means we're sometimes calling get another info immediately. 06:14.000 --> 06:18.000 So what we did instead was on Windows, 06:18.000 --> 06:22.000 we used DNS query A, just to get the TTL value. 06:22.000 --> 06:25.000 So we call get another info, then we call again, 06:25.000 --> 06:28.000 DNS query A, just for that TTL value. 06:28.000 --> 06:33.000 Which isn't great, but it works fairly well. 06:33.000 --> 06:39.000 And at some point, we started our DNS over HTTPS implementation, 06:39.000 --> 06:44.000 which kind of changed how things work. 06:44.000 --> 06:47.000 So like for more thread pull, calling get another info, 06:47.000 --> 06:52.000 we changed it to an event loop that takes the HTTPS response 06:52.000 --> 06:54.000 and parses the DNS payload. 06:54.000 --> 06:57.000 So like all in one thread. 06:57.000 --> 07:00.000 And now, so we had that DNS response, 07:00.000 --> 07:06.000 like we had TTL values, and we could parse any resource record we wanted, 07:06.000 --> 07:12.000 such as text records, or scene names, or whatever. 07:13.000 --> 07:17.000 And a few years ago, 07:17.000 --> 07:22.000 we got the SVCB service record, 07:22.000 --> 07:26.000 an HTTPS resource record, which are really great. 07:26.000 --> 07:29.000 Yeah, and before we continue, 07:29.000 --> 07:32.000 I know some of the people in this room may have 07:32.000 --> 07:36.000 like strong opinions about DNS over HTTPS. 07:36.000 --> 07:39.000 And I wanted to note that there's a difference 07:39.000 --> 07:43.000 between the dual protocol and the implementation in Firefox, 07:43.000 --> 07:46.000 and Firefox trusted recursive resolver program, 07:46.000 --> 07:51.000 which means that the resolvers that are defaults in Firefox 07:51.000 --> 07:56.000 are contractually obligated to follow our privacy requirements. 07:56.000 --> 08:00.000 And I'm quite happy to talk about that after the presentation, 08:00.000 --> 08:03.000 if you have any questions. 08:04.000 --> 08:08.000 So the SVCB resource records, 08:08.000 --> 08:12.000 an HTTPS record, the resource records, 08:12.000 --> 08:14.000 are quite useful. 08:14.000 --> 08:19.000 So if the user tries to load example.com, 08:19.000 --> 08:21.000 www.example.com, 08:21.000 --> 08:24.000 Firefox will resolve the HTTPS record, 08:24.000 --> 08:29.000 and just even before connecting to example.com, 08:30.000 --> 08:33.000 it will know that, hey, this host has an HTTPS record, 08:33.000 --> 08:37.000 that means there's no reason to use plain text HTTP. 08:37.000 --> 08:41.000 It also knows that it supports HTTP2, 08:41.000 --> 08:44.000 before negotiating it on the default port, 08:44.000 --> 08:48.000 and it knows that it supports HTTP3 on an alternative port. 08:48.000 --> 08:51.000 So if it wants to do HTTP3, 08:51.000 --> 08:53.000 we can connect it at alternative port, 08:53.000 --> 08:57.000 and the nice thing is that the URL bar will still 08:57.000 --> 09:01.000 show the same origin, so like with the default TLS port, 09:01.000 --> 09:04.000 and it will have the same origin meaning 09:04.000 --> 09:07.000 that it will share the same origin. 09:07.000 --> 09:12.000 It will be same origin with things like websockets and other resources. 09:12.000 --> 09:16.000 And there's other nice things in HTTPS records as well, 09:16.000 --> 09:19.000 like IPv4 hint and IPv6 hint, 09:19.000 --> 09:21.000 and then crypt and client hello, 09:21.000 --> 09:24.000 which is great for privacy because it allows you 09:24.000 --> 09:28.000 to hide the server name indication in the TLS handshake. 09:28.000 --> 09:31.000 Yeah, so that's great, 09:31.000 --> 09:36.000 but previously this was only available for Firefox users 09:36.000 --> 09:39.000 who used to do, and that's not all of them. 09:39.000 --> 09:43.000 So we want to bring the benefits of HTTPS records 09:43.000 --> 09:45.000 to all of Firefox users. 09:45.000 --> 09:51.000 So we looked at native OS APIs to resolve HTTPS records, 09:52.000 --> 09:54.000 which have a few advantages, 09:54.000 --> 09:57.000 like we're using the same resolver as the rest 09:57.000 --> 09:59.000 of the operating system. 09:59.000 --> 10:02.000 It may share the OS cache, 10:02.000 --> 10:06.000 and maybe the implementation is easier. 10:06.000 --> 10:09.000 That's something that we still don't know 10:09.000 --> 10:11.000 whether it's true or not. 10:11.000 --> 10:14.000 And yeah, when going into this project, 10:14.000 --> 10:19.000 our expectations for these APIs were that they exist, 10:19.000 --> 10:24.000 they're well documented, and that's they actually work. 10:24.000 --> 10:32.000 Yeah, so the best experience with the Linux implementation, 10:32.000 --> 10:36.000 res and query, which is well documented, 10:36.000 --> 10:40.000 it's easy to use, and after calling res and query, 10:40.000 --> 10:45.000 the buffer you pass into answer will contain the response bytes 10:45.000 --> 10:48.000 that you can parse with any DNS packet parser. 10:49.000 --> 10:51.000 And that's pretty much it. 10:51.000 --> 10:55.000 We were able to use the same parser that we had 10:55.000 --> 10:59.000 for our dough implementation, which was nice. 10:59.000 --> 11:03.000 The next platform was Android, 11:03.000 --> 11:07.000 and we looked at res query, 11:07.000 --> 11:10.000 but immediately when trying to use it, 11:10.000 --> 11:14.000 we noticed that it didn't really work. 11:14.000 --> 11:18.000 So just calling it for a record, 11:18.000 --> 11:21.000 it just returned minus one. 11:21.000 --> 11:24.000 I didn't find much documentation about it. 11:24.000 --> 11:27.000 Apart from a lonely stack overflow question, 11:27.000 --> 11:29.000 and a few forum posts, 11:29.000 --> 11:32.000 that said, okay, yeah, it doesn't work. 11:32.000 --> 11:36.000 So the implementation is completely worked. 11:36.000 --> 11:38.000 I did it ever work. 11:38.000 --> 11:40.000 I have no idea, maybe it did. 11:40.000 --> 11:44.000 But at least this gave us a good hint 11:44.000 --> 11:48.000 to look next, which is Android, 11:48.000 --> 11:50.000 res and query. 11:50.000 --> 11:54.000 So as you'll notice, this one needs dynamic linking 11:54.000 --> 11:58.000 to libandroidnet.so, 11:58.000 --> 12:03.000 where, and calling res and query returns a file descriptor, 12:03.000 --> 12:07.000 which you can pull, you can select, you can read from it, 12:07.000 --> 12:10.000 and the interesting thing about this one 12:10.000 --> 12:13.000 is that the answer here, the buffer, 12:13.000 --> 12:17.000 will actually contain the eight bytes for the UDP header, 12:17.000 --> 12:19.000 which was unexpected. 12:19.000 --> 12:23.000 None of the other APIs behave like that. 12:23.000 --> 12:26.000 Yeah, so my main right with this API 12:26.000 --> 12:30.000 is that it's only available on Android 10 and up. 12:30.000 --> 12:35.000 Fortunately, most Firefox users use a newer Android version, 12:35.000 --> 12:38.000 but it would have been nice to also support those 12:38.000 --> 12:41.000 user-dom on older phones too. 12:41.000 --> 12:43.000 It's relatively well documented, 12:43.000 --> 12:46.000 and you can specify it on like caching flags 12:46.000 --> 12:50.000 and the network interface that it's supposed to use. 12:50.000 --> 12:53.000 I haven't checked if these actually work, 12:53.000 --> 12:59.000 but I also haven't found anything that said that they don't work. 12:59.000 --> 13:03.000 Yeah, so next up is Windows. 13:03.000 --> 13:07.000 So as I mentioned, we already used the DNS query A 13:07.000 --> 13:11.000 for resolving A and quad A records. 13:11.000 --> 13:14.000 The big surprise was that on Windows 10, 13:14.000 --> 13:19.000 resolving HTTPS records returned null, 13:19.000 --> 13:22.000 which was really, really surprising, 13:22.000 --> 13:26.000 because the same code just worked on Windows 10. 13:26.000 --> 13:29.000 So obviously, there's a Windows bug here. 13:29.000 --> 13:31.000 We reported it to Microsoft, 13:31.000 --> 13:34.000 and reached out to some of their developers. 13:34.000 --> 13:37.000 But so far, there's been no progress on it. 13:37.000 --> 13:40.000 So if you want to upload it, if you're on Windows, 13:40.000 --> 13:44.000 please go to the URL and give it a thumbs up. 13:44.000 --> 13:46.000 Yeah, so exists. 13:46.000 --> 13:50.000 Well, documented kind of works on Windows 11. 13:50.000 --> 13:54.000 And there are some things I really like about this API. 13:54.000 --> 13:55.000 So it's really powerful. 13:55.000 --> 13:59.000 It has lots of options to control how the query is made, 13:59.000 --> 14:02.000 like taching, use of the host file, 14:02.000 --> 14:04.000 whether to use recursion or not. 14:04.000 --> 14:08.000 There's also DNS query X, which is A sync, 14:08.000 --> 14:13.000 which is like nice, if you don't want to use multiple threads. 14:13.000 --> 14:16.000 The response is a link to list of records, 14:16.000 --> 14:19.000 like similar to to get other info. 14:19.000 --> 14:23.000 And the nice thing about DNS record is that 14:23.000 --> 14:26.000 the data field is actually a union. 14:26.000 --> 14:30.000 So you can either access it as a struct, 14:30.000 --> 14:33.000 or you can access it as a buffer of bytes, 14:33.000 --> 14:39.000 and parse it with your otherwise DNS bucket library. 14:39.000 --> 14:44.000 Yeah, and you have the length of the DNS record, which can use. 14:44.000 --> 14:48.000 So I think this API is quite powerful and flexible. 14:48.000 --> 14:52.000 So if it weren't for the Windows 10 implementation bug, 14:52.000 --> 14:57.000 this would have been one of my favorite APIs here. 14:57.000 --> 15:02.000 Yeah, now we get to the vein of my existence, 15:02.000 --> 15:04.000 which is macOS. 15:04.000 --> 15:08.000 So like when we first started, we looked into risk query, 15:08.000 --> 15:14.000 but it soon became a parent that risk query is not thread safe. 15:14.000 --> 15:17.000 So that means it kind of works, 15:17.000 --> 15:20.000 but you can only resolve one record at the time. 15:20.000 --> 15:24.000 The documentation for it is not great. 15:24.000 --> 15:28.000 It says nothing about thread safety. 15:28.000 --> 15:32.000 So soon after this presentation, 15:32.000 --> 15:34.000 this talk was approved. 15:34.000 --> 15:38.000 I actually found out about DNS service query record. 15:38.000 --> 15:40.000 It's like this one definitely exists. 15:40.000 --> 15:42.000 The documentation could be better. 15:42.000 --> 15:45.000 It is thread safe. 15:45.000 --> 15:49.000 So I don't know if there's a lot of mac developers in the room, 15:49.000 --> 15:54.000 but my experience with Apple documentation is that it kind of sucks. 15:54.000 --> 15:59.000 Most APIs is just like, yeah, this is the function definition 15:59.000 --> 16:02.000 and like a short description for all the options. 16:02.000 --> 16:03.000 And that's pretty much it. 16:03.000 --> 16:07.000 But I would really like examples and something that 16:07.000 --> 16:10.000 talk about how things actually work. 16:10.000 --> 16:13.000 So it's quite an interesting API. 16:13.000 --> 16:14.000 You define a callback. 16:14.000 --> 16:17.000 Then you call the service query record. 16:17.000 --> 16:21.000 And then you call process resolved on it. 16:21.000 --> 16:25.000 And the callback gets called with the records. 16:25.000 --> 16:30.000 Now, what would you expect to happen if that host 16:30.000 --> 16:34.000 did not have an A record? 16:34.000 --> 16:38.000 Well, what I actually expected to happen is that this callback gets called 16:38.000 --> 16:41.000 with an error, right? 16:41.000 --> 16:46.000 Well, what actually happens is that the callback never gets called 16:46.000 --> 16:54.000 if you don't have that record. 16:54.000 --> 16:57.000 I have no idea how these things happen. 16:57.000 --> 17:00.000 I hope this is a bug. 17:00.000 --> 17:02.000 There is a worker on for it. 17:02.000 --> 17:07.000 So you can define a timeout there. 17:07.000 --> 17:11.000 But the fact that you have to wait for a timeout instead of the callback 17:11.000 --> 17:14.000 getting called when the NX domain comes back, 17:14.000 --> 17:17.000 it's just weird. 17:17.000 --> 17:23.000 You shouldn't need to do that. 17:23.000 --> 17:27.000 NX domain. 17:27.000 --> 17:29.000 Yeah. 17:29.000 --> 17:30.000 So yeah. 17:30.000 --> 17:33.000 So I looked in Wireshark and saw that the records 17:33.000 --> 17:34.000 goes out. 17:34.000 --> 17:35.000 Response comes back. 17:35.000 --> 17:36.000 Nothing happens. 17:36.000 --> 17:38.000 It's just thanks. 17:38.000 --> 17:42.000 So some things I learned in this experience, 17:42.000 --> 17:46.000 like the API capabilities vary widely across platforms. 17:46.000 --> 17:49.000 An abstraction library would be really nice. 17:49.000 --> 17:54.000 So like in Firefox, we use an SPR, which is kind of old and not 17:54.000 --> 17:58.000 maintained so much and difficult to update. 17:58.000 --> 18:02.000 So it would be nice if there were something like a rust library, 18:02.000 --> 18:05.000 which abstracted all these details away. 18:05.000 --> 18:08.000 Sometimes implementing your own DNS client would 18:08.000 --> 18:12.000 might be worth it, or use an existing library. 18:12.000 --> 18:16.000 And please, if you ever use some of these APIs or things, 18:16.000 --> 18:21.000 like trees blog posts about it, or documentary experience, 18:21.000 --> 18:24.000 because for me implementing this, 18:24.000 --> 18:29.000 it was quite difficult to find any resources about some of these. 18:29.000 --> 18:30.000 So yeah. 18:30.000 --> 18:33.000 Working the open, I think that's really valuable. 18:33.000 --> 18:36.000 And what kinds of APIs would I like? 18:36.000 --> 18:38.000 If I were to request one. 18:38.000 --> 18:44.000 So as I mentioned, the DNS query A and DNS query X have lots of options 18:44.000 --> 18:47.000 and would be really useful. 18:47.000 --> 18:51.000 I kind of liked Android risk query to the fact that it kind of 18:51.000 --> 18:54.000 gave you access to the socket and the response bytes. 18:54.000 --> 18:57.000 So you can actually wait on it, like even the UDP header. 18:57.000 --> 18:58.000 That was nice. 18:58.000 --> 19:02.000 I would like some better control over the request bytes as well. 19:02.000 --> 19:05.000 I think that would be nice. 19:05.000 --> 19:09.000 And like yet other info, I would like something that works everywhere. 19:09.000 --> 19:12.000 So like if all operating systems could get together and 19:12.000 --> 19:14.000 said, yeah, this is what we're going to implement. 19:14.000 --> 19:17.000 And make sure that it's going to work the same way. 19:17.000 --> 19:21.000 I would be really, really, really happy. 19:21.000 --> 19:23.000 So yeah. 19:23.000 --> 19:24.000 Thank you. 19:24.000 --> 19:26.000 Any questions? 19:26.000 --> 19:34.000 We have one question from Matrix. 19:34.000 --> 19:35.000 I'll start there. 19:35.000 --> 19:38.000 You have to repeat it as you are holding the microphone. 19:38.000 --> 19:39.000 Yes. 19:39.000 --> 19:43.000 Hasmobzilla tried requesting more modern APIs from some OS vendors. 19:43.000 --> 19:46.000 With listed requirements, missing and get other info. 19:46.000 --> 19:47.000 Yeah. 19:47.000 --> 19:52.000 So the question is, hasmobzilla tried requesting more modern API from some OS vendors 19:52.000 --> 19:55.000 with listed requirements missing and get other info? 19:55.000 --> 19:56.000 No, we haven't. 19:56.000 --> 20:00.000 We haven't found bugs for some of these issues. 20:00.000 --> 20:01.000 But no. 20:01.000 --> 20:07.000 Right now, we haven't tried to drive the development of new DNS APIs. 20:07.000 --> 20:08.000 Yeah. 20:08.000 --> 20:09.000 All right. 20:09.000 --> 20:12.000 So I do have a question that relates it to this. 20:12.000 --> 20:13.000 Yes. 20:13.000 --> 20:18.000 So recently, there was a security researchers planning bugs in the park. 20:18.000 --> 20:23.000 It's just a little lot of the answers. 20:23.000 --> 20:28.000 There's many additional records, compression. 20:28.000 --> 20:33.000 So are you doing your own DNS parsing or are you relying on the system? 20:33.000 --> 20:36.000 Because it makes back, I'm feeling. 20:36.000 --> 20:39.000 So have you thought about these? 20:39.000 --> 20:43.000 Like, if you receive the huge DNS response, 20:43.000 --> 20:46.000 there has a lot of compression pointing through each other and then stuff. 20:46.000 --> 20:48.000 So you just can blow off in the. 20:48.000 --> 20:49.000 Yes. 20:49.000 --> 20:50.000 Well, we have. 20:50.000 --> 20:52.000 So I should repeat the question. 20:52.000 --> 20:58.000 So there were some like security issues with DNS packets and compression, 20:58.000 --> 21:02.000 and like blowing up in size and getting very, very big. 21:02.000 --> 21:03.000 Yeah. 21:03.000 --> 21:07.000 So we've, I know we've had one of one issue, like that in the past in Firefox, 21:07.000 --> 21:11.000 because we implement our own like DNS packet parser, 21:11.000 --> 21:15.000 which is like, very simple, but it does do compression. 21:16.000 --> 21:20.000 But so we are looking into maybe using something, 21:20.000 --> 21:21.000 not implementing something or something, 21:21.000 --> 21:25.000 or maybe using an off the shelf library. 21:25.000 --> 21:27.000 Yeah. 21:27.000 --> 21:31.000 To avoid kind of like not having to re-implement some of these things, 21:31.000 --> 21:34.000 especially when they're in like more established DNS libraries. 21:34.000 --> 21:35.000 So follow up. 21:35.000 --> 21:36.000 Yeah. 21:36.000 --> 21:38.000 Do you want to be included? 21:38.000 --> 21:40.000 Something like this comes up. 21:40.000 --> 21:43.000 And the security researchers come to, well, 21:43.000 --> 21:45.000 that's not the end of vendors. 21:45.000 --> 21:47.000 Do you want to be like in this? 21:47.000 --> 21:48.000 Yes. 21:48.000 --> 21:50.000 So the question is whether we'd like to be included, 21:50.000 --> 21:52.000 when there's a. 21:52.000 --> 21:55.000 Research by by security researchers and S, 21:55.000 --> 21:57.000 and the answer is yes. 21:57.000 --> 21:59.000 I think that would be very useful for us. 21:59.000 --> 22:04.000 And second question and matrix is. 22:04.000 --> 22:07.000 Have you tried getting HTTPS RR? 22:07.000 --> 22:10.000 Not only with DNS specific APIs, 22:10.000 --> 22:15.000 but there's any OS provide a way to request it over multi-cast DNS, 22:15.000 --> 22:17.000 for example. 22:17.000 --> 22:19.000 I don't know. 22:19.000 --> 22:22.000 I haven't looked into it at all. 22:22.000 --> 22:23.000 Okay. 22:23.000 --> 22:24.000 Questions in here? 22:24.000 --> 22:25.000 Like that? 22:25.000 --> 22:27.000 If you kind of said far, 22:27.000 --> 22:29.000 if you want to see an X, 22:29.000 --> 22:30.000 then what do you just, 22:30.000 --> 22:32.000 probably think something's in there, 22:32.000 --> 22:34.000 okay, and that's the reason why I'm looking at this. 22:34.000 --> 22:36.000 So the question is, 22:36.000 --> 22:39.000 if we're doing our own DNS parsing, 22:39.000 --> 22:42.000 we just open a socket and do the request ourselves. 22:42.000 --> 22:43.000 Right? 22:43.000 --> 22:44.000 That's a very good question. 22:44.000 --> 22:47.000 And that's something we are exploring in the future, 22:47.000 --> 22:50.000 just because of all the things that I mentioned here. 22:50.000 --> 22:53.000 Like all the platforms that don't work. 22:53.000 --> 22:54.000 But rather than doing that, 22:54.000 --> 22:59.000 we're actually looking at maybe using a rust implementation 22:59.000 --> 23:01.000 that already exists, 23:01.000 --> 23:04.000 that's like that's a DNS client. 23:04.000 --> 23:06.000 So maybe using one of those, 23:06.000 --> 23:10.000 including it's DNS packet parser. 23:10.000 --> 23:14.000 Any other questions? 23:14.000 --> 23:15.000 Yeah. 23:15.000 --> 23:18.000 What's on there, a project to unify DNS query, 23:18.000 --> 23:21.000 I'm forcing, get DNS. 23:21.000 --> 23:23.000 The question is, 23:23.000 --> 23:27.000 whether there was an attempt to unify DNS parsing 23:27.000 --> 23:33.000 with DNS requesting resources with get DNS? 23:33.000 --> 23:34.000 I don't know. 23:34.000 --> 23:36.000 Maybe there's someone else in the room 23:36.000 --> 23:38.000 who has more information about this. 23:38.000 --> 23:39.000 Yeah, come on. 23:39.000 --> 23:42.000 I get DNS was of ease, 23:42.000 --> 23:44.000 depending on who you ask. 23:44.000 --> 23:46.000 The project was a unified API, 23:46.000 --> 23:48.000 a recent intimidation. 23:48.000 --> 23:51.000 It can, as detailed as a get DNS API. 23:51.000 --> 23:52.000 Up next. 23:52.000 --> 23:54.000 From the point to the point, it works. 23:54.000 --> 23:56.000 It could be a solution to this. 23:56.000 --> 23:58.000 As far as I know, 23:58.000 --> 24:00.000 it's going out of favor now, 24:00.000 --> 24:03.000 but not the format. 24:03.000 --> 24:05.000 Yeah, thank you. 24:05.000 --> 24:07.000 Could you show or write that? 24:07.000 --> 24:08.000 Like one sentence? 24:08.000 --> 24:12.000 So there is an attempt to use get DNS, 24:12.000 --> 24:14.000 but it's falling out of favor, 24:14.000 --> 24:16.000 and it can be found out, 24:16.000 --> 24:18.000 yet DNS.org. 24:18.000 --> 24:20.000 Get the APIs, 24:20.000 --> 24:23.000 get DNS API.net. 24:23.000 --> 24:25.000 Thank you. 24:25.000 --> 24:26.000 Thank you. 24:26.000 --> 24:36.000 Thank you. 24:54.000 --> 24:55.000 Oops. 24:55.000 --> 25:10.000 This is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could do, this is the first one I could