Subject: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 25 Mar 2019 15:08:50 +0100

Hi all,

We have published a new version of this document, taking in consideration a few inputs, clarified some examples, nits, etc.

https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/?include_text=1

Regards,
Jordi

El 25/3/19 15:05, "[email-masked]" <[email-masked]> escribió:

    A new version of I-D, draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
    has been successfully submitted by Jordi Palet Martinez and posted to the
    IETF repository.
    
    Name:		draft-palet-v6ops-464xlat-opt-cdn-caches
    Revision:	01
    Title:		464XLAT Optimization for CDNs/Caches
    Document date:	2019-03-25
    Group:		Individual Submission
    Pages:		10
    URL:            https://www.ietf.org/internet-drafts/draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cdn-caches/
    Htmlized:       https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt-cdn-caches-01
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-palet-v6ops-464xlat-opt-cdn-caches
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-palet-v6ops-464xlat-opt-cdn-caches-01
    
    Abstract:
       This document describes the drawbacks of IP/ICMP Translation
       Algorithm (SIIT), when used as a NAT46, and IPv4-only devices or
       applications initiate traffic flows to dual-stack CDNs (Content
       Delivery Networks) or Caches, which are forced to be translated back
       to IPv4 by a NAT64.  The document proposes possible solutions to
       avoid that.

    
    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.theipv6company.com
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.

---

From: Dave Plonka <[email-masked]>
Date: Thu, 28 Mar 2019 15:35:09 +0100

Hi Jordi -

Thanks for this draft presentation in v6ops.

As we mentioned in the v6ops meeting, I don't think a CPE (or any
remote host) can reliably determine if a given IPv4 DNS client is an
IPv4-only host.

For one, this is because dual-stack hosts have at least two different
IP addresses (v4 and v6), as you know, and there isn't a simple way to
remotely determine that a given IPv4 address and a given IPv6 address
are actually bound to the same host's interface(s), or even to enforce
that a dual-stack host will query the same DNS recursive service when
using two (or more) different client (IPv4 and IPv6) addresses.

However, for your draft, couldn't we just eliminate any attempt to
determine if any hosts are v4-only or not, and always synthesize the
IPv4 DNS answers?

I'm not saying I'm in favor of the mechanism overall, just saying we
could avoid the unnecessary and error-prone step of trying to
determine if a host is v4 only.

Does that make sense?

Thanks,
Dave

On Mon, Mar 25, 2019 at 3:09 PM JORDI PALET MARTINEZ
<jordi.palet=[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

--

[email-masked]  http://www.cs.wisc.edu/~plonka/

---

From: Alejandro D'Egidio <[email-masked]>
Date: Thu, 28 Mar 2019 11:58:21 -0300 (ART)

Hello Dave,
I hope you are doing well.
Is you question related to approach 4 where we suggest to use DNS?
The idea was to share the idea of what happens on different scenarios when we have a IPv4-only device/app and how can we solve the issue with different approaches.

Using DNS, yes, I think also could be a good idea to always check if there is an AAAA record for any A record requested and add that relationship to the EAMT.

Regards,
Alejandro

----- Mensaje original -----
De: "Dave Plonka" <[email-masked]>
Para: "JORDI PALET MARTINEZ" <jordi.palet=[email-masked]>
CC: "[email-masked] list" <[email-masked]>
Enviados: Jueves, 28 de Marzo 2019 11:35:09
Asunto: Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt

Hi Jordi -

Does that make sense?

Thanks,
Dave

--

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Mar 2019 16:49:24 +0100

Hi Dave,

After the meeting, I figured out that that's probably easier and no need to determine if it is an IPv4-only host.

We can just create the EAMT entry for any A request if there is a corresponding AAAA which doesn't contain the WKP or NSP. This means that the end-host (CDN) is dual-stacked.

Then any host using the A record will automatically get the NAT46 translated to the "real" AAAA, not the one with the WKP or NSP, so we fulfil the intended optimization not requiring knowing if the host is IPv4-only.

I think that's what you are meaning?

The other think is how to select what AAAA to use if there are several.

I really think it will be interesting to get some co-authors, or at least good inputs from CDN/caches operators on this.

Regards,
Jordi

El 28/3/19 15:35, "Dave Plonka" <[email-masked]> escribió:

    Hi Jordi -

    

    
    Does that make sense?
    
    Thanks,
    Dave

    
    --

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 28 Mar 2019 17:11:03 +0100

Reading more questions raised in the meeting from the etherpad:

1) Mikael mention that Chromecast (and other devices), use a manually configured DNS such as 8.8.8.8. I'm not sure if Chromecast is dual-stack, if that's the case, then they will prefer IPv6, so not an issue. Also, if they are IPv4-only, they still get the optimization with the small change that I mention in my previous email. Instead of creating the EAMT entries by "guessing" if the device is IPv4 only, we just create the entries when there is an A request and the corresponding AAAA is available with a GUA (i.e., not using the NSP or WKP).

2) Jared indicated that there is more and more work to move DNS from host control to apps. I agree. However, the problem that we are solving is OLD IPv4-only (like smartTVs and STBs) that aren't updated to IPv6, even less updated to use DTLS or DoH, etc.

Once more, the solution must not affect those apps that are dual-stack or use their own "DNS", they just will not get any optimization if they try to reach an IPv4 destination.

Regards,
Jordi

El 28/3/19 16:50, "v6ops en nombre de JORDI PALET MARTINEZ" <[email-masked] en nombre de jordi.palet=[email-masked]> escribió:

    Hi Dave,

    

    
    
    Regards,
    Jordi

    
        Hi Jordi -

        

        
        Does that make sense?
        
        Thanks,
        Dave

        
        --

---

From: Alejandro D'Egidio <[email-masked]>
Date: Thu, 28 Mar 2019 15:55:16 -0300 (ART)

Hello,
Just an additional comment...

----- Mensaje original -----
> De: "JORDI PALET MARTINEZ" <jordi.palet=[email-masked]>
> Para: "[email-masked] list" <[email-masked]>
> Enviados: Jueves, 28 de Marzo 2019 12:49:24

> We can just create the EAMT entry for any A request if there is a corresponding
> AAAA which doesn't contain the WKP or NSP. This means that the end-host (CDN)
> is dual-stacked.
> 
> Then any host using the A record will automatically get the NAT46 translated to
> the "real" AAAA, not the one with the WKP or NSP, so we fulfil the intended
> optimization not requiring knowing if the host is IPv4-only.
> 
Regarding this, If I'm not wrong in general CDNs offer one Answer because they need to manage the load balancing between servers with DNS answers.

> 
> I really think it will be interesting to get some co-authors, or at least good
> inputs from CDN/caches operators on this.
> 
> Regards,
> Jordi
> 
> 
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Mar 2019 06:56:47 +0100

On Mar 28, 2019, at 5:11 PM, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:
> 1) Mikael mention that Chromecast (and other devices), use a manually configured DNS such as 8.8.8.8.

This is a different comment than Jordi's topic, but I'm of the opinion that the use of services like 8.8.8.8 by default overrides what might be local policy. I'd really like to see such things use 8.8.8.8 (or 1.1.1.1 or whatever) only as a backup in case the network didn't tell it what DNS server to use.

Reason: if nothing else, the device might be used in a network that has local services that need to be accessible. Google is well informed, but even Google doesn't know everything, and specifically doesn't know about such services. To me, this design decision borders on arrogance, and certainly isn't about enabling user control of the services they use. Net Neutrality and all that...
--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Martin Huněk <[email-masked]>
Date: Fri, 29 Mar 2019 08:50:54 +0100

Hi Jordi,

I would like to point out a question I've asked to you after session:

Would it work if a multiple sides would be under the single proxy on IPv4, but 
on separate hosts on IPv6? Wouldn't it make just one side accessible and rest 
would be pointed to wrong server?

Regards,
Martin

Dne čtvrtek 28. března 2019 16:49:24 CET, JORDI PALET MARTINEZ napsal(a):
> We can just create the EAMT entry for any A request if there is a
> corresponding AAAA which doesn't contain the WKP or NSP. This means that
> the end-host (CDN) is dual-stacked.
> 
> Then any host using the A record will automatically get the NAT46 translated
> to the "real" AAAA, not the one with the WKP or NSP, so we fulfil the
> intended optimization not requiring knowing if the host is IPv4-only.
> 
> I really think it will be interesting to get some co-authors, or at least
> good inputs from CDN/caches operators on this.
> 
> Regards,
> Jordi
> 
> 
> 
>     > We have published a new version of this document, taking in
>     > consideration a few inputs, clarified some examples, nits, etc.
>     > 
>     >     A new version of I-D,
>     >     draft-palet-v6ops-464xlat-opt-cdn-caches-01.txt
>     >     URL:           
>     >     https://www.ietf.org/internet-drafts/draft-palet-v6ops-464xlat-op
>     >     t-cdn-caches-01.txt Status:        
>     >     https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-cd
>     >     n-caches/ Htmlized:      
>     >     https://tools.ietf.org/html/draft-palet-v6ops-464xlat-opt-cdn-cac
>     >     hes-01 Htmlized:      
>     >     https://datatracker.ietf.org/doc/html/draft-palet-v6ops-464xlat-o
>     >     pt-cdn-caches Diff:          
>     >     https://www.ietf.org/rfcdiff?url2=draft-palet-v6ops-464xlat-opt-c
>     >     dn-caches-01    >     
>     >     Abstract:
>     >     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
>     > 
>     > 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.
>     > 
>     > 
>     > 
> 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.
> 
> 
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 29 Mar 2019 08:56:17 +0100

Hi Martin,

Not sure to completely understand you. May be an explicit example will make it more obvious to me, but see first the following:

The EAMT will create an entry with an AAAA (if available) for each A.

So, if it works with "DNS" it will work with the EAMT.

Regards,
Jordi

El 29/3/19 8:52, "v6ops en nombre de Martin Huněk" <[email-masked] en nombre de [email-masked]> escribió:

    Hi Jordi,

    
    Regards,
    Martin

---

From: Martin Huněk <[email-masked]>
Date: Fri, 29 Mar 2019 09:05:26 +0100

Let say:

# Here is HTTP proxy
www.example.com   IN A 192.0.2.64
www.example.net   IN A 192.0.2.64

# Here are IPv6-only hosts
www.example.com   IN AAAA 2001:db8::1:1
www.example.net   IN AAAA 2001:db8::2:1

Now if one (or multiple) host asks for both sides what would be in EAMT?

Martin

Dne pátek 29. března 2019 8:56:17 CET, JORDI PALET MARTINEZ napsal(a):
> Hi Martin,
> 
> Not sure to completely understand you. May be an explicit example will make
> it more obvious to me, but see first the following:
> 
> El 29/3/19 8:52, "v6ops en nombre de Martin Huněk" <[email-masked]
> en nombre de [email-masked]> escribió:
> 
>     Hi Jordi,
> 
>     Would it work if a multiple sides would be under the single proxy on
> IPv4, but on separate hosts on IPv6? Wouldn't it make just one side
> accessible and rest would be pointed to wrong server?
> 
>     Regards,
>     Martin
> 
>     > After the meeting, I figured out that that's probably easier and no
>     > need to
>     > determine if it is an IPv4-only host.
>     > 
>     > Then any host using the A record will automatically get the NAT46
>     > translated to the "real" AAAA, not the one with the WKP or NSP, so we
>     > fulfil the intended optimization not requiring knowing if the host is
>     > IPv4-only.
>     > 
>     >     > https://datatracker.ietf.org/doc/draft-palet-v6ops-464xlat-opt-c
>     >     > dn-cac
>     >     > hes/?include_text=1
>     >     > 
>     >     > Regards,
>     >     > Jordi
>     >     > 
>     >     > El 25/3/19 15:05, "[email-masked]" <internet-
> 
>     [email-masked]> escribió:
>     >     >     A new version of I-D,
>     >     >     has been successfully submitted by Jordi Palet Martinez and
>     >     >     posted
>     >     >     to the
>     >     >     IETF repository.
>     >     >     
>     >     >     https://www.ietf.org/rfcdiff?url2=draft-palet-v6ops-464xlat->     >     >     opt-c
>     >     >     dn-caches-01    >
>     >     >     
>     >     >     Abstract:
>     >     >        Algorithm (SIIT), when used as a NAT46, and IPv4-only
>     >     >        devices
>     >     >        or
>     >     >        Delivery Networks) or Caches, which are forced to be
>     >     >        translated
>     >     >        back
>     >     >        to IPv4 by a NAT64.  The document proposes possible
>     >     >        solutions
>     >     >        to
>     >     >        avoid that.
>     >     >     
>     > or

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 29 Mar 2019 09:09:44 +0100

Unless I'm wrong, this will also fail with the standard NAT64/DNS64 behavior !

So, we aren't breaking anything at it is broken already :-(

Regards,
Jordi

El 29/3/19 9:06, "v6ops en nombre de Martin Huněk" <[email-masked] en nombre de [email-masked]> escribió:

    Let say:
    
    # Here is HTTP proxy

    
    Martin

---

From: Martin Huněk <[email-masked]>
Date: Fri, 29 Mar 2019 09:17:50 +0100

I'm not sure about that. In case of NAT64 it would reach the destination by 
IPv4, then trough a proxy to IPv6 only host. Same goes for 464XLAT. Not 
mentioning that in such case it should go directly over IPv6.

Maybe I'm just imagine things, I'm not in content delivery, but I think that 
this situation might happen in IPv6-only datacenter.

Martin

Dne pátek 29. března 2019 9:09:44 CET, JORDI PALET MARTINEZ napsal(a):
> El 29/3/19 9:06, "v6ops en nombre de Martin Huněk" <[email-masked]
>     >     Dne čtvrtek 28. března 2019 16:49:24 CET, JORDI PALET MARTINEZ
> 
>     napsal(a):
>     >     > Hi Dave,
>     >     > 
>     >     > corresponding AAAA which doesn't contain the WKP or NSP. This
>     >     > means
>     >     > that
>     >     > I really think it will be interesting to get some co-authors, or
>     >     > at
>     >     > least
>     >     >     remote host) can reliably determine if a given IPv4 DNS
>     >     >     client is
>     >     >     an
>     >     >     IPv4-only host.
>     >     >     
>     >     >     IP addresses (v4 and v6), as you know, and there isn't a
>     >     >     simple
>     >     >     way to
>     >     >     remotely determine that a given IPv4 address and a given
>     >     >     IPv6
>     >     >     address
>     >     >     are actually bound to the same host's interface(s), or even
>     >     >     to
>     >     >     enforce
>     >     >     that a dual-stack host will query the same DNS recursive
>     >     >     service
>     >     >     when
>     >     >     determine if any hosts are v4-only or not, and always
>     >     >     synthesize
>     >     >     the
>     >     >     IPv4 DNS answers?
>     >     >     
>     >     >     I'm not saying I'm in favor of the mechanism overall, just
>     >     >     saying
>     >     >     we
>     >     >     >     https://www.ietf.org/internet-drafts/draft-palet-v6ops
>     >     >     >     -464xl
>     >     >     >     at-op
>     >     >     >     https://datatracker.ietf.org/doc/draft-palet-v6ops-464
>     >     >     >     xlat-o
>     >     >     >     pt-cd
>     >     >     >     n-caches/ Htmlized:
>     >     >     >     https://tools.ietf.org/html/draft-palet-v6ops-464xlat->     >     >     >     opt-cd
>     >     >     >     n-cac
>     >     >     >     hes-01 Htmlized:
>     >     >     >     https://datatracker.ietf.org/doc/html/draft-palet-v6op
>     >     >     >     s-464x
>     >     >     >     lat-o
>     >     >     >     pt-cdn-caches Diff:
>     >     >     >     https://www.ietf.org/rfcdiff?url2=draft-palet-v6ops-46
>     >     >     >     4xlat->     >     >     opt-c dn-caches-01    >
>     >     >     >     
>     >     >     >     Abstract:
>     >     >     >        applications initiate traffic flows to dual-stack
>     >     >     >        CDNs
>     >     >     >        (Content
>     >     >     >     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
>     >     >     > 
>     >     >     > strictly prohibited and will be considered a criminal
>     >     >     > offense.
>     >     >     > If you
>     >     >     > are not the intended recipient be aware that any
>     >     >     > disclosure,
>     >     >     > copying,
>     >     >     > partially, including attached files, is strictly
>     >     >     > prohibited,
>     >     >     > will be
>     >     > confidential. The information is intended to be for the
>     >     > exclusive use
>     >     > of
>     >     > prohibited and will be considered a criminal offense. If you are
>     >     > not
>     >     > the
>     >     > intended recipient be aware that any disclosure, copying,
>     >     > distribution
>     >     > or

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 29 Mar 2019 09:30:12 +0100

It may depend on "where" is located the proxy.

I don't think this is something that is used. If you have a dual-stack service or website, I don't see why it is practical to have it in different hosts. I see the same host having different apache "virtual servers" if you really want to show different contents for IPv4 and IPv6, but even do ... I really doubt.

If an IPv6-only DC is using SIIT-DC, I also don't see the case where this will fail. I will investigate a bit more, just in case.

Regards,
Jordi

El 29/3/19 9:18, "v6ops en nombre de Martin Huněk" <[email-masked] en nombre de [email-masked]> escribió:

    
    Martin

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 29 Mar 2019 14:14:31 +0100

Hi Fred,

I fully agree. It breaks things, even it may happen that it means that some networks avoid those devices working at all, because they have strict rules about the use of their own DNS resolvers, etc. (not saying either this is right).

I've described that as "manual configuration of foreign DNS" in https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/.

In the case of NAT64 it simply means you break your connectivity for those devices/apps that are IPv4-only, which fortunately doesn't happen with 464XLAT, but you lose optimization (forcing the use of the CLAT), but at the same time it provides the advantage of ensuring that DNSSEC is not broken.

All that said, how we avoid that?

Do you think a BCP will solve it? Do app/device developers follow it?

Regards,
Jordi

El 29/3/19 6:57, "v6ops en nombre de Fred Baker" <[email-masked] en nombre de [email-masked]> escribió:

---

From: Richard Patterson <[email-masked]>
Date: Fri, 29 Mar 2019 14:24:37 +0100

Jordi, implementation details aside, I think this is a useful topic to
discuss and document.  Bypassing network-side translators has a very
tangible financial benefit to an operator, and was definitely taken in
to consideration during my IPv4aaS technology assessment and decision
making.

I'd like to add an alternative to the DNS/CLAT-based approach, there's
also the "deterministic addressing" approach that could be used, as
briefly touched on in RFC75977 Section 12.3.
i.e. if the CDN supports IPv4-derived IPv6 address using RFC6052, from
the NAT64 prefix, or the prefix defined in the MAP DMR, then we won't
need to do any DNS record-synthesizing, the network will simply use
the more specific IPv6 route direct to the CDN node, bypassing the
NAT64 translator.

-Rich

---

From: Jordi Palet Martinez <[email-masked]>
Date: Fri, 29 Mar 2019 14:51:07 +0100

I guess you don’t mean RFC75977 ?

I agree and we’ve investigated that as well, I think is the same we described as the first approach in the ID, however:
A) Some CDN operators don’t want to use the WKP or NSP, at least I got those responses at the moment. They even mention a charge to customers for that.
B) This will not work when the CDN/caches aren’t in the ISP network, i.e., in a IX

I think it will be better a “self-contained” solution, even if the optimization may be not done in 100% of the cases.

Regards,
Jordi

> El 29 mar 2019, a las 14:24, Richard Patterson <[email-masked]> escribió:
>

---

From: Richard Patterson <[email-masked]>
Date: Fri, 29 Mar 2019 15:00:35 +0100

Sorry, RFC7599 MAP-T.

---

From: Erik Nygren <[email-masked]>
Date: Fri, 29 Mar 2019 16:58:37 -0400

For those who haven't seen it, this was perhaps one of the hottest topics
at this IETF.
See the discussions in DoH, DPRIVE, a session Wednesday afternoon, and
elseswhere.
There is a strong desire by some parties to use "more trustworthy DNS
resolvers"
which means not necessarily trusting the network-offered resolver.
I suspect this may not immediately impact consumer electronics,
but it could impact some browsers.

Some response perspectives, at least one of which mentions DNS64:

https://tools.ietf.org/html/draft-reid-doh-operator-00
https://tools.ietf.org/html/draft-livingood-doh-implementation-risks-issues-03

For what it's worth, Firefox doesn't yet do DNS64 synthesis when using a
DoH server
(and actually also does happy eyeballs backwards when doing DoH),
but now has bugs open to fix both.

      Erik

On Fri, Mar 29, 2019 at 1:57 AM Fred Baker <[email-masked]> wrote:

> This is a different comment than Jordi's topic, but I'm of the opinion
> that the use of services like 8.8.8.8 by default overrides what might be
> local policy. I'd really like to see such things use 8.8.8.8 (or 1.1.1.1 or
> whatever) only as a backup in case the network didn't tell it what DNS
> server to use.
>
> Reason: if nothing else, the device might be used in a network that has
> local services that need to be accessible. Google is well informed, but
> even Google doesn't know everything, and specifically doesn't know about
> such services. To me, this design decision borders on arrogance, and
> certainly isn't about enabling user control of the services they use. Net
> Neutrality and all that...
>
> The fact that there is a highway to hell and a stairway to heaven is an
> interesting comment on projected traffic volume...
>

---

From: Mark Smith <[email-masked]>
Date: Sat, 30 Mar 2019 10:43:21 +1100

Hi Fred,

> Neutrality and all that...

The trouble Google would have with retail consumer focused electronics
products like the Chromecast is that non-technical customers will likely
attribute all faults, whose effects appear on the device, to the device and
its maker, in particular if those faults occur when the customer first
tries to use it.

So if an ISP is running badly performing or unreliable DNS resolvers that
impact Chromecast performance visibly to the customer, or the customer's
CPE's DNS resolver is badly performing (which wouldn't be a surprise given
how low end their CPUs can be, and how limited their memory can be meaning
limited DNS caching), customers are likely to attribute blame to Google and
the Chromecast, rather than the ISP or the CPE that is the actual cause of
the problem.

So I think Google running and preferring their own DNS resolvers to try to
better ensure their product provides a good customer experience makes sense.

I suppose they could have instead tested ISP DNS resolver performance and
put up an error message to say "Call your ISP or replace your CPE because
DNS resolving performance is bad."

Lodging a fault with an ISP and waiting for it to be resolved also isn't a
good customer experience, and it may not have occurred to them when they
developed the Chromecast because they already had a reliable and well
performing DNS resolver service that they operated.

Google are now also running public NTP servers, I wouldn't be all that
surprised if they've gone to that expense for similar end-user/customer
experience reasons.

Regards,
Mark.