Hi, some additions.
on Monday, 30. December 2019, 23:48:41 CET I wrote: > resolver1 asks Autoritative of the com-Zone for ImenT.Com or wWw.ImenT.Com There are two ways for a resolver to behave. The slower way which is leaking less information to the highest levels of the authoritatives is to ask for NS records on each dot in the name, and only to ask the most specific authoritative for the real query. The many dots in ip6.arpa are massively slowing this down, but also DNSSEC will require lots of queries in this case. If this way to ask is used and a FQHN contains a deep hierarchy which is done to be able to delegate but not all dots are real delegations at the time of the query, it will be slowed down by this strategy. The other way is to always forward the orignal query. So the query to e.g. to g.gtld-servers.net (one of the com authoritatives) can be ImenT.Com IN NS or wWw.ImenT.Com IN A Both will be answered with a NS RR for ImenT.Com. Which strategy is used strongly depends on the used resolver software and configuration. They can be also mixed in different ways, e.g. asking for NS RRs in the first levels. [...] > client1 gets Www.IMent.coM IN A 216.55.100.245 back from resolver1 If client2 asks for www.IMEnT.CoM within the TTL of the A RR it will get an answer for www.IMEnT.CoM, but resolver1 will not ask the autoritatives for that again. Thats (without the camelcase) how DNS caching already works for decades, and that's what can be attacked when there isn't enough entropy in the query. If the Resolver is connected with 10Gb/s or more the randomization of the source port is definitely not enough. The clue of dnsext-dns0x20-00 is that it can be used against most of the most common implementations of authoritative dns without needing them to be adopted for that. And it only produces some log lines the people operating them are wondering about there. ;-) Only the Resolver that is kind of well connected needs to run a software version that implements dnsext-dns0x20-00 to be more secure by that. Until the end of the 90s DNS-Queries were done with source and destination port 53. Then the source port randomization was implemented. That's now not enough any more, and attacks were already seen in the wild. This is adressed by DNS cookies and dnsext-dns0x20-00, they are both (like the sourceport randomization) not protecting against real MitM attacks, but against spoofed UDP answers in large amounts. DNS cookies must be implemented on both ends, and there were authoritatives that were needing exceptions, because they didn't answer queries with DNS cookies. Hope this makes clear what the dnsext-dns0x20-00 is for. If you need a real MitM proof DNS, all stakeholders relevant for you will have to do DNSSEC. But NSEC and NSEC3 (the proof of nonexistence) is probably a bit like choosing between pest and cholera. NSEC can't be spoofed in any way but allows to walk the zone. NSEC3 will be possibly/probably weak for being replayed in a real MitM scenario, since the answer can be only checked for plausibility, since the signatures are done over non revertable hashes without disclosing the data the hashes are generated from. On Mondagy, 30. December 2019, 19:54:13 CET Tony Finch wrote: > Yes. And one prominent resolver that implements this is unbound Not only unbound does. ;-) On Montag, 30. December 2019, 20:10:57 CET Tony Finch wrote: > Well, it's a bit more complicated than that, I'm afraid! The case that you > use in zone files and UPDATEs should be preserved on disk and (I think?) > through zone transfers, but not necessarily in answers to queries. I at first misread the context of this. :-( Fred is of course talking about DNS Update, and a least BIND is cleanly implementing the case insensitivity for for DNS answers for many years. But in the AXFR Data of BIND (9.10.3) and probably also on disk the character case of an upper case character in the zone file is really preserved. Might be that also happens with DNS Update. I'm not really sure that is useful. ;-) But the NSCD stuff he also mentioned sometimes also uses other non DNS mechanisms like mDNS, NIS+ or /etc/hosts as far as I remember. NIS+ and at least some versions and parts of /etc/hosts tooling are really case sensitive. Kind regards, Lars -- Lars Kollstedt Telefon: +49 6151 16-71027 E-Mail: l...@man-da.de man-da.de GmbH Dolivostraße 11 64293 Darmstadt Sitz der Gesellschaft: Darmstadt Amtsgericht Darmstadt, HRB 9484 Geschäftsführer: Andreas Ebert _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users