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. Currently if server send INTERNAL_IP*_DNS (and do not include INTERNAL_DNS_DOMAIN), then clients usually send all dns queries to that server. Typically enterprice users trust their own DNS servers more than the DNS server provided by the hotel... After this change client must have some other DNS server also configured, and MUST use them for other domains. Of course the general idea for the Split-DNS is that we do not send all dns traffic to server, only those internal domains, but one main use for it is also to provide TAs for those internal domains so DANE etc can work for internal services. 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. 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
