Re: [v6ops] New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt

[Jen Linkova <[e-mail]>]

On Thu, Oct 11, 2018 at 5:33 AM JORDI PALET MARTINEZ
<jordi.palet=[e-mail]> wrote:
> We have worked in an integrated version of two documents:
>
> draft-v6ops-byrne-dnssecaaaa
> draft-palet-sunset4-ipv6-ready-dns-00
>
> The new document is now:
>
> https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/?include_text=1

The new document starts with:
"This document defines the timing for implementing a worldwide
   IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
   global IPv6-only deployment."

So you are suggesting that DNS operators have to do some work (in
quite short timeframe) to facilitate something they might not even
care about...Not sure it would work.

Then there is a section 7 (Implementation Timeline) which look a bit
unrealistic. (I have to confess I wish we had a magic wand to make it
happen...).
If I let my imagination run wild...let's say a miracle has happened
and steps 1-3 are done.
Obviously *just* adding AAAA RR for A-only names has nothing to do
with enabling IPv6 for a service.
The service needs to have IPv6 connectivity (which might not even be
available in the specific location) it needs to be tested etc. Adding
AAAA w/o doing all of that would just negatively impact user
experience.
What would happen if a imaginary website cutekittens.example.net which
hosts popular videos of kittens (and koals) suddenly gets AAAA RR in
DNS w/o IPv6 being properly enabled for it? Or even worse, the
webservice would respond to TCP handshake but would not be able to
server users over IPv6? Well, I'm sure 99.9% of level1 techsupport
engineers would tell the unhappy customers "disable IPv6 on your
device and it would solve your issue". I'm not sure it's want we want.

Also, how exactly are you suggesting to enforce the step 4?

Last but not least: "If there is a failure at the
   deadline in complying with those requirements, the relevant NS, MUST
   be temporarily suspended until there is a subsequent successful
   verification."
So an NS for cutekittens.example.net got suspended (whatever it means).
So the server would become unreachable? How could it be fixed/get IPv6 enabled?

"MUST" in RFCs are (usually) for a reason. If you do not follow MUST
smth bad would happen.
This draft has a lot of MUST which (IMHO) could not be enforced.

To sum up, I found draft-v6ops-byrne-dnssecaaaa be more useful and
realistic. It explains why if you want to use DNSSEC for your zone,
you should consider enable IPv6.

> -----Mensaje original-----
> De: <[e-mail]>
> Fecha: miércoles, 10 de octubre de 2018, 20:30
> Para: Jordi Palet <[e-mail]>, Jordi Palet Martinez <[e-mail]>, Cameron Byrne <[e-mail]>, Cameron Byrne <[e-mail]>
> Asunto: New Version Notification for draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
>
>
>     A new version of I-D, draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
>     has been successfully submitted by Jordi Palet Martinez and posted to the
>     IETF repository.
>
>     Name:               draft-bp-v6ops-ipv6-ready-dns-dnssec
>     Revision:   00
>     Title:              IPv6-Ready DNS/DNSSSEC Infrastructure
>     Document date:      2018-10-10
>     Group:              Individual Submission
>     Pages:              6
>     URL:            https://www.ietf.org/internet-drafts/draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
>     Status:         https://datatracker.ietf.org/doc/draft-bp-v6ops-ipv6-ready-dns-dnssec/
>     Htmlized:       https://tools.ietf.org/html/draft-bp-v6ops-ipv6-ready-dns-dnssec-00
>     Htmlized:       https://datatracker.ietf.org/doc/html/draft-bp-v6ops-ipv6-ready-dns-dnssec
>
>
>     Abstract:
>        This document defines the timing for implementing a worldwide
>        IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the
>        global IPv6-only deployment.
>
>        A key issue for this, is the need for a global support of DNSSEC and
>        DNS64, which in some scenarios do not work well together.  This
>        document states that any DNSSEC signed resources records should
>        include a native IPv6 resource record as the most complete and
>        expedient path to solve any deployment conflict with DNS64 and DNSSEC
>
>
>
>
>     Please note that it may take a couple of minutes from the time of submission
>     until the htmlized version and diff are available at tools.ietf.org.
>
>     The IETF Secretariat
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.consulintel.es
> The IPv6 Company
>
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops



-- 
SY, Jen Linkova aka Furry