On Thu, 23 Mar 2017, Tero Kivinen wrote:
then someone manages to tear down the VPN connection, and suddenly all
these mappings go away, the next time your mail client tries to fetch
email, it does mail.example.com lookup using external DNS servers, and
will get IP-address of 1.1.1.1 from ns.evil.org, then then it will
connect to wrong mail server...
If you are afraid of this attack, deploy DNSSEC on your domain.
I most likely would have configfured my internal domain with DNSSEC,
bu tthe DNSSEC trust anchors got deleted when tunnel went down, and
when it revers to external DNS that might or might not be signed
depending whether the top level domain or service provider you are
using supports DNSSEC.
If you are in a split view, we can't really retain DNS cache. When the
split goes away you would not be able to reach these. For example,
bugzilla.redhat.com has an internal and external IP. If DNS cache is
retaining, when my VPN goes down, I can no longer connect to bugzilla.
So I think my use case trumps your use case because you should just
sign your external DNS too :P
Perhaps we should keep the mappings for some time, just in case the
connection comes back few seconds later when the vpn reconnects...
I switch regularly from redhat.com to public, and that would really
cause me problems. It is really important to wipe all the now
unreachable cached DNS data.
If you wish to stall for a few seconds, I'd recommend you would be
dropping the DNS packets instead of lingering old state, and I would
say that is a pure local implementation issue and shouldn't go into
the RFC.
But the MUST delete DNS forwarding etc will not allow me to do that.
That's semantics :P
If you linger the Child SA, you haven't torn it down yet, so you can
also leave your DNS entries.
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
