Paul Wouters writes: > > When an IPsec connection is terminated, the DNS forwarding must be > > unconfigured. The DNS forwarding itself MUST be be deleted. All > > cached data of the INTERNAL_DNS_DOMAIN provided DNS domainis MUST be > > flushed. This includes negative cache entries. Obtained DNSSEC > > trust anchors MUST be removed from the list of trust anchors. The > > > > This might cause security issues. I.e., if you have mail.example.com > > resolved using internal dns server to have IP-address of 10.0.0.1, and > > 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. > > 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. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
