More Odd DNS Records: NIMLOC, (Tue, Jul 7th)
\n \t
\n
<\/BR>
\n
\n \t
\n
<\/BR><\/p>\n
Yesterday, I talked about NAPTR records and how they are related to RCS. But there is another “odd” record that shows up in my DNS logs. This one isn’t new, but I don’t think I ever covered it: NIMLOC. At least that is what Zeek calls it. But let’s see what it is all about.<\/p>\n
At first, it looks like NIMLOC records are no longer used. Google’s AI overview explains: “A NIMLOC (Nimrod Locator) DNS record is an obsolete resource record type (Type 32) originally designed for the Nimrod routing architecture to map names to network locators. Because Nimrod was an experimental protocol, NIMLOC records are considered historic and are not used in modern, standard network operations.”<\/p>\n
While I do have\u00a0one or the other odd IOT device in my network, I doubt any of them speak “Nimrod”. On the other hand, the queries originate from my macOS systems. This turns out to be an older standard,\u00a0replaced by a newer (but still old) standard, with the newer standard becoming obsolete before the even older standard is phased out.<\/p>\n
DNS defines several resource record types. The official list is maintained by IANA [1] and I am including a sample below:<\/p>\n
\u00a0<\/p>\n
| TYPE<\/td>\n | Value<\/td>\n | Meaning<\/td>\n | References<\/td>\n<\/tr>\n |
| A<\/td>\n | 1<\/td>\n | IPv4 Address<\/td>\n | RFC1035<\/td>\n<\/tr>\n |
| NS<\/td>\n | 2<\/td>\n | Name Server<\/td>\n | RFC1035<\/td>\n<\/tr>\n |
| PTR<\/td>\n | 12<\/td>\n | Domain Name Pointer<\/td>\n | RFC1035<\/td>\n<\/tr>\n |
| MX<\/td>\n | 15<\/td>\n | Mail Server<\/td>\n | RFC1035<\/td>\n<\/tr>\n |
| TXT<\/td>\n | 16<\/td>\n | Text String<\/td>\n | RFC1035<\/td>\n<\/tr>\n |
| AAAA<\/td>\n | 28<\/td>\n | IPv6 Address<\/td>\n | RFC3596<\/td>\n<\/tr>\n |
| NIMLOC<\/td>\n | 32<\/td>\n | Nimrod Locator<\/td>\n | (no RFC)<\/td>\n<\/tr>\n |
| SRV<\/td>\n | 33<\/td>\n | Server Selection<\/td>\n | RFC2782<\/td>\n<\/tr>\n |
| NAPTR<\/td>\n | 35<\/td>\n | Naming Authority Pointer<\/td>\n | RFC3403<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n There is a range of unassigned RR types, so one would think that it is not necessary to reuse RR Types. But this is exactly what happened here.<\/p>\n RR Type 32 was originally assigned for the old NetBIOS over TCP\/UDP (RFC 1002, [2]). This actually became one of the few Internet Standards (STD 19). RR Type 32 is assigned ot “NB” (NetBIOS General Name Service) and 33 to “NBSTAT”, the NetBIOS Node Status. If you search for it in the RFC, look for the hex values 0x0020 and 0x0021 (took me a while to find them).<\/p>\n NetBIOS is long gone, and modern Windows networks use DNS\u00a0and SMB over TCP, eliminating the NetBIOS layer. But\u00a0macOS is still holding on to it\u00a0and broadcasting name announcements on port 137\u00a0using these records. Zeek (which I used to collect the logs), translates RR Type 32 to “NIMLOC”, which conforms to the current IANA assignment for this type. But in reality, you are probably going to see NetBIOS and not the never-quite-implemented Nimrod routing scheme.<\/p>\n [1]\u00a0https:\/\/www.iana.org\/assignments\/dns-parameters\/dns-parameters.xhtml#dns-parameters-4 — (c) SANS Internet Storm Center. https:\/\/isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.<\/p><\/div>\n \t |