Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

[<mohamed.boucadair at orange-ftgroup.com>]

Dear Brian,

At this stage, the draft does not discuss the reverse DNS. Do you have in mind a particular hurdle related to the use of A64?

Cheers,
Med 

-----Message d'origine-----
De : behave-bounces at ietf.org [mailto:behave-bounces at ietf.org] De la part de Brian E Carpenter
Envoyé : samedi 7 novembre 2009 00:24
À : Andrew Sullivan
Cc : behave at ietf.org
Objet : Re: [BEHAVE] Review of draft-boucadair-behave-dns-a64-01

FWIW, I think either of these suggestions would have a better chance of deploying than a new RR type. Think about the ill-fated A6 record.

Incidentally, the draft doesn't mention whether reverse entries are also needed.

   Brian

On 2009-11-07 06:14, Andrew Sullivan wrote:
...
>     a.  Add the "base" A record to the Additional section
> 
> If a DNS64 server were to provide synthetic AAAA records and include 
> the corresponding A record in the Additional section, a DNS64-aware 
> querying client could take the presence of that A record as a hint 
> that there might be more to the answer than meets the eye.  It should 
> be able to extract the equivalent IPv4 address from the AAAA record, 
> and thereby infer that the AAAA is synthetic.  A dual-stack host could 
> then just use the A record instead.  A signficant disadvantage of this 
> approach is that the Additional section is the first thing to be 
> truncated when a response gets long, so it's possible that the 
> Additional section won't have the "base A" when it's needed.  In 
> addition, a site publishing statically-configured synthetic AAAA 
> records can do so with a bog-standard DNS server, and there'd be no 
> way to tell that the records are in fact synthetic, so such servers 
> wouldn't include the A record without some kind of additional work.
> 
>     b.  Use an EDNS0 option to signal DNS64 awareness
> 
> If we defined an EDNS0 option (call it the SY bit, for synthetic) to 
> signal DNS64 awareness, then either an initiator or a recursor could 
> signal its ability to understand DNS64.  A server receiving such a 
> signal could include the Pref64::/n in the answer using a new RRTYPE 
> (say, PREF64).  That prefix could then be stripped off the AAAA by 
> whatever node got the answer, and the resulting IPv4 address could be 
> used as appropriate.  One disadvantage of this approach is that it 
> requires participating nodes to upgrade in order to achieve the 
> functionality; but in fact, A64 also requires that, and so the effect 
> is no worse.  Moreover, it does not introduce new queries or anything 
> of the sort to the mix, so we aren't increasing the number of queries.
> 
>     4.  Conclusion
> 
> Even if this is a problem that needs to be solved -- a position that 
> is not obvious to me -- it is not plain that A64 solves it.  Even if 
> it does solve it, it solves it at a very great price, and a price that 
> will be paid long after A64 is broadly useful.  In any case, there are 
> other ways to solve the same problem, and they are less disruptive 
> than adding A64 to the DNS.  Therefore, I do not think the A64 
> proposal should be adopted.
> 
> Best regards,
> 
> Andrew
> 
> 

_______________________________________________
Behave mailing list
Behave at ietf.org
https://www.ietf.org/mailman/listinfo/behave

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************