3 ms·
As a matter of preference mainly for speed and reliablity, not as any sort of "security" measure, I do DNS lookups in advance and store the data, using various
by textmode 8y ago
As a matter of preference mainly for speed and reliablity, not as any sort of "security" measure, I do DNS lookups in advance and store the data, using various custom solutions.
Thus I do not need to do any lookups while viewing a page. The addresses are already available to HTTP clients locally, e.g., via HOSTS, a cdb key-value store, or an authoritative nameserver serving a custom zone file on the local network. In other words, I am not using a caching resolver.
"DNS cache poisoning" publicity circa 2008 gave me the impetus to end reliance on shared caches and later caches altogether. But it was the speed when not using a cache that kept me interested. It still does, even today.
Maybe "DNS rebinding" publicity will cause others to question the need for using shared caches, or even caches in general. Maybe not. In any event, with the increasing availability of bulk DNS data from a variety of sources, it is much easier to devise methods for avoiding caches today than it was in 2008.
- pfg 8y agoDoes your approach respect TTL, i.e. by updating your source of truth after a record expires? Because you'd still be affected by DNS rebinding attacks in that case - and if not, I imagine there'd be quite a bit of breakage when IPs change? DNS caching in combination with an enforced minimum TTL (of something like 60 seconds) can be useful in mitigating certain categories of rebinding attacks (for example an attempt to bypass SSRF checks). Your solution might share this property if it behaves similarly.
- textmode 8y agoI control the frequency of updates to the data. If something changes I see it. I decide whether I want to trust it. Usually in the case of a change I will do some research on the new IP address. "TTL" is a concept used for DNS caches. I do not use a cache.
- nstart 8y agoThis sounds interesting. Quick questions. 1. Is it possible at all to release some source code related to this? I know it's a big ask but I didn't want to leave without asking :) 2. Would it be ok to describe what this solution looks like a little more? Is it /etc/hosts being edited using a service? Is it at a deeper level? Do you use your own DNS server? I'd love to adopt something similar, hence the curiosity :)
- dvfjsdhgfv 8y agoI was using a similar solution but probably quite different than the parent. I first generated the list of entries using Tinyproxy (turned out it was much easier than inspecting local DNS cache): you install Tinyproxy somewhere and use it for a few days. Then take the log and cut the lines: CONNECT Sep 08 08:29:04 [18050]: Connect (file descriptor 6): DOMAIN [IP] So basically you almost have your hosts file ready, you just need to switch places of the DOMAIN and IP, cutting out all before and the brackets. A minute or so. I used it for a short time and never bothered to take care of the updates though. I guess I'd have to temporarily disable the hosts file and run an async DNS resolver such as adnshost: adnshost -Vq +Dt - filtering out the INET string to create a diff. It seems to much hassle to me though, to manually inspect DNS changes - I have so many things to do, I see no much reason to bother with every IP change on the Internet.
- chopin 8y agoI am using bind9 for this and just looked up how to prevent it. It seems that bind9 has a (non-default) setting which prevents binding external host names to internal addresses (of which you control the A records).