WEBVTT 00:00.000 --> 00:07.440 Okay, sorry for that. 00:07.440 --> 00:12.280 So as an introduction to what the theme of this presentation is, I'm going to talk about 00:12.280 --> 00:14.480 the Thuleumithos. 00:14.480 --> 00:25.200 And so about 100 years ago, there was an American writer and he created this kind of world 00:25.200 --> 00:29.560 that was dark and hidden and all around us all the time. 00:29.560 --> 00:35.440 And in this universe, humans are not that the world is acting against us, but we were so 00:35.440 --> 00:40.440 far beneath the creatures that inhabited it, that we were not even important to them. 00:40.440 --> 00:45.800 And in his world, a common theme was that the more you learned about it, the closer to 00:45.800 --> 00:47.280 madness you got. 00:47.280 --> 00:51.920 And the human brain is just not capable of comprehending the true nature of the universe without 00:51.920 --> 00:53.520 going utterly insane. 00:53.520 --> 01:03.240 So the question that we faced with this idea, this fiction maybe of the universe, is, though 01:03.240 --> 01:06.000 the crazy person know that they're crazy, right? 01:06.000 --> 01:12.000 I think most crazy people probably think that everyone else is crazy, right? 01:12.000 --> 01:19.880 So if you combine this with this idea of lovecraft where you kind of, the characters in 01:19.880 --> 01:23.760 this story, learned about the world and often went crazy. 01:23.760 --> 01:26.000 Now, this is just fiction. 01:26.000 --> 01:29.040 I worked 25 years on the DNS. 01:29.040 --> 01:33.080 The protocol is 40 years old and I'm fine, so this is just fiction. 01:33.080 --> 01:37.280 All right, so let's get started here. 01:37.280 --> 01:41.160 So what we're going to do in this presentation is I'm going to basically sprinkle a few 01:41.160 --> 01:45.680 weird things from the DNS, but you may or may not know, but even if you do know about 01:45.680 --> 01:49.840 the, maybe you haven't thought about it in quite this way. 01:49.840 --> 01:52.480 So the first thing I'm going to talk about is serial numbers. 01:52.480 --> 01:56.360 So in the DNS, we have an SOA, start of authority record. 01:56.360 --> 02:02.240 Every zone has this, this is kind of what defines a zone and it has a little bit of information 02:02.240 --> 02:03.920 that's useful. 02:03.920 --> 02:07.600 One of these pieces of information, you can see it embolden that kind of first line 02:07.600 --> 02:09.440 by itself, the serial number. 02:09.440 --> 02:13.920 And this is what primaries and secondaries use to keep zones in sync. 02:13.920 --> 02:18.200 So the primary will update this number, and the secondary will see that it's been changed 02:18.200 --> 02:23.200 and then transfer an updated version of the zone, pretty basic stuff. 02:23.200 --> 02:25.920 One would think, they were pretty basic stuff. 02:25.920 --> 02:29.520 However, this number is in a 32 bit space. 02:29.520 --> 02:32.160 So what do you do when you get to do more than that? 02:32.160 --> 02:37.040 What you use normal unsigned integer math and you roll, right? 02:37.040 --> 02:40.080 And so, but the question is, well, what happens when you get to the end? 02:40.080 --> 02:45.120 So it turns out in engineering, there's a way to define these numbers that roll around. 02:45.120 --> 02:48.320 And there's a kind of math that you use to compare numbers in this space. 02:48.320 --> 02:52.800 And so you can look at this image and like, amadding you get to the end of your 32 bit space 02:52.800 --> 02:53.960 and then you add one. 02:53.960 --> 02:56.200 Well, then you go back to zero, pretty easy. 02:56.200 --> 03:03.920 And so it turns out that in this case, what we end up with is zero is greater than 03:03.920 --> 03:06.520 two to the 32nd minus one. 03:06.520 --> 03:09.720 It makes sense if you think about it, it's not that weird. 03:09.720 --> 03:17.200 But it also means that if you try to compare to any two numbers, this more or less makes sense. 03:17.200 --> 03:22.880 But once you start adding other numbers and trying to sort them, for example, sometimes it works. 03:22.880 --> 03:27.760 So for example, if we added another one and had one and two and so on, then those numbers would 03:27.760 --> 03:28.760 sort pretty well. 03:28.760 --> 03:33.680 But if we started adding a billion or another billion, then we end up with a set of numbers 03:33.680 --> 03:38.760 where you can't put them in order because with the order that they come up with, depends 03:38.760 --> 03:41.480 on where you start and which one you compare. 03:41.480 --> 03:48.160 So you have a system of numbers where some comparisons are possible sometimes but not always. 03:48.160 --> 03:53.080 So if that doesn't blow your mind enough, it gets even weirder because in the specifications 03:53.080 --> 03:59.600 if you get exactly two to the 32nd minus one away, it's undefined which number is greater 03:59.600 --> 04:01.520 or less than the other. 04:01.520 --> 04:02.520 And they're not equal. 04:02.520 --> 04:06.560 So you have a numerical system where every number has one other number that it's neither 04:06.600 --> 04:09.760 greater than, more or less than, more equal to. 04:09.760 --> 04:14.920 So anyway, that's serial numbers, something to think about on your train right home. 04:14.920 --> 04:17.520 All right, next thing we're going to talk about, TTL records. 04:17.520 --> 04:22.280 So if you're in the DNS derby room, you're probably very familiar with TTLs, it's not 04:22.280 --> 04:23.760 that weird. 04:23.760 --> 04:30.560 One thing that lurks me, that annoys me a lot about these records, is that the large amount 04:30.560 --> 04:32.760 of redundancy in the system that these incurred. 04:32.760 --> 04:36.200 So every resource record has a TTL. 04:36.200 --> 04:43.880 But if you have, for example, one name, www.fostem.org, all of the address records for it 04:43.880 --> 04:46.200 are in what we call a resource record set. 04:46.200 --> 04:52.000 So they all have to have the same TTL and if there's different, there's rules for how 04:52.000 --> 04:53.640 you're supposed to interpret that. 04:53.640 --> 04:59.840 But what it means is that you're wasting 32 bits for every record when you really only 04:59.840 --> 05:02.280 need one for the whole set. 05:02.320 --> 05:03.800 That's the first thing. 05:03.800 --> 05:10.360 The other thing is that because it wasn't 100% clear when the specification was defined, 05:10.360 --> 05:14.040 whether it was signed or unsigned, although what a negative time to live would mean is a 05:14.040 --> 05:17.680 bit strange and you might want to consider that. 05:17.680 --> 05:20.040 What they eventually did was said, look, it's too hard. 05:20.040 --> 05:21.880 We're just going to ignore that last bit. 05:21.880 --> 05:27.680 Which basically means half of the TTL space is missing or unusable or undefined or I don't 05:27.680 --> 05:32.400 know exactly, again, we're in kithulu realm, so who knows. 05:32.400 --> 05:37.440 Now, it operationally, it's not normally a problem two to the 31st is 68 years, which 05:37.440 --> 05:40.040 is probably long enough for keeping most records. 05:40.040 --> 05:45.080 I did a little research about this last year, if you curious, we can talk about that. 05:45.080 --> 05:51.040 Anyway, TTL's only a little bit weird, not as weird as serial number, so it's fine. 05:51.040 --> 05:55.080 So sticking with the theme of wasting space. 05:55.080 --> 06:01.720 In addition to TTL's, every resource record has something called class, which is a 16-bit 06:01.720 --> 06:06.920 field, which is always one, so it's literally always one. 06:06.920 --> 06:12.200 You're wasting tons of space in every query, and keep in mind that the DNS packet format 06:12.200 --> 06:18.800 is designed to be compact and well organized, but it has this historical craft, and to 06:18.800 --> 06:23.560 be fair, I say it's always one, sometimes it's not, sometimes it's two, which is the 06:23.560 --> 06:26.720 lovely name chaos class, which I love. 06:26.720 --> 06:30.400 So you can see an example here at the bottom of the kind of things that you can do with 06:30.400 --> 06:37.280 the chaos class, and they're mostly used for asking the server about itself, so you can 06:37.280 --> 06:41.160 some servers will tell you where it's located, or let's tell you what the name is, or 06:41.160 --> 06:46.040 what version of software it's running, which may or may not be a security problem, depending 06:46.040 --> 06:48.640 on your philosophies about these things. 06:48.640 --> 06:54.560 Anyway, class is mostly a waste, and people have discussed trying to get rid of it, but 06:54.560 --> 07:01.120 not had much success, because it's very, very hard to change things in such an old, and 07:01.120 --> 07:06.480 the DNS itself, it kind of is like a living organism, it kind of resists change in a weird 07:06.480 --> 07:08.480 way. 07:08.480 --> 07:09.480 What's that? 07:09.480 --> 07:18.400 Yeah, all right, next thing, text records, text records were in the very first DNS 07:18.400 --> 07:23.200 RFCs, and they're very simple, we use them for a ton of things, because they're basically 07:23.200 --> 07:28.920 an 8-bit clean way to send, to put random data in the DNS, so it's pretty cool, pretty 07:28.920 --> 07:35.120 simple, however, it's not actually that simple as it could be, because it's not just 07:35.120 --> 07:41.480 a blob of data or a blob of textual data, it's actually a list of strings, which are between 07:41.480 --> 07:49.240 zero and 255 bytes long, each one has a length-specifier in the front, so this presents 07:49.240 --> 07:51.200 problems to an application developer. 07:51.200 --> 07:56.680 What do you do if you have 300 bytes you want to put into the DNS, so one way to do 07:56.680 --> 08:02.760 it is to look at it semantically and break the data in the right way and so on, or what 08:02.760 --> 08:06.760 a lot of applications do is they just go to, they get to the byte 255 and then create 08:06.760 --> 08:12.400 a new string, but that breaking them up and putting them together is not defined anywhere 08:12.400 --> 08:19.080 as far as I know, so it's an undefined operation and you're not exactly sure what you're 08:19.080 --> 08:20.640 going to get when you do that. 08:20.640 --> 08:26.520 Now, even though this weirdness causes problems, it actually does have advantages, so in 08:26.520 --> 08:33.520 the DNS, for example, if I do a lookup of records and I talked about R sets before, normally 08:33.520 --> 08:40.160 those will come back to you in an indeterminate order, so good resolvers will shuffle those, 08:40.160 --> 08:47.800 so they'll appear randomly, and that has very useful properties, but in any case, the resource 08:47.800 --> 08:52.720 record sets are sets, they're not actually ordered, so when you get them back, they kind 08:52.720 --> 08:54.640 of appear in some random order. 08:54.640 --> 09:02.880 This list of strings and a text record is a list of strings, it has an order, so you can see 09:02.880 --> 09:07.600 on this slide, at the top, these are the kind of results you get when you query, when 09:07.600 --> 09:12.120 you query, just separate text records, and you can see just based on these two queries, 09:12.120 --> 09:15.200 they come in random orders, please don't speak these names out loud, I don't know what 09:15.200 --> 09:20.960 will happen, so, and in the bottom, you can see a single text record with multiple values 09:20.960 --> 09:25.480 and they come in a deterministic order, so we can bring order out of the chaos of text 09:25.480 --> 09:31.920 records, at least, so you're just at a web browser and you want to check a text record 09:31.920 --> 09:38.920 quickly, so you might go to, these are all of the web-based query lookup tools, if you say 09:38.920 --> 09:43.860 lookup DNS record on duct.go, I just looked at them all, none of them handle text records 09:43.860 --> 09:50.160 properly, they all do things in slightly different ways, I did find one tool which understood 09:50.160 --> 09:54.120 that they were separate fields within a text record, but it treated them exactly the same 09:54.120 --> 09:58.440 as if they were separate records, and there was no way to distinguish them, so I don't know 09:58.440 --> 10:03.200 what people get your act together, if you're in here, yeah, you're doing it wrong, 10:03.200 --> 10:11.320 there's no good answer, so, don't do that, I think there's someone giving an equivalent 10:11.320 --> 10:18.120 presentation in a web room about HTML, so, all right, next thing we're going to talk 10:18.120 --> 10:25.640 about here is status, so, like HP Lovecraft was kind of an elitist, he believed that some 10:25.640 --> 10:28.480 people were better than there was, he thought that status was really important, so does 10:28.480 --> 10:35.840 the DNS, and every DNS message has an op code, operation code, and almost always 10:35.840 --> 10:42.120 that's query, zero, there's also notify, and for when the primary talks to a secondary 10:42.120 --> 10:47.080 says something's changed, there's update for dynamic DNS, there's DNS-date for operations, 10:47.080 --> 10:51.800 I don't really know what those are for, I don't really care, I query, which was absolutely 10:51.800 --> 10:54.560 deleted, that was where you tried to look up, I think that's where you tried to look 10:54.560 --> 10:59.680 up things based on the R data, so you'd say, like, give me all the web servers that 10:59.680 --> 11:06.680 have, you know, a given IP address or whatever, and then we have status, which is not 11:06.680 --> 11:11.240 defined, it just says get the server status, it has no information about what it contains, 11:11.240 --> 11:17.240 or what it's going to work, so John Dickinson tried to get rid of it because no one knows 11:17.240 --> 11:21.560 what it is, no one even knows what it is, so let's get rid of it, and he put together 11:21.560 --> 11:27.600 an RFC, and it was met with fierce resistance within the DNS community, people were morally 11:27.600 --> 11:32.920 opposed to this, I suspect that the RFC is working on them, that we don't really understand, 11:32.920 --> 11:38.600 but I don't really know for sure, now I heard a report just last night that someone stopped 11:38.600 --> 11:42.920 answering status queries and started ignoring them, and then they got a report from a 11:42.920 --> 11:46.520 customer, who couldn't tell them what they were for, but just that they needed them, 11:46.600 --> 11:59.880 so there you go, there you go, all right, true story, next thing is about escape sequences, 11:59.880 --> 12:06.280 right, so DNS comes from a more elegant era where things were in text, asky text, everything 12:06.280 --> 12:11.880 was simple, nowadays we live in a world with Unicode, which is complicated and constantly moving, 12:12.840 --> 12:16.600 but even in the Asky world, you would sometimes want to put data that wasn't 12:16.600 --> 12:22.440 seven bit printable, right, and so the way you can do that is you can use a little escape code, 12:22.440 --> 12:30.760 so like this is Octal Code for 32, which gives you a space, right, or Octal Code for a dash, right, 12:31.400 --> 12:38.040 now the DNS also has a similar way to represent non-asky data in an Asky way, 12:38.040 --> 12:43.960 it's a very similar except different, so you can see here that we use the exact same codes 12:43.960 --> 12:49.000 and we get different results, so this is just using dynamic DNS to add these records and then 12:49.000 --> 12:56.200 we just use dig to query them so we can show what we get, and the reason is that these codes 12:56.200 --> 13:02.520 while they look Octal are actually decimal because, because I don't know why, it seems like a 13:02.520 --> 13:07.800 good idea at the time, or again maybe mysterious forces were working on them, all right, 13:09.880 --> 13:16.600 so the next one I decided I should actually do some research for this presentation, and I looked 13:16.600 --> 13:23.160 at our name, so going back to our SOA record, every zone has what's supposed to be an email address 13:23.160 --> 13:29.640 up here at the top, so you can see if you look up the phosdom one, hostmaster.phosdom.org, 13:29.640 --> 13:36.280 like what does that mean? Well, I think it's on the next slide, yeah, no it's not on the next one, 13:36.280 --> 13:41.080 but basically what you're supposed to do is replace the first dot with an add, and then it's an email 13:41.080 --> 13:45.560 address, now of course you may ask yourself what happens if I have a dot in my email address, 13:45.560 --> 13:49.480 like well then you're supposed to escape it of course, that's basically the answer, 13:50.360 --> 13:56.760 now as far as I know this never works, like maybe phosdom, if you email this, we'll get 13:56.760 --> 14:02.120 an answer back in a few days, but I think very few places actually monitor that email addresses 14:02.120 --> 14:07.800 you used in these, it's more of a historical thing. Oh, well there we go, there we go. 14:11.800 --> 14:16.680 Me too, but I actually don't get any email about it, I don't know, I figure there's 14:17.960 --> 14:22.120 stammers have tried it, but it doesn't work, I don't know, maybe actually maybe I get tons of 14:22.120 --> 14:32.120 email that it all ends up in my field. Yeah, yeah, so they look different from the normal format 14:32.120 --> 14:37.400 because of this conversion of dots and escaping and things like that. So I thought like I know 14:37.400 --> 14:41.720 because we run a name server and I've been working on the dance, that there's a lot of weird 14:41.720 --> 14:47.160 names in there, so I just like let's just do a very simple test. The sweetest government 14:47.320 --> 14:53.880 lets you download, or the sweetest registry lets you download all of the content, it's creative 14:53.880 --> 15:01.000 comments license for .se and you, which is handy. So you can just download it, get all of the zones 15:01.000 --> 15:05.320 that get all of the domain delegations there, and then do an SOA look up and see what you get. 15:05.320 --> 15:13.320 Now, in my measurements, only 0.5% have strange our name, so I was actually really impressed. 15:13.320 --> 15:16.840 I doubt most of the more. So anyway, let's what kind of stuff do you see in there? 15:17.880 --> 15:23.240 Well, obviously if I try to try to send an email to hostmaster.it's not going to go anywhere. 15:23.240 --> 15:29.400 So we have a lot of bare emails. We have things like this, which are of course TTLs, I guess. 15:30.680 --> 15:36.600 We have this, which is probably a serial number, I don't know. This looks like some sort of old IP address. 15:36.680 --> 15:45.000 They used to use these quite a decimal IP addresses. And then we have a lot of just emails 15:45.000 --> 15:49.400 that are badly formed, like with at symbols that are encoded in there, things like that. 15:49.400 --> 15:53.240 And my favorite, which is please set email.absolutely.knower. 15:58.360 --> 16:00.520 Actually, I didn't try to send mail and maybe it works, I don't know. 16:01.160 --> 16:14.440 All right, so that's our our name. So DNS is very old and I've just shown you a few strange things 16:14.440 --> 16:19.000 that are in there. But I wanted to make sure that everyone kept in mind that the DNS isn't limited 16:19.000 --> 16:25.960 to the DNS standards, right? So this is a dice graph that I found that a Japanese, I don't know if 16:26.040 --> 16:30.440 these are researcher or something like that. But anyway, he tried to put together a nice graph 16:30.440 --> 16:35.240 of all of the, all of the RFCs and how they fit together and everything like that. 16:37.160 --> 16:44.920 Just for DNS. Yeah. Yeah. Yeah. So there's a lot. And a lot of them don't mean anything anymore, 16:45.320 --> 16:53.160 a lot of them do, but not exactly how it looks. And so there's, but in addition to all of this, 16:53.160 --> 16:57.880 which there will be a test on at the end of the week, there's a lot of features which aren't 16:57.880 --> 17:03.240 defined in any of these. And I have the next slide we'll talk a little bit about those. There's 17:03.240 --> 17:07.880 also things that aren't as far as I know not written down anywhere that you kind of just have to 17:07.880 --> 17:15.400 learn by writing DNS software. Simple example of this is for example, when you get a, when you get a 17:15.400 --> 17:20.360 UDP packet, which is the most common way you get a query in DNS, you then send the reply back 17:20.360 --> 17:27.080 to where it came from. Well, if the query came from port 0, most unixes won't let you reply to it, 17:27.080 --> 17:32.920 because that's not how it works. So you just have, so what you end up seeing is all of a sudden 17:32.920 --> 17:37.960 you'll start getting spam in your error logs because you're getting errors trying to send a packet. 17:38.520 --> 17:42.920 And then you have to say, oh, there's nothing, I'm not doing anything wrong, the internet is wrong. 17:44.520 --> 17:48.600 And so I think these are coming from embedded devices or maybe people like putting their 17:48.680 --> 17:53.640 packets together directly and using like direct raw, raw, IO or something, I don't know. 17:53.640 --> 17:58.680 But these are the kind of things that you just have to learn by doing it. There's not, 17:58.680 --> 18:04.760 as far as I know, there's not a manual, so good luck. So here's a few things that are in the DNS 18:04.760 --> 18:12.120 expanded universe. The first thing is bind views, which are so old that many, many people think 18:12.120 --> 18:16.680 that they're part of the DNS, but they're not. It's just something that someone thought of 18:16.680 --> 18:22.040 sometime. And the idea is that you give different answers to the people in the office and the people 18:22.040 --> 18:28.520 outside the office so that only your coworker can see your printer, basically. And then there's also 18:28.520 --> 18:35.320 something called response policy zones. So it's kind of a cool idea, so like because we like DNS, 18:35.320 --> 18:40.600 because we're DNS people, we put everything in the DNS, including data about which answers 18:40.600 --> 18:46.600 to block and things like that. So response policy zones are a way to basically stream over the DNS 18:47.480 --> 18:53.160 updates about which zones to block and how. And people actually sell feeds with this with like 18:54.120 --> 18:58.360 bad people. And of course some governments say you must apply our block list and things like that. 18:59.640 --> 19:05.160 And there's RL. Someone was talking earlier about reflection and amplification attacks. 19:06.280 --> 19:13.080 This is basically that you spoof your source address, send a UDP query to a server, and then it 19:13.160 --> 19:21.960 goes to the target, which is the address that you gave it. And that can both hide you and amplify the damage 19:21.960 --> 19:27.080 you call. Because the responses are bigger than the questions. So that's, this is a technique 19:27.080 --> 19:31.640 for dealing with that, which basically keeps track of the answers that you're sending. And if you keep 19:31.640 --> 19:35.880 sending the same answer to the same address, something's wrong because they're not cashing it or whatever. 19:35.880 --> 19:40.920 And so you just drop some of them on the floor. So it works pretty well, but not standardized, 19:40.920 --> 19:45.160 very, very widely deployed. And then the final thing on this slide, there's many, many, many, many more. 19:46.840 --> 19:51.000 So that the final one this slide is just DNS tap, which I think was mentioned earlier, I can't 19:51.000 --> 19:55.640 remember. It's just an efficient way to log queries and answers. So there's tons of stuff in this 19:55.640 --> 20:04.120 expanded universe. And that is all I have. I have a couple of reference slides. I don't expect 20:04.120 --> 20:08.680 you to read these, but they'll be in the slides that you can download. As far as I know, there's no AI 20:09.240 --> 20:14.280 generated images in this presentation. And as far as I know, all of the links and references and 20:14.280 --> 20:19.240 everything are available for personal use. If you want to use this in your company, you'll have to 20:19.240 --> 20:25.240 talk to Castilia yourself. Anyway, that is it.