41–50 of 72 posts
Earlier quoted context omitted.
Okay stupid question… I thought TTL was a count of hops, not time in seconds. Or do people use it differently where instead of subtracting 1, their routing devices subtract n seconds?
TTL is a general term standing for "time to live". In the context of an IP packet it's a number of hops. In the context of a cache, it's a time until expiration.
Wondering what prompted the blog post. The recent publication of RFC 9539? It would be interesting to hear how often the google dns servers see attempts to poison their cache. The mitigations probably prevent folks from even trying, but he numbers would be interesting. The OARC 40 presentation PDF mentions cookies deployment is low for large operators but open source software has compliant implementations. Are large…
Yes. It is trivial to build a DNS server, and near impossible to write a correct DNS server. Eventually your organization gets large enough that someone thinks it is a good idea without understanding the implications.
> you would be able to detect which software nameservers are running, each with known capabilities
There are pseudo-standards for asking an authoritative server what software it is running, but everyone turns that off because somehow it makes you "more secure." What you end up having to do is probe auth servers by replaying user queries on the side, measuring if the responses you get are correct, and then keeping a database somewhere of which servers support which flags.
Earlier quoted context omitted.
Guess - possibly some sort of outbound port-knock alternative: if (SYN->dest port && TTL > X) { ACK };
How is this supposed to work, exactly?
Earlier quoted context omitted.
For end users, TLS is the key protection. I don't care if my DNS is poisoned, MITMed, or malicious: if the IP address I connect to can't present a valid TLS cert, then I don't proceed. If you can't securely authenticate your server (as HTTPS/TLS does) you have other problems too.
Unfortunately it's quite easy for some actors to get a valid TLS cert https://notes.valdikss.org.ru/jabber.ru-mitm/
Still, good to see that monitoring the CT logs would have caught this problem much sooner.
Earlier quoted context omitted.
DNS is where the web would have been if browsers basically didn't force websites to support HTTPS. The reasoning is that DNS is not important enough to go through the trouble of deploying DNSSEC. These days TLS is often cited as the reason DNSSEC is not needed. At the same time we see a lot of interest in techniques to prevent cache poisoning and other spoofing attacks. Suddenly in those cases DNS is important. If al…
If we didn't have the web, all networking above OSI L4 on all operating systems would have been encrypted by default. A simple set of syscalls and kernel features could have enabled it. But since the web was there, and popularized a solution for secure communications (TLS + HTTP), everyone just jumped on that bandwagon, and built skyscrapers on top of a used books store. The weird irony is it's the old "worse is bett…
Earlier quoted context omitted.
Okay stupid question… I thought TTL was a count of hops, not time in seconds. Or do people use it differently where instead of subtracting 1, their routing devices subtract n seconds?
TTL is a general term standing for "time to live". In the context of an IP packet it's a number of hops. In the context of a cache, it's a time until expiration.
TTL is still in seconds, but every hop has to decrease it by at least one.
I'm not sure if there is any implementation out there that cares, but if e.g. wifi retries or a massive buffer queue lead to a packet spending more than a second on a hop, it should decrease by two.
Earlier quoted context omitted.
DNS is where the web would have been if browsers basically didn't force websites to support HTTPS. The reasoning is that DNS is not important enough to go through the trouble of deploying DNSSEC. These days TLS is often cited as the reason DNSSEC is not needed. At the same time we see a lot of interest in techniques to prevent cache poisoning and other spoofing attacks. Suddenly in those cases DNS is important. If al…
If we didn't have the web, all networking above OSI L4 on all operating systems would have been encrypted by default. A simple set of syscalls and kernel features could have enabled it. But since the web was there, and popularized a solution for secure communications (TLS + HTTP), everyone just jumped on that bandwagon, and built skyscrapers on top of a used books store. The weird irony is it's the old "worse is bett…
The problem is that applications typically use TCP connections, but IPSEC works at the IP level. Early on, the (BSD socket) kernel API was basically fixed at the IP level instead of associating it with a TCP socket.
So the whole thing became too complex (also for other reasons). So SSL and SSH were created to have simple things that worked.
SSL took many iterations to get any kind of security, so IPSEC had plenty of time to get it right and take over. But as far as I know, there just never happened. It also doesn't help that TLS is trivial to combine with NAT, and for IPSEC that is quite tricky.
Weird that they don't even mention that Google's public DNS performs DNSSEC validation. It does, and that's the ultimate defense against cache poisoning attacks.
No, it obviously isn't, because less than 5% of zones are signed, and an even smaller fraction of important zones (the Moz 500, the Tranco list) are. That's why they don't mention DNSSEC: because it isn't a significant security mechanism for Internet DNS. It's also why they do mention ADoT: because it is. I think this is also why DNSSEC advocates are so fixated on DANE, which is (necessarily) an even harder lift than…
DNSSEC is the ultimate defense against cache poisoning attacks, no matter the adoption percentage.
Earlier quoted context omitted.
The low adoption of DNSSEC might be due to posts like these: https://news.ycombinator.com/item?id=36171696 - Calling time on DNSSEC: The costs exceed the benefits (2023) And also many news regarding validation failures: https://hn.algolia.com/?q=dnssec
The rabbit hole on people gradually pulling up stakes on DNSSEC goes deeper than that; I'd say the canary in the coal mine is probably Geoff Huston switching from "of course we're going to DNSSEC everything" to "are we going to DNSSEC anything?": https://www.potaroo.net/ispcol/2023-02/dnssec.html (Geoff Huston is an Internet infrastructure giant.) But really it all just boils down to the fact that the DNS zones that…
Some other counterpoints to general DNSSEC doomsayers:
• https://blog.technitium.com/2023/05/for-dnssec-and-why-dane-...>
• https://www.redpill-linpro.com/techblog/2019/05/06/sshfp-and...>
Earlier quoted context omitted.
TTL is a general term standing for "time to live". In the context of an IP packet it's a number of hops. In the context of a cache, it's a time until expiration.
IP is weird. TTL is still in seconds, but every hop has to decrease it by at least one. I'm not sure if there is any implementation out there that cares, but if e.g. wifi retries or a massive buffer queue lead to a packet spending more than a second on a hop, it should decrease by two.
If an intermediate server handed out the original TTL for all requests then the TTL would be effectively multiplied by each caching layer³, which is why you will only get the true TTL at the client end if a fresh request was actually made to the authoritative server(s).
--
[1] the fraction of a second difference caused by latency isn't likely to be significant for either long or short TTLs
[2] and on a really high latency link (like back when GPRS or POTS landlines were common, or some links even now in deep rural areas) 1s might not be enough anyway for the benefit they think they are giving
[3] so at my home where lookups go PiHole->8.8.8.8->authoritative it would make TTLs potentially up to 2x their intended length. Example: for a 1000s TTL if PiHole gets the lookup request with 1s remaining but hands out the true TTL, my client will not check for 1000s, potentially 999s late. Depending on the sequence of related requests to each DNS server from other clients, that could become 1998s in my case, longer if there were more caching layers.