Valery Smyslov writes: > > > > This way if you have originally configured company1.com to the > > > > internal dns names, and then company decides to buy another company > > > > called company2.com, teh client can still request company1.com and > > > > server can return both company1.com and company2.com in its reply. > > > > Then it is up to the client whether it will belive the list or not. > > > > > > Why the client would ever not believe to the information from the > > > authenticated server? I'd go further and say that the initiator MUST > > > use the received internal DNS servers for all the requests within > > > the received INTERNAL_DNS_DOMAIN (as you proposed before). > > > > The level of trust might not be complete. I.e., if my laptop is > > connecting to both my own VPN gateway, and also one of our partners > > VPN gateway, I might trust the VPN gateway of our my company even if > > it claims to provide trusted DNS delegation for .com... > > > > I might not want to trust the VPN gateway of our partner claiming to > > be authorative for mycompany.com, i.e., I will have policy limiting > > what is accepted from the gateway. > > > > Also when using opportunistic authentication we might want to have > > even strictier policies. > > OK, then it contradicts with your own comment that all requests to > INTERNAL_DNS_DOMAIN MUST be done using internal DNS server. > Quoting your message: > > I think the 1st point (I.e. all requests about internal names go to > the internal servers) is something that is important for security, so > it should perhaps be MUST. > > At least it must be clarified.
Yes, and No. If the client rejects the INTERNAL_DNS_DOMAIN because of policy reasons, then it is not internal name anymore, thus it can use DNS server configured elsewhere. But yes, I agree there should be clarification explaining that only those internal names client accepted must use internal servers... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
