Paul Wouters writes: > I did not really want to do that. It would also require updating RFC > 7296. So instead, I just pushed a change with: > > - assigned domains. DNS queries for other domains MUST be sent to the > - regular DNS service of the client. > + assigned domains. DNS queries for other domains SHOULD be sent to > + the regular DNS service of the client unless it prefers to use the > + IPsec tunnel for all its DNS queries. For example, the client could > + trust the IPsec provided DNS servers more than the locally provided > + DNS servers especially in the case of connecting to unknown or > + untrusted networks (eg coffee shops or hotel networks). Or the > + client could prefer the IPsec based DNS servers because those provide > + additional features over the local DNS servers. > > > Anyways I think changing that to say "SHOULD be sent" could work > > better, i.e., depending on the policy clients could either send > > requests to normal DNS server or to the server provided in IKE. > > Yes, done. see above.
Looks good. > > Note, that the original configuration payload was supposed to provide > > similar information than what DHCP does, so client does not need to > > have anything preconfigured, but can get the whole network > > configuration from the server. This included addresses, dns servers, > > etc, and even DHCP server address that it can use to get attributes > > not included in the configuration payload. Usually the configuration > > parameters received from configuration payload replaced the parameters > > they had before. > > Yes, but with split-tunnel, the client is clearly stepping in with one > foot while keeping the other foot dry :) Agreed. My text was mostly to explain people not familiar with configuration payload what was the original meaning for them in non-split-tunnel context. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
