<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 11, 2018, at 21:58 , Christopher Morrow <<a href="mailto:morrowc.lists@gmail.com" class="">morrowc.lists@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe <<a href="mailto:jerry@jtcloe.net" class="">jerry@jtcloe.net</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u class=""></u>
<div class=""><p class="">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).<br class=""></p></div></blockquote><div class=""><br class=""></div><div class="">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?</div></div></div></div></blockquote><div><br class=""></div>They’d only be able to do one such agreement per routing environment.</div><div><br class=""></div><div>Managing that would be _UGLY_ for the first one and __UGLY__ at scale for anything more than one.</div><div><br class=""></div><div>It also pretty much eliminates potential for geographic diversity and anycast for a provider in a local geography.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>Owen</div><div><br class=""></div></body></html>