Subject: [BEHAVE] Handling error reponses in draft-bagnulo-behave-dns64

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Mar 2009 06:49:52 +1300

Repeating the old question I raised at the microphone.

The draft says that if there is no A record, DNS64 will
return the error response to the stub resolver. If I understand
things correctly, DNS responses include the original query.
If DNS64 does literally what the draft says, it will return
a response to the stub resolver containing its own A query
and not the stub's AAAA query. That seems wrong in principle, and
it isn't obvious to me that a legacy resolver would process
the response correctly.

   Brian

On 2008-12-01 21:01, marcelo bagnulo braun wrote:
> Brian E Carpenter escribió:
>> This is still open from the old draft. It's section 3.1
>> in the new draft:
>>
>> On 2008-06-20 00:05, marcelo bagnulo braun wrote:
>>
>>  
>>>>>>>    If this query results in an empty result or in
>>>>>>>    an error, this result is returned to the client.             
>>>>>>>             
>>>>>> Even in this case, the result has to be synthetic I think
>>>>>> (original AAAA query followed by empty answer or error).
>>>>>>
>>>>>>                   
>>>>> don't know
>>>>> why do you think this is needed?
>>>>>             
>>>> I don't fully understand what DNS error replies look like,
>>>> but I think they include the original query type. If so, the
>>>> resolver code might get confused if the error reply to a AAAA
>>>> query contained query type A.
>>>>
>>>>         
>>> ok, let's get some dns experts to look at this
>>>     
>>
>> And a similar point later in the new draft:
>>
>>  
>>> 4.3.1.  An-IPv6-network-to-IPv4-Internet
>>>     
>> ...
>>  
>>>    3.  If the CD is set and DO is set, then it SHOULD NOT perform
>>>        validation, and it SHOULD NOT perform translation.  It SHOULD
>>>        hand the data back to the query initiator, just like a regular
>>>        recursing server, and depend on the client to do the validation
>>>        and the translation itself.
>>>     
>>
>> This is very odd - the stub resolver asks for a AAAA record
>> and gets back an A record. I really don't know if that's going
>> to work.
>>   
> Of course, this requires the stub resolver to be upgraded to understand
> this
> We are working in an alternative behaviour, proposed by people in dnsops
> presentation.
> 
> We hope to have a new version sometime soon.
> 
> Regards, marcelo
> 
>>     Brian
>>
>>   
> 
>