Re: [BEHAVE] [Francis.Dupont@fdupont.fr: [dnsext] DNS64 and lying cache servers]

Hi,

For me this sounds exactly like the split-DNS problem I describe here: draft-savolainen-mif-dns-server-selection (http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection-00) and what we discuss in MIF WG.

Essentially even today multi-interfaced hosts can not really trust DNS information being fully coherent between different administrative domains.

I plan to include the faked AAAA records as additional example of private information DNS servers are providing, and information that must be used only in the administrative domain they were learned from. 

Best regards,

	Teemu

>-----Original Message-----
>From: behave-bounces@ietf.org [mailto:behave-bounces@ietf.org] 
>On Behalf Of ext Charles E. Perkins
>Sent: 03 August, 2009 01:46
>To: Andrew Sullivan
>Cc: behave@ietf.org
>Subject: Re: [BEHAVE] [Francis.Dupont@fdupont.fr: [dnsext] 
>DNS64 and lying cache servers]
>
>
>Hello folks,
>
>There is a reference below to a disaster that can occur when 
>DNS64 encounters mobility.  Is there something more I can read 
>about this?
>
>Thanks in advance for any pointers to reading material.
>
>Regards,
>Charlie P.
>
>
>
>Brian E Carpenter wrote:
>> It's an interesting point but it misses the point IMHO:
>> we *have* to lie to classical IPv6-only hosts.
>>
>> I've always preferred the stub resolver approach, right back to 
>> draft-van-beijnum-v6ops-mnat-pt-00.txt, but that preference 
>is useless 
>> if the real world contains classical IPv6 hosts.
>>
>>    Brian
>>
>>
>> On 2009-07-31 19:44, Andrew Sullivan wrote:
>>   
>>> Dear colleagues,
>>>
>>> Some of the participants in dnsext are reluctant to join another 
>>> mailing list the subject of which is mostly not of interest to them.
>>> I have offered to accept comments from those participants 
>and forward 
>>> them to behave when appropriate and if asked.  Attached is one such 
>>> example.
>>>
>>> A
>>>
>>>
>>>
>>> 
>---------------------------------------------------------------------
>>> ---
>>>
>>> Subject:
>>> [dnsext] DNS64 and lying cache servers
>>> From:
>>> Francis Dupont <Francis.Dupont@fdupont.fr>
>>> Date:
>>> Wed, 29 Jul 2009 14:28:26 +0200
>>> To:
>>> namedroppers@ops.ietf.org
>>>
>>> To:
>>> namedroppers@ops.ietf.org
>>>
>>>
>>> [Please forward this to the behave mailing-list]
>>>
>>> [I use the term "cache server" as a synonym of "recursive DNS 
>>> server"]
>>>
>>> DNS64 (draft-ietf-behave-dns64-00.txt) is usually presented with a 
>>> cache server serving a lot of NAT64 IPv6-only clients and 
>performing 
>>> AAAA RR synthesis from A RRs to make external IPv4-only servers 
>>> reachable through a NAT64 translator.
>>>
>>> So this is essentially a lying cache server: this is *bad* for the 
>>> usual reason (it breaks DNSSEC). Worse, its lie is very location 
>>> dependent, so it has very bad interaction when the DNS is 
>assumed to 
>>> be location independent, for instance with Mobility.
>>>
>>> But as explained in the draft at the end of the section 2 Overview 
>>> this is not the only way to deploy DNS64: in the "DNS64 in stub- 
>>> resolver mode" the synthesis is done as close as possible to the 
>>> client so there is no longer lying issues.
>>>
>>> Note this doesn't extend to some other lying DNS proposals from NAT 
>>> based IPv6/IPv4 transition mechanisms because DNS64 uses a 
>small set 
>>> of static parameters (mainly the Pref64::/n) which is the 
>only state 
>>> of the synthesis process.
>>>
>>> So I recommend the DNSEXT WG to advise to put more work into the 
>>> sub-resolver mode (producing DNS64 capable stub-resolvers, which 
>>> should be very easy, and solving the DNS64 parameter distribution 
>>> issue) than into the DNS server mode which should be 
>recognized as an 
>>> example of a false good idea.
>>>
>>> Regards
>>>
>>> Francis.Dupont@fdupont.fr
>>>
>>> PS: Acknowledgments to Mark Andrews who introduced the strong but 
>>> correct "lying" term, and to Wassim Haddad who remarked DNS64 and 
>>> Mobility together can easily lead to disasters.
>>>
>>> --
>>> to unsubscribe send a message to namedroppers-request@ops.ietf.org 
>>> with the word 'unsubscribe' in a single line as the message 
>text body.
>>> archive: <http://ops.ietf.org/lists/namedroppers/>
>>>
>>>
>>> 
>---------------------------------------------------------------------
>>> ---
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> Behave@ietf.org
>>> https://www.ietf.org/mailman/listinfo/behave
>>>     
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
>>   
>
>_______________________________________________
>Behave mailing list
>Behave@ietf.org
>https://www.ietf.org/mailman/listinfo/behave
>