Peculiar DNS queries

[Lars Kollstedt]

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:  lk at 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