IP Blocked from Airbnb

[Ryan Hamel]

Hello Everyone,

 

If there is someone on this list from Airbnb who can get an IP address
removed from a block list, please contact me off list.

 

Thanks!

 

Ryan Hamel

Reminder OARC 40 - Call for Contribution

[John Todd]

Deadline Extension for OARC 40 abstract submission - January 5, 23:59 
UTC 

 
Please note that, we are looking for contributions and remote 
participation is actively supported

 


Subject: OARC 40 - Call for Contribution

OARC 40 will be a two-day hybrid meeting held on 16 & 17 February in 
Atlanta (GA), USA at 10:00 AM  (Local time - EST (UTC-05:00)). The 
onsite part of the meeting will be colocated with NANOG 87. 


The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are 
welcome. For inspiration, we provide a non-exhaustive list of ideas:
  • Operations: Any operational gotchas, lessons learned from an 
outage, details/reasons for a recent outage (how to improve TTR, 
tooling).

  • Deployment: DNS config management and release process.
  • Monitoring: Log ingestion pipeline, analytics infrastructure, 
anomaly detection.
  • Scaling: DNS performance management and metrics. Increasing DNS 
Server Efficiency
  • Security/Privacy: DNSSEC signing and validation, key storage, 
rollovers, qname minimization, DoH/DoT


The presentations can be either a full-length presentation - 20 mins (+5 
mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A) 


Workshop Milestones:

2022-10-22 Submissions open via Indico
2022-01-05 Extended Deadline for submission (23:59 UTC)
2023-01-10 Preliminary list of contributions published
2023-01-17 Full agenda published
2023-01-30 Deadline for slideset submission and Rehearsal
2023-02-16 OARC 40 Workshop - Day1
2023-02-17 OARC 40 Workshop - Day2

The Registration page and details for presentation submission are 
published at:



To allow the Programme Committee to make objective assessments of 
submissions, so as to ensure the quality of the workshop, submissions 
SHOULD include slides. Draft slides are acceptable on 
submission. Guidelines for presentation 
slides: https://www.grammarly.com/blog/presentation-tips/ 


Additional information for speakers of OARC 40
  • your talk will be broadcast live and recorded for future 
reference
  • your presentation slides will be available for delegates and 
others to download and refer to, before, during and after the meeting
  • Remote speakers have mandatory rehearsal on 2023-01-31 at 14:00 
UTC. It would be very useful to have your slides (even if draft) ready 
for this.


Note: DNS-OARC provides registration fee waivers for the workshop to 
support those who are part of underrepresented groups to speak at and/or 
attend DNS-OARC. More details will be provided when registration opens.


If you have questions or concerns you can contact the Programme 
Committee:

https://www.dns-oarc.net/oarc/programme
via submissi...@dns-oarc.net

John Todd, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social 
events. Please contact spon...@dns-oarc.net if your organization is 
interested in becoming a sponsor.


(Please note that OARC is run on a non-profit basis, and is not in a 
position to reimburse expenses or time for speakers at its meetings.)




--
John Todd - jt...@quad9.net
General Manager - Quad9 Recursive Resolver

Re: Large RTT or Why doesn't my ping traffic get discarded?

[Jason Iannone]

Thanks for engaging with this. I was intentionally brief in my explanation.
I have observed this behavior in congested networks for years and ignored
it as an obvious symptom of the congestion. What has always piqued my
curiosity though is just how long a ping can last.

In my case yesterday, I was at the airport at peak holiday travel and free
wifi usage time. I expect a bad experience. I don't expect a ping to return
5 seconds after originating it. I just imagine the network straining and
groaning to get my ping back to me. It's okay, man. Let it go.

On Thu, Dec 22, 2022 at 5:22 AM Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:

> Jerry Cloe wrote:
>
> > Because there is no standard for discarding "old" traffic, only
> > discard is for packets that hop too many times. There is, however, a
> > standard for decrementing TTL by 1 if a packet sits on a device for
> > more than 1000ms, and of course we all know what happens when TTL
>  > hits zero. Based on that, your packet could have floated around for
>  > another 53 seconds.
>
> Totally wrong as the standard says TTL MUST be decremented at least
> by one on every hop and TTL MAY NOT be decremented further as is
> specified by the standard of IPv4 router requirements (rfc1812):
>
> When a router forwards a packet, it MUST reduce the TTL by at least
> one.  If it holds a packet for more than one second, it MAY decrement
> the TTL by one for each second.
>
> As for IPv6,
>
> Unlike IPv4, IPv6 nodes are not required to enforce maximum packet
> lifetime.  That is the reason the IPv4 "Time to Live" field was
> renamed "Hop Limit" in IPv6.  In practice, very few, if any, IPv4
> implementations conform to the requirement that they limit packet
> lifetime, so this is not a change in practice.
>
> Masataka Ohta
>
>

Re: Large RTT or Why doesn't my ping traffic get discarded?

[Masataka Ohta]

Jerry Cloe wrote:


Because there is no standard for discarding "old" traffic, only
discard is for packets that hop too many times. There is, however, a
standard for decrementing TTL by 1 if a packet sits on a device for
more than 1000ms, and of course we all know what happens when TTL

> hits zero. Based on that, your packet could have floated around for
> another 53 seconds.

Totally wrong as the standard says TTL MUST be decremented at least
by one on every hop and TTL MAY NOT be decremented further as is
specified by the standard of IPv4 router requirements (rfc1812):

   When a router forwards a packet, it MUST reduce the TTL by at least
   one.  If it holds a packet for more than one second, it MAY decrement
   the TTL by one for each second.

As for IPv6,

   Unlike IPv4, IPv6 nodes are not required to enforce maximum packet
   lifetime.  That is the reason the IPv4 "Time to Live" field was
   renamed "Hop Limit" in IPv6.  In practice, very few, if any, IPv4
   implementations conform to the requirement that they limit packet
   lifetime, so this is not a change in practice.

Masataka Ohta