Re: Question about ISP billing procedures

[Ben Cannon]

You have to zero it.

-Ben

> On Feb 27, 2019, at 8:10 PM, Michael Gehrmann  wrote:
> 
> From my provider days if you miss data you can't bill it or assume zero.
> 
> Mike
> 
> 
>> On Thu, 28 Feb 2019 at 15:06, Steve Meuse  wrote:
>> I can say that missing samples weren’t back filled when we billed. Never had 
>> any complaints.
>> 
>> -Steve
>> 
>>> On Wed, Feb 27, 2019 at 10:31 PM Daniel Rohan  wrote:
>>> Can anyone shed light on how ISPs handle missing samples when calculating 
>>> p95s for monthly billing cycles? Do they fill null samples with zeros or 
>>> leave them as null? 
>>> 
>>> I’m working on a billing sanity tool and want to make sure to cover my 
>>> corner cases well. 
>>> 
>>> Thanks!
>>> 
>>> Dan
>>> -- 
>>> Thanks, Dan

Re: Question about ISP billing procedures

[Roy]

  
  
On 2/27/2019 8:31 PM, Daniel Rohan
  wrote:


  
  Can anyone shed light on how ISPs handle missing
samples when calculating p95s for monthly billing cycles? Do
they fill null samples with zeros or leave them as null? 
  
  
  I’m working on a billing sanity tool and want to
make sure to cover my corner cases well. 
  
  
  Thanks!
  
  
  Dan
  -- 
  Thanks,
Dan


You have to be careful legally.  You can't bill something you
  cannot prove.  Unless you can extrapolate the data from the
  adjacent samples, you have to assume the best case for the user
  which is probably zero usage.
  

Re: Question about ISP billing procedures

[Michael Gehrmann]

>From my provider days if you miss data you can't bill it or assume zero.

Mike


On Thu, 28 Feb 2019 at 15:06, Steve Meuse  wrote:

> I can say that missing samples weren’t back filled when we billed. Never
> had any complaints.
>
> -Steve
>
> On Wed, Feb 27, 2019 at 10:31 PM Daniel Rohan  wrote:
>
>> Can anyone shed light on how ISPs handle missing samples when calculating
>> p95s for monthly billing cycles? Do they fill null samples with zeros or
>> leave them as null?
>>
>> I’m working on a billing sanity tool and want to make sure to cover my
>> corner cases well.
>>
>> Thanks!
>>
>> Dan
>> --
>> Thanks, Dan
>>
>

Re: Question about ISP billing procedures

[Steve Meuse]

I can say that missing samples weren’t back filled when we billed. Never
had any complaints.

-Steve

On Wed, Feb 27, 2019 at 10:31 PM Daniel Rohan  wrote:

> Can anyone shed light on how ISPs handle missing samples when calculating
> p95s for monthly billing cycles? Do they fill null samples with zeros or
> leave them as null?
>
> I’m working on a billing sanity tool and want to make sure to cover my
> corner cases well.
>
> Thanks!
>
> Dan
> --
> Thanks, Dan
>

Re: Question about ISP billing procedures

[Ross Tajvar]

Interesting question. How often are you missing data? I'd expect that to be
pretty robust.

On Wed, Feb 27, 2019, 10:33 PM Daniel Rohan  wrote:

> Can anyone shed light on how ISPs handle missing samples when calculating
> p95s for monthly billing cycles? Do they fill null samples with zeros or
> leave them as null?
>
> I’m working on a billing sanity tool and want to make sure to cover my
> corner cases well.
>
> Thanks!
>
> Dan
> --
> Thanks, Dan
>

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Seth Mattinen]

On 2/27/19 7:02 PM, b...@theworld.com wrote:

I have proposed many times to just move domain WHOIS data into a new
RRTYPE and let whoever owns the domain put in that whatever they want,
including (and perhaps most usefully for many) just a URL for further
detail.



We kind of have that with RP records. But does anyone do it?

Question about ISP billing procedures

[Daniel Rohan]

Can anyone shed light on how ISPs handle missing samples when calculating
p95s for monthly billing cycles? Do they fill null samples with zeros or
leave them as null?

I’m working on a billing sanity tool and want to make sure to cover my
corner cases well.

Thanks!

Dan
-- 
Thanks, Dan

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

> On 28 Feb 2019, at 1:13 pm, John R. Levine  wrote:
> 
> FYI:
> 
>> SMTP transitioned from A to MX.
> 
> No, it didn't.  A surprising number of real mail hosts only publish an A, and 
> I lost the battle to say that MX shouldn't fall back to .  It does.

You have missed the point.  No one publishes A’s (or ’s) because they think 
MX is not supported by other MTAs.

If one wanted to stop all fallback to A (and ) then there needed to be a 
RFC that said so and set a date for
fallback to no longer be performed.

>> SPF could have been the same except people were impatient and had 
>> unrealistic expectations of how long it would take.
> 
> Perhaps it's a generational thing.  I'm not very interested in transitions 
> that won't happen until after I'm dead.

It required libraries to be written and for MTAs to use those new libraries.  
That had started to happen.  We had name
servers at the end that were synthesising SPF records from TXT records.  One 
just had to wait for the OS refreshes to
occur which would got the new MTA’s deployed.  That would have mostly been done 
by now and I’m happy that you are not
dead.  Unfortunately I can’t prove that this would have been the course of 
events because it got aborted.

> R's,
> John

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

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[bzs]

I have proposed many times to just move domain WHOIS data into a new
RRTYPE and let whoever owns the domain put in that whatever they want,
including (and perhaps most usefully for many) just a URL for further
detail.

Obviously registries/registrars/ICANN can require and maintain more
specific and validatable information from domain owners.

I only mean the publicly accessible WHOIS info.

It was a reaction to the whole GDPR foofraw: Let each domain owner
control their own publicly visible data with some default (like we see
now) initialized by registrars on purchase via a new RRTYPE perhaps
call it WHOIS tho there are some which might be reused for this
purpose, TBD.

-- 
-Barry Shein

Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD   | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[John R. Levine]

FYI:


SMTP transitioned from A to MX.


No, it didn't.  A surprising number of real mail hosts only publish an A, 
and I lost the battle to say that MX shouldn't fall back to .  It 
does.


SPF could have been the same except people were impatient and had 
unrealistic expectations of how long it would take.


Perhaps it's a generational thing.  I'm not very interested in transitions 
that won't happen until after I'm dead.


R's,
John

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

> On 28 Feb 2019, at 9:03 am, John R. Levine  wrote:
> 
> On Thu, 28 Feb 2019, Mark Andrews wrote:
>> Agreed.  Additionally it suddenly went from something being done along
>> with a experiment to being “a experiment on can you transition to a new
>> type”.  The transition to type99 was well underway. ...
> 
> No, really, we had numbers.  Approximately nobody was using it, and of the 
> few that were, they were querying just one or just the other and getting 
> wrong results thereby.
> 
> In general I completely agree that new applications should have new rrtypes. 
> That's why I wrote my extension language, to help add new types to the 
> provisioning crudware that is the actual blocking factor on new types.  (The 
> actual servers are all updated pretty quickly.)  But trying to retrofit a new 
> type to an application that was already (albeit unwisely) using TXT was a 
> losing battle.

Actually it was a battle that could have easily been won.  People just gave up
way too soon.  Doing stuff like synthesising SPF records from spf style TXT
records in the primary server and setting a end date for transition would have
worked.  We didn’t do that because we didn’t think of it as a battle.  We were
also blindsided by the decision to treat the change as a experiment in how to
migrate types when it was never intended to be.  If one was after a fast 
transition
there was lots more that could have been done.

DLV transitioned types (we started out with a user assigned type).
DNS COOKIE transitioned EDNS code points (started out with a user assigned code
point).

It’s perfectly do able.

SMTP transitioned from A to MX.  We no longer publish A records just in case 
some
MTA doesn’t support MX anymore.  I can remember having to do that.  SPF could 
have
been the same except people were impatient and had unrealistic expectations of 
how
long it would take.

> Regards,
> John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for 
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

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

Re: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Töma Gavrichenkov]

On Thu, Feb 28, 2019, 1:14 AM Måns Nilsson 
wrote:

> Calling TXT or DANE non-standard is a remarkable statement.
>

Wow.

There's a whole lot of people who confuse "standard" with "typical". That's
fairly the flaw that brought us all sorts of ossification along the way.

And that's exactly fun seeing a Googler doing that mistake!

--
Töma

>

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[John R. Levine]

On Thu, 28 Feb 2019, Mark Andrews wrote:

Agreed.  Additionally it suddenly went from something being done along
with a experiment to being “a experiment on can you transition to a new
type”.  The transition to type99 was well underway. ...


No, really, we had numbers.  Approximately nobody was using it, and of 
the few that were, they were querying just one or just the other and 
getting wrong results thereby.


In general I completely agree that new applications should have new 
rrtypes. That's why I wrote my extension language, to help add new types 
to the provisioning crudware that is the actual blocking factor on new 
types.  (The actual servers are all updated pretty quickly.)  But trying 
to retrofit a new type to an application that was already (albeit 
unwisely) using TXT was a losing battle.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Mark Andrews]

> On 28 Feb 2019, at 7:28 am, Måns Nilsson  wrote:
> 
> Subject: Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS 
> Hijacking Date: Wed, Feb 27, 2019 at 01:07:09PM -0500 Quoting John Levine 
> (jo...@iecc.com):
>> In article <20190227161327.ga27...@besserwisser.org> you write:
>>> that is RFC 7208.[0]
>> 
>>> [0] This document tries to deprecate RRTYPE 99 for SPF. By stating that
>>> only TXT records can be trusted. ...
>> 
>> This must be a very different RFC 7208 from the one that the IETF published.
>> 
>> The IETF one says that nobody used type 99, and some of the few 
>> implementations
>> we saw were broken, so we deprecated it.
> 
> We will never agree on that.  Because I think you were, and are,
> wrong. Mostly out of eagerness and lack of patience.

Agreed.  Additionally it suddenly went from something being done along
with a experiment to being “a experiment on can you transition to a new
type”.  The transition to type99 was well underway.  The libraries that
supported it where being deployed.  New MTAs where using using them.
Type99 was being published. There was BS about not interoperating with
old libraries that only looked for TXT records.  The only response to that
should have been “doh, go update the code” and maybe set a date for stopping
falling back to TXT.

> I'm fairly certain you think I have no idea what I'm talking about. But,
> to rehash, a little less subtle:
> 
> My point was that the general state of criminal ignorance about the
> finer nuances of DNS is so wide spread that around 2038 we'll have an
> abstraction layer entirely built out of mile-long CNAME chains, because
> nobody remembers any other record type. CNAMEs we tried to forget too,
> replacing them with something out of the olde annals of Compuserve, but
> since the golden standard of resiliency and load balancing is a chain
> of them pointing into a bookstore's spare servers, we really can't do
> without them.
> 
> -- 
> Måns Nilsson primary/secondary/besserwisser/machina
> MN-1334-RIPE   SA0XLR+46 705 989668
> Don't worry, nobody really LISTENS to lectures in MOSCOW, either! ...
> FRENCH, HISTORY, ADVANCED CALCULUS, COMPUTER PROGRAMMING, BLACK
> STUDIES, SOCIOBIOLOGY! ...  Are there any QUESTIONS??

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

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Måns Nilsson]

Subject: Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS 
Hijacking Date: Wed, Feb 27, 2019 at 01:07:09PM -0500 Quoting John Levine 
(jo...@iecc.com):
> In article <20190227161327.ga27...@besserwisser.org> you write:
> >that is RFC 7208.[0]
> 
> >[0] This document tries to deprecate RRTYPE 99 for SPF. By stating that
> >only TXT records can be trusted. ...
> 
> This must be a very different RFC 7208 from the one that the IETF published.
> 
> The IETF one says that nobody used type 99, and some of the few 
> implementations
> we saw were broken, so we deprecated it.

We will never agree on that.  Because I think you were, and are,
wrong. Mostly out of eagerness and lack of patience.

I'm fairly certain you think I have no idea what I'm talking about. But,
to rehash, a little less subtle:

My point was that the general state of criminal ignorance about the
finer nuances of DNS is so wide spread that around 2038 we'll have an
abstraction layer entirely built out of mile-long CNAME chains, because
nobody remembers any other record type. CNAMEs we tried to forget too,
replacing them with something out of the olde annals of Compuserve, but
since the golden standard of resiliency and load balancing is a chain
of them pointing into a bookstore's spare servers, we really can't do
without them.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
Don't worry, nobody really LISTENS to lectures in MOSCOW, either! ...
FRENCH, HISTORY, ADVANCED CALCULUS, COMPUTER PROGRAMMING, BLACK
STUDIES, SOCIOBIOLOGY! ...  Are there any QUESTIONS??


signature.asc
Description: PGP signature

RE: [Non-DoD Source] Re: FYI - Major upgrade this weekend to Caution-www.arin.net and ARIN Online

[Stephenson, Ryan M CIV DISA IE (USA) via NANOG]

This looks amazing.  Can't wait!  Great job to ARIN!



-Original Message-
From: NANOG  On Behalf Of John Curran
Sent: Wednesday, February 27, 2019 12:03 PM
To: Mitcheltree, Harold B 
Cc: nanog list 
Subject: [Non-DoD Source] Re: FYI - Major upgrade this weekend to 
Caution-www.arin.net and ARIN Online 

All active links contained in this email were disabled. Please verify the 
identity of the sender, and confirm the authenticity of all links contained 
within the message prior to copying and pasting the address to a Web browser. 






Argh - my error on errant truncation.

Correct link is further down the email, but also here - 

   Caution-https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/ < 
Caution-https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/ > 

/John

John Curran
President and CEO
American Registry for Internet Numbers



On 27 Feb 2019, at 11:59 AM, Mitcheltree, Harold B 
mailto:p...@ots.utsystem.edu > > wrote:

Link fails - 

ARTICLE NOT FOUN




--Pete



From: NANOG mailto:nanog-boun...@nanog.org > > on behalf of John Curran 
mailto:jcur...@arin.net > >
Sent: Wednesday, February 27, 2019 10:56:27 AM
To: nanog list
Subject: FYI - Major upgrade this weekend toCaution-www.arin.net < 
Caution-http://www.arin.net >  and ARIN Online 
 
NANOGers - 

This weekend there will be a major upgrade to Caution-www.arin.net < 
Caution-http://www.arin.net/ >  website and the ARIN Online system.  

If you routinely use these systems, you might want to read what follows 
for an overview of the upcoming change – 
Caution-https://teamarin.net/…/02/27/getting-ready-for-the-big-rev…/ < 
Caution-https://teamarin.net/%E2%80%A6/02/27/getting-ready-for-the-big-rev%E2%80%A6/
 > 

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers



Begin forwarded message:

From: ARIN mailto:i...@arin.net > >

Subject: [arin-announce] How Community Input Shaped Our New 
ARIN.NET < Caution-http://arin.net/ > 

Date: 27 February 2019 at 11:50:22 AM EST

To: mailto:arin-annou...@arin.net > >


On 2 March, we will be deploying a new and improved 
Caution-www.arin.net < Caution-http://www.arin.net/ > . This
project is the product of collaboration with our community; 
user input
was a driving factor at every stage. We encourage you to read 
our new
blog post about the process and some of the changes you will 
see when we
go live:


Caution-https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/ < 
Caution-https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/ > 

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

___
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (arin-annou...@arin.net < 
Caution-mailto:arin-annou...@arin.net > ).
Unsubscribe or manage your mailing list subscription at:
Caution-https://lists.arin.net/mailman/listinfo/arin-announce < 
Caution-https://lists.arin.net/mailman/listinfo/arin-announce > 
Please contact i...@arin.net if you experience any issues.




smime.p7s
Description: S/MIME cryptographic signature

Re: a detour DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[John Levine]

In article <20190227161327.ga27...@besserwisser.org> you write:
>that is RFC 7208.[0]

>[0] This document tries to deprecate RRTYPE 99 for SPF. By stating that
>only TXT records can be trusted. ...

This must be a very different RFC 7208 from the one that the IETF published.

The IETF one says that nobody used type 99, and some of the few implementations
we saw were broken, so we deprecated it.

Re: FYI - Major upgrade this weekend to www.arin.net and ARIN Online

[Paul Ferguson]

This one works:

https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/

- ferg



> On Feb 27, 2019, at 8:59 AM, Mitcheltree, Harold B  
> wrote:
> 
> Link fails -
> ARTICLE NOT FOUN
> --Pete
> From: NANOG  on behalf of John Curran 
> 
> Sent: Wednesday, February 27, 2019 10:56:27 AM
> To: nanog list
> Subject: FYI - Major upgrade this weekend to www.arin.net and ARIN Online
> 
> NANOGers -
> 
> This weekend there will be a major upgrade to www.arin.net website and the 
> ARIN Online system.
> 
> If you routinely use these systems, you might want to read what follows for 
> an overview of the upcoming change –
> https://teamarin.net/…/02/27/getting-ready-for-the-big-rev…/
> 
> FYI,
> /John
> 
> John Curran
> President and CEO
> American Registry for Internet Numbers
> 
> 
>> Begin forwarded message:
>> 
>> From: ARIN 
>> Subject: [arin-announce] How Community Input Shaped Our New ARIN.NET
>> Date: 27 February 2019 at 11:50:22 AM EST
>> To: 
>> 
>> On 2 March, we will be deploying a new and improved www.arin.net. This
>> project is the product of collaboration with our community; user input
>> was a driving factor at every stage. We encourage you to read our new
>> blog post about the process and some of the changes you will see when we
>> go live:
>> 
>> https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/
>> 
>> Regards,
>> 
>> Communications and Member Services
>> American Registry for Internet Numbers (ARIN)
>> 
>> ___
>> ARIN-Announce
>> You are receiving this message because you are subscribed to
>> the ARIN Announce Mailing List (arin-annou...@arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-announce
>> Please contact i...@arin.net if you experience any issues.

—
Paul Ferguson
Principal, Threat Intelligence
Gigamon
Seattle, Washington, USA






signature.asc
Description: Message signed with OpenPGP

Re: FYI - Major upgrade this weekend to www.arin.net and ARIN Online

[John Curran]

Argh - my error on errant truncation.

Correct link is further down the email, but also here -

   https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/

/John

John Curran
President and CEO
American Registry for Internet Numbers


On 27 Feb 2019, at 11:59 AM, Mitcheltree, Harold B 
mailto:p...@ots.utsystem.edu>> wrote:

Link fails -
ARTICLE NOT FOUN

--Pete

From: NANOG mailto:nanog-boun...@nanog.org>> on behalf 
of John Curran mailto:jcur...@arin.net>>
Sent: Wednesday, February 27, 2019 10:56:27 AM
To: nanog list
Subject: FYI - Major upgrade this weekend to www.arin.net 
and ARIN Online

NANOGers -

This weekend there will be a major upgrade to 
www.arin.net website and the ARIN Online system.

If you routinely use these systems, you might want to read what follows for an 
overview of the upcoming change –
https://teamarin.net/…/02/27/getting-ready-for-the-big-rev…/

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] How Community Input Shaped Our New 
ARIN.NET
Date: 27 February 2019 at 11:50:22 AM EST
To: mailto:arin-annou...@arin.net>>

On 2 March, we will be deploying a new and improved 
www.arin.net. This
project is the product of collaboration with our community; user input
was a driving factor at every stage. We encourage you to read our new
blog post about the process and some of the changes you will see when we
go live:

https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

___
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List 
(arin-annou...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-announce
Please contact i...@arin.net if you experience any issues.

Re: FYI - Major upgrade this weekend to www.arin.net and ARIN Online

[Mitcheltree, Harold B]

Link fails -

ARTICLE NOT FOUN

--Pete


From: NANOG  on behalf of John Curran 

Sent: Wednesday, February 27, 2019 10:56:27 AM
To: nanog list
Subject: FYI - Major upgrade this weekend to www.arin.net and ARIN Online

NANOGers -

This weekend there will be a major upgrade to www.arin.net 
website and the ARIN Online system.

If you routinely use these systems, you might want to read what follows for an 
overview of the upcoming change –
https://teamarin.net/…/02/27/getting-ready-for-the-big-rev…/

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] How Community Input Shaped Our New 
ARIN.NET
Date: 27 February 2019 at 11:50:22 AM EST
To: mailto:arin-annou...@arin.net>>

On 2 March, we will be deploying a new and improved 
www.arin.net. This
project is the product of collaboration with our community; user input
was a driving factor at every stage. We encourage you to read our new
blog post about the process and some of the changes you will see when we
go live:

https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

___
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (arin-annou...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-announce
Please contact i...@arin.net if you experience any issues.

FYI - Major upgrade this weekend to www.arin.net and ARIN Online

[John Curran]

NANOGers -

This weekend there will be a major upgrade to www.arin.net 
website and the ARIN Online system.

If you routinely use these systems, you might want to read what follows for an 
overview of the upcoming change –
https://teamarin.net/…/02/27/getting-ready-for-the-big-rev…/

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers


Begin forwarded message:

From: ARIN mailto:i...@arin.net>>
Subject: [arin-announce] How Community Input Shaped Our New 
ARIN.NET
Date: 27 February 2019 at 11:50:22 AM EST
To: mailto:arin-annou...@arin.net>>

On 2 March, we will be deploying a new and improved 
www.arin.net. This
project is the product of collaboration with our community; user input
was a driving factor at every stage. We encourage you to read our new
blog post about the process and some of the changes you will see when we
go live:

https://teamarin.net/2019/02/27/getting-ready-for-the-big-reveal/

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)

___
ARIN-Announce
You are receiving this message because you are subscribed to
the ARIN Announce Mailing List (arin-annou...@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-announce
Please contact i...@arin.net if you experience any issues.

Re: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Måns Nilsson]

Subject: RE: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking Date: 
Wed, Feb 27, 2019 at 10:17:22AM -0500 Quoting Eric Tykwinski 
(eric-l...@truenet.com):
> > Nah, you know, that won't happen any time soon. Mozilla is busy doing 
> > other, more important things, like streaming all of the users' DNS queries 
> > to Cloudflare, etc. The plain old security doesn't count anymore.
> >
> > --
> > Töma
> 
> This was sort of discussed awhile ago:
> Adam Langley:
> https://www.imperialviolet.org/2015/01/17/notdane.html

Calling TXT or DANE non-standard is a remarkable statement. Smells of the
deeply flawed reasoning that brought us the festering pile of defaitism
that is RFC 7208.[0]

As I wrote a few messages upthread, the user can not expect the network
to be trustworthy, and still, we who run the network would very much
like their business. So, what we must constantly strive for is maximum
transparency, carrying as much of the Internet experienc, good or bad,
to the end user. Or, more terse: "Middleboxes are bad for you." 

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE   SA0XLR+46 705 989668
I demand IMPUNITY!

[0] This document tries to deprecate RRTYPE 99 for SPF. By stating that
only TXT records can be trusted. Apparently, it is possible to decide
on the fly which RRtypes are possible to query for, depending on the
argument.


signature.asc
Description: PGP signature

RE: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Eric Tykwinski]

> Nah, you know, that won't happen any time soon. Mozilla is busy doing other, 
> more important things, like streaming all of the users' DNS queries to 
> Cloudflare, etc. The plain old security doesn't count anymore.
>
> --
> Töma

This was sort of discussed awhile ago:
Adam Langley:
https://www.imperialviolet.org/2015/01/17/notdane.html

Dan York:
https://www.internetsociety.org/blog/2012/01/what-is-the-correct-user-experience-for-dnssec-in-a-web-browser/

I don't totally agree with it all, but at least it's been tested.

Re: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Töma Gavrichenkov]

On Wed, Feb 27, 2019, 11:45 PM Mike via NANOG  wrote:

> On 2/26/2019 11:10 AM, John Levine wrote:
> At one point, there was the DNSSEC/TLSA validator plug-in for browsers.
>
> I'd really like to see similar functionality return, not as a plug-in,
> but as a part of the base browser.
>

Nah, you know, that won't happen any time soon. Mozilla is busy doing
other, more important things, like streaming all of the users' DNS queries
to Cloudflare, etc. The plain old security doesn't count anymore.

--
Töma

>

Re: DANE, was A Deep Dive on the Recent Widespread DNS Hijacking

[Mike via NANOG]

On 2/26/2019 11:10 AM, John Levine wrote:
> In article  you write:
>> We need to get switched over to DANE as quickly as possible, and stop 
>> wasting effort trying to keep the CA system alive with
>> ever-hackier band-aids.
> 
> What's the DANE version of a green-bar cert?
> 
> 

At one point, there was the DNSSEC/TLSA validator plug-in for browsers.
I had used it and it worked quite well, displaying a green key for valid
DANE.

  https://www.dnssec-validator.cz/

Unfortunately, Firefox's API change, circa version 57, was the start of
browser changes that halted the project.

I'd really like to see similar functionality return, not as a plug-in,
but as a part of the base browser.


===

End of Support

Tue 16 October 2018

After struggling and failing to implement the DNSSEC/TLSA Validator
extension for Firefox Quantum (57+) we've decided to stop the
development and support of the extension.

Firefox 56 was the last version which provided necessary APIs that
enabled the DNSSEC/TLSA Validator to check DNS records and certificates  …

===