SRV records and cache poisoning (full)

[Mark Andrews]

> Hello,
> 
> (sorry, I seem to have pressed the "Send" button earlier by mistake,
> so an incomplete version of this email will have ended up on
> bind-users)
> 
> This is more of a resolver/DNS question than a BIND one, but I thought
> I'd ask it here since there are people on this list that also worked
> on the libbind resolver library.
> 
> I'm writing this C++ module that does some DNS queries, SRV being one
> of them; it functions as a stub resolver, querying recursive
> nameservers that do the full resolution. Now, say that the following
> scenario happens:

	Stub resolvers need to trust their caching servers to have
	anti-poisioning support.  Stub resolvers don't have enough
	information to detect poisioning.  This assumes DNSSEC is
	not available for the zone that is the target of the
	poisoning.  If DNSSEC is available them the stub resolver
	can verify the answer.
 
> Some malicious user makes me do an SRV query for, say,
> _ldap._tcp.domain.com; as far as my understanding of the whole product
> works, this could be possible. That user owns domain.com and on those
> domain's nameservers he has something like:
> 
> ;; in the 'domain.com.' zone
> _ldap._tcp  3600 IN SRV  10 1  389 www.microsoft.com
> 
> and a www.microsoft.com. zone with a bogus IP address:
> ;; bogus www.microsoft.com zone
> @ 3600 IN A 123.234.234.1
> 
> So, when I'd query for that SRV record, my local caching nameserver
> would forward that to domain.com's nameserver and would pass me back a
> reply which, if I understand RFC2782 and BIND's handling of SRV
> records (I'm simplifying by assuming both servers are running BIND)
> would also include an A record for www.microsoft.com. in the
> additional section. Since I'm planning to implement some primitive
> caching in this module, my question is: how can I decide if the
> records in the additional section can be cached or not? It seems that
> I can't trust them, so I could generate lookups for each of the
> targets of the SRV records from the reply, but that would be costly,
> is there some middle ground?
> 
> Thanks in advance,
> Stefan
> 
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org