Paul Wouters writes:
> > 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...
> 
> Remember ipsec is peer to peer, not client to server :)

Yes, but configuration payloads for endpoint from the tunnel endpoint
(section 1.1.3), is not peer to peer, it is client to server :-)

> The idea is that the client can convey information of which DNS it will
> allow to be stolen and the server can convey which DNS it is serving
> that is expected to be an internal dns domain (eg different from outside
> worldview).

For endpoint to security gateway setup (RFC7296 section 1.1.3) the
endpoint is usually configured to trust the tunnel endpoint, but
endpoint might also have some of its own configuration for example
from previous runs. I.e. endpoint can offer these are the domains I
configured last time, and server will respond those look good. Or the
server can respond, those look good, but add this new domain, as my
configuration has changed since last time.

The reason client might want to keep track of the old internal dns
domains is that it might want to block the dns for those domains while
the vpn is not up, and even trigger the vpn creation when some
application tries to resolve one of those domains. 

> This is not about the server offering a DNS server to take all your
> queries. For that, I believe you can use the existing options, and
> those are outside the scope of this document.

This is about the server offering a DNS server to take some of your
queries, but not all. And the defintion of some is intersection of the
servers and clients policies. I.e., what server is willing to offer,
and what client is willing to accept.
-- 
kivi...@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to