Re: [IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-split-dns-14: (with COMMENT)

[Paul Wouters <[e-mail]>]

On 2018-11-25 4:15 a.m., Tero Kivinen wrote:
> Paul Wouters writes:
>> So I suggest instead:
>>
>>      A client using these configuration payloads will be able to request
>>      and receive Split DNS configurations using the INTERNAL_DNS_DOMAIN
>>      and INTERNAL_DNSSEC_TA configuration attributes.  These attributes
>>      MUST be accompanied by one or more INTERNAL_IP4_DNS or
>>      INTERNAL_IP6_DNS configuration attributes.  The client device can
>>      then use the internal DNS server(s) for any DNS queries within the
>>      assigned domains.  DNS queries for other domains MUST be sent to the
>>      regular DNS service of the client.
> So the meaning of the INTERNAL_IP*_DNS changs meaning depending
> whether you have INTERNAL_DNS_DOMAIN or not. You might want to be bit
> more text explaining that in this paragraph.

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.


>
> 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 :)


Paul