SAFNOG-4/EANOG/tzNOG - Just Under 2 Weeks To Go!

[Mark Tinka]

Hi all.

This is just a reminder that with a little under 2 weeks to go the
upcoming SAFNOG-4/EANOG/tzNOG meeting to be held in Dar Es Salaam, 24th
- 29th September, please remember to register your attendance at
http://www.safnog.org/ so you don't miss the meeting.

The agenda is now up on the web site at http://www.safnog.org/#agenda
with just a few slots left which are filling fast. In case you feel like
you have an interesting technical and operational talk that you'd like
to share with the community at this meeting, please feel free to submit
it for the program committee to review as soon as possible, at:

    https://papers.safnog.org/user/login.php?event=76

Key talks that you would be looking forward include:

  * Ben Roberts (Liquid Telecom), talking about the latency realities of
intra-African Internet communication.

  * The 3 major data centre projects that are happening in South Africa,
Kenya and Uganda.

  * The DNSSEC key rollover due on 11th October, and what to look
forward to, as explained by Amreesh Phokeer.

  * An IPv6 Deployathon 2-day workshop headed by Mukom Akong Tamon.

  * ... and so many more.

There will be 2 social events where delegates can network, share a
drink, some good food, and stand a chance to win either an iPhone X or
AppleTV 4K.

We have secured a special discount rate at the hotel venue for all
SAFNOG/EANOG/tzNOG participants. More details are available at
http://www.safnog.org/#venue .

We look forward to seeing you in Dar Es Salaam.

Mark Tinka
On Behalf of the SAFNOG-4/EANOG/tzNOG Organising Committee

Re: QWEST you have broken DNS servers

[Mark Andrews]

Yes please.

> On 13 Sep 2018, at 2:45 am, Anne P. Mitchell, Esq.  
> wrote:
> 
> 
> Would you like us to send this to our Qwest/CenturyLink contact?
> 
> Anne P. Mitchell, 
> Attorney at Law
> GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant
> Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
> Legislative Consultant
> CEO/President, Institute for Social Internet Public Policy
> Legal Counsel: The CyberGreen Institute
> Legal Counsel: The Earth Law Center
> Member, California Bar Association
> Member, Cal. Bar Cyberspace Law Committee
> Member, Colorado Cyber Committee
> Member, Board of Directors, Asilomar Microcomputer Workshop
> Ret. Professor of Law, Lincoln Law School of San Jose
> Ret. Chair, Asilomar Microcomputer Workshop
> 
> 
> 
>> 
>> I know it takes some time to upgrade DNS servers to ones that are actually
>> protocol compliant but 4+ years is ridiculous.  Your servers are the only
>> ones serving the Alexa top 1M sites or the GOV zone that still return BADVERS
>> to EDNS queries with a EDNS option present.  This was behaviour made up by
>> your DNS vendor.  The correct response to EDNS options that are not 
>> understood
>> is to IGNORE them.  This allows clients and servers to deploy support for
>> new options independently of each other.
>> 
>> Additionally this is breaking DNSSEC validation of the signed zones your 
>> clients
>> have you serving.  They expect you to be using EDNS compliant name servers 
>> for
>> this role which you are not.  No, we are not working around this breakage in 
>> the
>> resolver.
>> 
>> Mark
>> 
>> % dig soa frc.gov. @208.44.130.121 +norec
>> 
>> ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 59707
>> ;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; Query time: 66 msec
>> ;; SERVER: 208.44.130.121#53(208.44.130.121)
>> ;; WHEN: Tue Sep 11 06:08:41 UTC 2018
>> ;; MSG SIZE  rcvd: 23
>> 
>> % dig soa frc.gov. @208.44.130.121 +norec +nocookie
>> 
>> ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec +nocookie
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16876
>> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
>> 
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;frc.gov.IN  SOA
>> 
>> ;; ANSWER SECTION:
>> frc.gov. 86400   IN  SOA sauthns2.qwest.net. 
>> dns-admin.qwestip.net. 2180320527 10800 3600 604800 86400
>> 
>> ;; AUTHORITY SECTION:
>> frc.gov. 86400   IN  NS  sauthns1.qwest.net.
>> frc.gov. 86400   IN  NS  sauthns2.qwest.net.
>> 
>> ;; Query time: 66 msec
>> ;; SERVER: 208.44.130.121#53(208.44.130.121)
>> ;; WHEN: Tue Sep 11 06:19:33 UTC 2018
>> ;; MSG SIZE  rcvd: 145
>> 
>> % grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep edns=ok | 
>> awk '{print $3}' | sort -u 
>> (sauthns1.qwest.net.):
>> (sauthns2.qwest.net.):
>> % grep ednsopt=badvers reports-full/gov-full.2018-09-11T00:00:06Z  | grep 
>> edns=ok | awk '{print $3}' | sort -u
>> (sauthns1.qwest.net.):
>> (sauthns2.qwest.net.):
>> % 
>> 
>> -- 
>> Mark Andrews, ISC
>> 1 Seymour St., Dundas Valley, NSW 2117, Australia
>> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
>> 
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: OpenDNS CGNAT Issues

[valdis . kletnieks]

On Wed, 12 Sep 2018 09:42:11 -0700, Owen DeLong said:
> If you do it for a mere footlocker, I will be happy to watch and laugh.

So.. taking this as a size: 
https://www.containerstore.com/s/storage/trunks/black-rolling-trunk-with-tray/12d?productId=1230

We'll shave off an inch or so off each dimension to get inside dimension.
30 x 16 x 15 is 7200 cubic inches.  Gold is 11.1 ounces per cubic inch.
(Oh, you'll need to get a special cart for that foot locker, I'm pretty sure
the provided wheels won't support the 4,995 pounds of gold...)
(Divide by 1.09 to convert to troy ounces)
Gold is sitting at US$1,198.15 per troy ounce today.

US$87,849,677.06

Still laughing?


pgp5oeAGs042g.pgp
Description: PGP signature

Re: OpenDNS CGNAT Issues

[Denys Fedoryshchenko]

On 2018-09-12 19:40, Lee Howard wrote:

On 09/11/2018 09:31 AM, Matt Hoppes wrote:

So don't CGNat?  Buy IPv4 addresses at auction?


Buy IPv4 addresses until CGN is cheaper. If a customer has to call,
and you have to assign an IPv4 address, you have to recover the cost
of that call and address.
While ((CostOfCall + CostOfAddress)*NumberOfCalls) >
(CostOfAddress*NumberOfNewCustomers):
 BuyAddresses(NumberOfNewCustomers)

Meanwhile, deploy IPv6, and move toward IPv4aaS, probably 464xlat or
MAP, but your religion may vary. That way your "CGN" is an IPv6-IPv4
translator, and that's easier than managing dual-stack.

At the very least, dual-stack your web sites now, so the rest of us
can get to it without translation.



Just regarding ipv4 issue solution, this process can be somehow 
automated by detecting those who use opendns(by netflow, for example), 
to avoid "CostOfCall" part.
Also, to avoid false claiming of nat pool, he can nat DNS requests for 
OpenDNS to different ip pool, that cannot be claimed.

Re: QWEST you have broken DNS servers

[Anne P. Mitchell, Esq.]

Would you like us to send this to our Qwest/CenturyLink contact?

Anne P. Mitchell, 
Attorney at Law
GDPR, CCPA (CA) & CCDPA (CO) Compliance Consultant
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Legislative Consultant
CEO/President, Institute for Social Internet Public Policy
Legal Counsel: The CyberGreen Institute
Legal Counsel: The Earth Law Center
Member, California Bar Association
Member, Cal. Bar Cyberspace Law Committee
Member, Colorado Cyber Committee
Member, Board of Directors, Asilomar Microcomputer Workshop
Ret. Professor of Law, Lincoln Law School of San Jose
Ret. Chair, Asilomar Microcomputer Workshop


 
> 
> I know it takes some time to upgrade DNS servers to ones that are actually
> protocol compliant but 4+ years is ridiculous.  Your servers are the only
> ones serving the Alexa top 1M sites or the GOV zone that still return BADVERS
> to EDNS queries with a EDNS option present.  This was behaviour made up by
> your DNS vendor.  The correct response to EDNS options that are not understood
> is to IGNORE them.  This allows clients and servers to deploy support for
> new options independently of each other.
> 
> Additionally this is breaking DNSSEC validation of the signed zones your 
> clients
> have you serving.  They expect you to be using EDNS compliant name servers for
> this role which you are not.  No, we are not working around this breakage in 
> the
> resolver.
> 
> Mark
> 
> % dig soa frc.gov. @208.44.130.121 +norec
> 
> ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: BADVERS, id: 59707
> ;; flags: qr ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; Query time: 66 msec
> ;; SERVER: 208.44.130.121#53(208.44.130.121)
> ;; WHEN: Tue Sep 11 06:08:41 UTC 2018
> ;; MSG SIZE  rcvd: 23
> 
> % dig soa frc.gov. @208.44.130.121 +norec +nocookie
> 
> ; <<>> DiG 9.12.1 <<>> soa frc.gov. @208.44.130.121 +norec +nocookie
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16876
> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;frc.gov. IN  SOA
> 
> ;; ANSWER SECTION:
> frc.gov.  86400   IN  SOA sauthns2.qwest.net. 
> dns-admin.qwestip.net. 2180320527 10800 3600 604800 86400
> 
> ;; AUTHORITY SECTION:
> frc.gov.  86400   IN  NS  sauthns1.qwest.net.
> frc.gov.  86400   IN  NS  sauthns2.qwest.net.
> 
> ;; Query time: 66 msec
> ;; SERVER: 208.44.130.121#53(208.44.130.121)
> ;; WHEN: Tue Sep 11 06:19:33 UTC 2018
> ;; MSG SIZE  rcvd: 145
> 
> % grep ednsopt=badvers reports/alexa1m.2018-08-26T00:00:06Z | grep edns=ok | 
> awk '{print $3}' | sort -u 
> (sauthns1.qwest.net.):
> (sauthns2.qwest.net.):
> % grep ednsopt=badvers reports-full/gov-full.2018-09-11T00:00:06Z  | grep 
> edns=ok | awk '{print $3}' | sort -u
> (sauthns1.qwest.net.):
> (sauthns2.qwest.net.):
> % 
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

Re: OpenDNS CGNAT Issues

[Owen DeLong]

If you do it for a mere footlocker, I will be happy to watch and laugh.

Owen


> On Sep 12, 2018, at 9:11 AM, valdis.kletni...@vt.edu wrote:
> 
> On Wed, 12 Sep 2018 14:10:05 -, Kenny Taylor said:
> 
>> For a truckload of gold, I’m pretty sure most of us would make that work ☺
> 
> Unless they get underbid by the one of us willing to settle for a foot locker 
> full of gold.
> 

Re: OpenDNS CGNAT Issues

[Lee Howard]

On 09/11/2018 09:31 AM, Matt Hoppes wrote:

So don't CGNat?  Buy IPv4 addresses at auction?


Buy IPv4 addresses until CGN is cheaper. If a customer has to call, and 
you have to assign an IPv4 address, you have to recover the cost of that 
call and address.
While ((CostOfCall + CostOfAddress)*NumberOfCalls) > 
(CostOfAddress*NumberOfNewCustomers):

 BuyAddresses(NumberOfNewCustomers)

Meanwhile, deploy IPv6, and move toward IPv4aaS, probably 464xlat or 
MAP, but your religion may vary. That way your "CGN" is an IPv6-IPv4 
translator, and that's easier than managing dual-stack.


At the very least, dual-stack your web sites now, so the rest of us can 
get to it without translation.


Lee



On 9/11/18 9:28 AM, Ca By wrote:



On Tue, Sep 11, 2018 at 6:04 AM Matt Hoppes 
> wrote:


    That isn’t a solution. He still will need to dual stack and CGNat 
that.



But the flows that can support ipv6, will go ipv6 and not be subject 
to these abuse triggers.


Look, this list has monthly reports from some small network operator 
hurting their customers with CGN NAT. Meanwhile, the big guys like 
Comcast / Charter / ATT / Cox have moved onto ipv6.


Where does that leave the little guy with CGN?

Right here. Screaming into the avoid begging for help. Some special 
exception.


And, me, saying you had 10+ years of not deploying ipv6.  Here’s to 
the next 10 years of you email this list about your own failure to 
keep up with the times.


We will have this discussion again and again.  Not sure your 
customers will stick around, all they know is your CGN space got 
black listed from yet another service


#realtalk


    On Sep 11, 2018, at 08:54, Ca By mailto:cb.li...@gmail.com>> wrote:




    On Mon, Sep 10, 2018 at 9:12 PM Darin Steffl
    mailto:darin.ste...@mnwifi.com>> wrote:

    Hello,

    I have a ticket open with OpenDNS about filtering happening on
    some of our CGNAT IP space where a customer has "claimed" the
    IP as theirs so other customers using that same IP and OpenDNS
    are being filtered and not able to access sites that fall
    under their chosen filter.

    I have a ticket open from 6 days ago but it's not going
    anywhere fast.

    Can someone from OpenDNS contact me or point me to a contact
    there to help get this resolved? I believe we need to claim
    our CGNAT IP space so residential users can't claim IP's of
    their own.

    Thank you!


    You should provide your users ipv6, opendns supports ipv6 and
    likely will not have this issue you see

    https://www.opendns.com/about/innovations/ipv6/

    I am sure it may cost you time / money / effort. But this old
    thing we call ipv4 is in a death spiral, and it will just get
    worse and worse for you without ipv6.




    --     Darin Steffl
    Minnesota WiFi
    www.mnwifi.com 
    507-634-WiFi
     Like us on Facebook
    

Re: OpenDNS CGNAT Issues

[valdis . kletnieks]

On Wed, 12 Sep 2018 14:10:05 -, Kenny Taylor said:

> For a truckload of gold, I’m pretty sure most of us would make that work ☺

Unless they get underbid by the one of us willing to settle for a foot locker 
full of gold.



pgp6lNCVQkTiq.pgp
Description: PGP signature

Re: OpenDNS CGNAT Issues

[Owen DeLong]

Sure… The point was that short of that, anyone in their right mind wouldn’t 
bother.

Owen


> On Sep 12, 2018, at 7:10 AM, Kenny Taylor  wrote:
> 
> For a truckload of gold, I’m pretty sure most of us would make that work J
>  
> Kenny
>  
> From: NANOG  > On Behalf Of Owen 
> DeLong
> Sent: Tuesday, September 11, 2018 10:04 PM
> To: Christopher Morrow  >
> Cc: nanog list mailto:nanog@nanog.org>>
> Subject: Re: OpenDNS CGNAT Issues
>  
>  
> 
> 
> On Sep 11, 2018, at 21:58 , Christopher Morrow  > wrote:
>  
>  
> 
> On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe  > 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.
>  
> Managing that would be _UGLY_ for the first one and __UGLY__ at scale for 
> anything more than one.
>  
> It also pretty much eliminates potential for geographic diversity and anycast 
> for a provider in a local geography.
>  
> 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.
>  
> Owen

RE: OpenDNS CGNAT Issues

[Kenny Taylor]

For a truckload of gold, I’m pretty sure most of us would make that work ☺

Kenny

From: NANOG  On Behalf Of Owen 
DeLong
Sent: Tuesday, September 11, 2018 10:04 PM
To: Christopher Morrow 
Cc: nanog list 
Subject: Re: OpenDNS CGNAT Issues




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


On Tue, Sep 11, 2018 at 9:06 PM Jerry Cloe 
mailto:je...@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.

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

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

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.

Owen