The weird and wonderful world of DNS LOC records
Cloudflare's RRDNS server, crucial for DNS requests, faced issues with LOC records due to a missing code link. A parser was implemented, ensuring proper handling of these records in their infrastructure.
Read original articleCloudflare's infrastructure relies on its ability to quickly serve DNS requests and mitigate DNS attacks, achieved through its proprietary authoritative DNS server, RRDNS, developed in Go. Despite the complexity of DNS, which has evolved since its inception in 1987, Cloudflare manages millions of DNS records, including a rare type known as LOC (location) records. These records specify physical locations, but only 743 LOC records exist in Cloudflare's database. A recent customer inquiry about an unserved LOC record prompted an investigation into RRDNS, revealing a missing code link that prevented the server from parsing LOC records correctly. The LOC record format, defined in RFC 1876, includes latitude, longitude, altitude, and optional size and precision values. The textual format is straightforward, while the on-the-wire format converts this data into a fixed-size binary format. To address the issue, a parser for the LOC text record type was created and implemented, allowing RRDNS to serve existing LOC records properly. The article illustrates the technical intricacies of DNS record handling and highlights the importance of even the least utilized record types in a large-scale DNS infrastructure. The successful resolution of the LOC record issue demonstrates Cloudflare's commitment to maintaining robust DNS services.
Related
The prevalence, persistence, and perils of lame delegations (2021)
The Domain Name System (DNS) translates domain names to IP addresses. Lame delegations, causing delays and security risks, stem from unreachable nameservers and misconfigurations. Passive analysis detects issues, with 50% in .BIZ domain.
Issues with 1.1.1.1 public resolver in multiple locations
Cloudflare faces problems with 1.1.1.1 public resolver in various locations. Fix in progress. Investigation ongoing. Users can subscribe for updates. Cloudflare working on resolving the issue.
Cloudflare 1.1.1.1 incident on June 27, 2024
Cloudflare faced a DNS resolver issue on 1.1.1.1 due to BGP hijacking and route leak, impacting global users. Cloudflare used RPKI for prevention but challenges remain. Mitigation steps were taken during the incident.
Cloudflare 1.1.1.1 incident on June 27, 2024
Cloudflare faced a global incident on June 27, 2024, with its 1.1.1.1 DNS resolver due to BGP hijacking and a route leak. Despite affecting some users, Cloudflare responded by disabling peering locations and engaging with network operators to resolve the issue.
Privacy and DNS Client Subnet
The Internet's architecture has evolved with CDNs like Cloudflare's 1.1.1.1 using anycast efficiently. DNS Steering and Client Subnet raise privacy concerns but aim to optimize performance globally.
- Several users express surprise at the existence and functionality of LOC records, indicating a lack of awareness prior to the article.
- There are discussions about the practical applications of LOC records, with some users suggesting creative uses like scavenger hunts and memorials.
- Users share personal experiences and examples of using LOC records, highlighting both successes and failures in implementation.
- Some comments reference past talks and articles, indicating a broader interest in the implications and security aspects of DNS features.
- There is a sense of community engagement, with users asking questions and sharing resources related to LOC records.
$ dig loc SW1A1AA.find.me.uk
; <<>> DiG 9.10.6 <<>> loc SW1A1AA.find.me.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63530
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;SW1A1AA.find.me.uk. IN LOC
;; ANSWER SECTION:
SW1A1AA.find.me.uk. 21600 IN LOC 51 30 3.637 N 0 8 29.624 W 0.00m 0.00m 0.00m 0.00m
# dig geekatlas.com LOC @1.1.1.1
; <<>> DiG 9.20.0 <<>> geekatlas.com LOC @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19487
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;geekatlas.com. IN LOC
;; AUTHORITY SECTION:
geekatlas.com. 300 IN SOA ns1.namefind.com. dns.jomax.net. 2023031500 28800 7200 604800 300
;; Query time: 22 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon Jul 29 08:46:31 EDT 2024
;; MSG SIZE rcvd: 104
In particular, it solves the discovery issue discussed in RFC 9092 (https://www.rfc-editor.org/rfc/rfc9092), allows real-time updates, and would make it easier for ISPs to delegate maintenance of geolocation records to customers.
Verified it works on another machine, my daily driver was blocking something. Also verified coordinates that it generates.
[1] - https://dnsloc.net/
Secondly I think cloudflare will see an (sizable???) increase in Loc records due to this article
Hence you could have
* google.com <LOC San Francisco>
* google.com <LOC London>
and pick the right one
but that's not really how it works at all :(
Perhaps the title of this post can be edited to include [2014] as well.
Related
The prevalence, persistence, and perils of lame delegations (2021)
The Domain Name System (DNS) translates domain names to IP addresses. Lame delegations, causing delays and security risks, stem from unreachable nameservers and misconfigurations. Passive analysis detects issues, with 50% in .BIZ domain.
Issues with 1.1.1.1 public resolver in multiple locations
Cloudflare faces problems with 1.1.1.1 public resolver in various locations. Fix in progress. Investigation ongoing. Users can subscribe for updates. Cloudflare working on resolving the issue.
Cloudflare 1.1.1.1 incident on June 27, 2024
Cloudflare faced a DNS resolver issue on 1.1.1.1 due to BGP hijacking and route leak, impacting global users. Cloudflare used RPKI for prevention but challenges remain. Mitigation steps were taken during the incident.
Cloudflare 1.1.1.1 incident on June 27, 2024
Cloudflare faced a global incident on June 27, 2024, with its 1.1.1.1 DNS resolver due to BGP hijacking and a route leak. Despite affecting some users, Cloudflare responded by disabling peering locations and engaging with network operators to resolve the issue.
Privacy and DNS Client Subnet
The Internet's architecture has evolved with CDNs like Cloudflare's 1.1.1.1 using anycast efficiently. DNS Steering and Client Subnet raise privacy concerns but aim to optimize performance globally.