On Tue, Sep 11, 2018 at 10:03 PM Owen DeLong <owen@delong.com> wrote:

On Sep 11, 2018, at 21:58 , Christopher Morrow <morrowc.lists@gmail.com> wrote:

On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe <jerry@jtcloe.net> wrote:

OpenDNS, or anyone for that matter, should never see 100.64/10 ip's. If they do, something is wrong at the source, and OpenDNS wouldn't be able to reply anyway (or at least have the reply route back to the user).

maybeopendns peers directly with such an eyeball network? and in that case maybe they have an agreement to accept traffic from the 100.64 space?

They’d only be able to do one such agreement per routing environment.

sure, I hear DNS servers are cheap and small, and easy to manage...

Managing that would be _UGLY_ for the first one and __UGLY__ at scale for anything more than one.

meh? it's a dns server stack and router(s) for peering to the customer + world... it's really not THAT hard to automate and deploy...

and really for 'single customer' or 'non overlapping sets of customers' it's not like they need lots of horsepower here, right? this is ... simple to do, simple to manage and simple to maintain.

It also pretty much eliminates potential for geographic diversity and anycast for a provider in a local geography.

there are more than one building in the georgrahy, and probably/maybe these providers appear in more than one local, right? so... a dns provider can arrive in the right matrix of locations and connect + provide routing-data .... done.

Certainly not something I’d choose to do if I were OpenDNS unless someone arrived with a very large truck full of gold, diamonds, or other valuable hard assets.

meh.. again, say the customer covers the cost of gear + network + maintenance for the previous parts.. .then it's just managing 'another' remote dns server .. .something I understand they do fairly well even? once you have a hundred of somethign deployed you are automated or .. you are doing it wrong.

Owen