[dns-operations] Issues on source-based DNS policy in dual-stack network

["Davey(宋林健)"]

> 在 2016年8月11日，11:12，Mark Andrews <marka at isc.org> 写道：
> 
> 
> In message <032e01d1f375$1cb87970$56296c50$@cn>, =?gb2312?B?RGF2ZXkgU29uZyjLzsHWvaEp?= writes:
>> 
>> Hi folks, 
>> 
>> I recently notice a issue on source-based DNS policy in dual-stack networks.
>> (Maybe I missed some solution or best practice already existed.)
>> 
>> It may be well known that some networks use multiple upstream ISPs to share
>> the load (Universities for example). There are many options to do this. One
>> option is to use DNS resolver to response with different answers to
>> different group of users, which will finally steal the traffic to different
>> ISPs. It works very well in IPv4-only network, because the resolve can
>> implement the load-balance policy based on IPv4 source address. However, in
>> dual-stack environment a client may query A via IPv6 or AAAA via IPv4 which
>> makes this load-balance option difficult. It is become a reason some network
>> administrators become reluctant to upgrade their resolver to dual-stack. 
>> 
>> Besides the resolver, authority server who player smart DNS function
>> (response differently according to clients geo-location address) suffers as
>> well. Current RFC7871 give some clue that DNS massages can carry subnet
>> information of end users, but it is fit the scenario from resolver to
>> authority. And the resolver still have no way to know other IPv6(or IPv4 )
>> addresses of their users when they are speaking different language(I mean IP
>> version).
>> 
>> Is it a qualified problem statement? 
>> 
>> Best regards,
>> 
>> Davey
> 
> "If (in IPv4-prefix) return address"
> 
> 	becomes
> 
> "If (in IPv4-prefix or in IPv6-prefix) return address"
> 
> This is just a matter of doing the necessary homework to build up
> the databases.  

Thanks. I know it works and it indeed the cost to run dual-stack network, mapping the two, manage the dynamic change, especially for larger network. Yes,  I’m too lazy to think of use the existing IPv4 database to resolve this issue. 

> You can still corollate resolver IPv6 address ->
> connection source IPv4 and vica versa.  This is no harder than
> resolver IPv4 address -> connection source IPv4.
> Mark
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org <mailto:marka at isc.org>
---------------------------
Davey Song(宋林健)
BII Lab
ljsong at biigroup.cn



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160811/116c963d/attachment.html>