Now, this is great.
Have to read the complete draft though.
Mat
On 14/09/11 16:32, Teemu Savolainen wrote:
Cool!
So this behavior is as already described in
draft-ietf-mif-dns-server-selection Appendix A.2:
--
A.2. Search list option for DNS forward lookup decisions
A node can learn the special DNS suffixes of attached network
interfaces from DHCP search list options; DHCPv4 Domain Search Option
number 119 [RFC3397] and DHCPv6 Domain Search List Option number 24
[RFC3646]. The node behavior is very similar as is illustrated in
the example at section 5. While these DHCP options are not intended
to be used in DNS server selection, they may be used by the nodes as
hints for smarter DNS server prioritization purposes in order to
increase likelihood of fast and successful DNS query.
Overloading of existing DNS search list options is not without
problems: resolvers would obviously use the DNS suffixes learned from
search lists also for name resolution purposes. This may not be a
problem in deployments where DNS search list options contain few DNS
suffixes like'example.com <http://example.com>,private.example.com
<http://private.example.com>', but can become a
problem if many suffixes are configured.
--
except that the MIF draft should also reference to RFC6106 (5006 does
not specify search list option). Adding for -05 version..
Anyhow, I recall comments that search list option should not be
"overloaded" with such use, but that it would be better to use explicit
options to define preferred DNS servers for specific domains and networks.
Best regards,
Teemu
2011/9/14 Dan Wing <[email protected] <mailto:[email protected]>>
> On a side note:
> In FreeBSD they just recently implemented RFC5006/RFC6106
following the
> lines of OpenResolv. The cool thing it does on the client, is to
set up
> different DNS servers for different domains, so in your case it would
> point to your local DNS if you want to resolve any *.company.com
<http://company.com>, and
> to
> the other DNS for everything else (with fallback to the local DNS
> eventually)
>
> Maybe we should push for that method to become standardised (if it
> hasn't been done yet).
There is still resistance that Split DNS occurs in real life.
However, draft-ietf-mif-dns-server-selection is somewhere that could
be useful to consider adding such support.
-d
_______________________________________________
homenet mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
