A Google Cloud support engineer solves a tough DNS case
cloud.google.com
A Google Cloud support engineer solves a tough DNS case
1–10 of 283 posts
Re: A Google Cloud support engineer solves a tough DNS case
#2> they use raw sockets! Raw sockets are different than normal sockets: they bypass iptables, and they are not buffered!
Can someone elaborate on the above statement from the article? Does this imply that raw sockets have unbounded buffer?
Re: A Google Cloud support engineer solves a tough DNS case
#3> they use raw sockets! Raw sockets are different than normal sockets: they bypass iptables, and they are not buffered! Can someone elaborate on the above statement from the article? Does this imply that raw sockets have unbounded buffer?
Clearly not, but raw is raw. For the purposes of this article, it's enough to say that raw sockets, being raw, don't traverse the flawed block of code, which is in net/ipv4/udp.c
Re: A Google Cloud support engineer solves a tough DNS case
#4that’s a pretty good and detailed explanation. 2 things: 1) i hope they have a runbook for situations like this (ie the support engineer does not have to figure all this on the fly) 2) the customer should have provides more details and maybe should have thought of the tweaks they made (classic solution is to compare 2 instances - one works one does not)
Re: A Google Cloud support engineer solves a tough DNS case
#5> they use raw sockets! Raw sockets are different than normal sockets: they bypass iptables, and they are not buffered! Can someone elaborate on the above statement from the article? Does this imply that raw sockets have unbounded buffer?
Probably the opposite, they send without waiting for any bytes to build up.
Re: A Google Cloud support engineer solves a tough DNS case
#6" I find that 2147481343 seems to do the trick. This number doesn't make any sense to me. I suggest the customer try this number. The customer replies back: it works with google.com, but it does not work with other domains."
My extrapolation: I find a potential fix: don't test it, don't understand it, and send it to customer.
How is this acceptable?
Re: A Google Cloud support engineer solves a tough DNS case
#7The LKML message described in the post is here: https://lkml.org/lkml/2019/12/19/482
Re: A Google Cloud support engineer solves a tough DNS case
#8" I find that 2147481343 seems to do the trick. This number doesn't make any sense to me. I suggest the customer try this number. The customer replies back: it works with google.com, but it does not work with other domains." My extrapolation: I find a potential fix: don't test it, don't understand it, and send it to customer. How is this acceptable?
Did you read the next sentence? "I continue my investigation."
Re: A Google Cloud support engineer solves a tough DNS case
#9" I find that 2147481343 seems to do the trick. This number doesn't make any sense to me. I suggest the customer try this number. The customer replies back: it works with google.com, but it does not work with other domains." My extrapolation: I find a potential fix: don't test it, don't understand it, and send it to customer. How is this acceptable?
Technically-inclined customers generally appreciate being actively involved in the debugging process, rather than the alternative of being stonewalled until a solution everyone's 100% confident in can be found.
Re: A Google Cloud support engineer solves a tough DNS case
#10> After another spin around the world the case comes back to our team.
So basically, follow the sun doesn't work for hard problems? Can you really say the people are working on this 24/7 if progress is only made in one time zone?