Hello,
We have been looking at some DNS resolvers and encountered a question:
When a DNS response contains (in the answer section) records which were
not requested, how should the resolver react to those and what should
it return to the requesting client?
For example:
QUESTION:
example.com
> > Is the client responsible for identifying the requested RRSet
> > or should the resolver only return the records matching the
> > request? E.g. in the example above, should the client return
> > all records in the answer section or just the 1.2.3.4 A record?
>
> Without being able to cite cha
> That's cache poisoning. Search for "Eugene Kashpureff" to learn all
> about it.
There is a relation in the sense that checking RRs for relevance to the
query is mentioned as a partial defense against cache poisoning in RFC
3833, section 2.3.
Note however some differences:
1. Caching of unrequ
Hello everyone,
a while ago I asked for guidance concerning a vulnerability I found in a DNS
library.
Unfortunately I cannot find the message right now, so please excuse the new
thread.
The vulnerability now has a CVE and a GitHub Advisory published here:
https://github.com/dnsjava/dnsjava/secu
> However, it doesn't make sense to include step 4. A DNSSEC validator will
> have taken care of step 4.
Partially. I believe the DNSSEC validation and following the CNAME-chain have
to be implemented in the same routine.
This is because to perform an authenticated denial of existence, you firs
> The IETF does not create standards for APIs. So a validating stub resolver is
>
> not really something that can be defined, because it is not a protocol.
I beg to differ here. It may not be strictly part of the DNS protocol, but then
this logic needs to be a part of every single protocol dep
