Peculiar DNS queries
lk at man-da.de
Tue Dec 31 01:56:11 UTC 2019
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
ImenT.Com IN NS
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 18.104.22.168 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
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
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
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.
Telefon: +49 6151 16-71027
E-Mail: lk at man-da.de
Sitz der Gesellschaft: Darmstadt
Amtsgericht Darmstadt, HRB 9484
Geschäftsführer: Andreas Ebert
More information about the bind-users