On Mon, Jul 01, 2024 at 11:49:10AM +0800, Davey Song wrote:
>People add tricks to DNS when DNS does not fit their needs. However, my
>customers complained about the difficulties of deploying their DNS on
>multiple platforms with different DNS tricks (GeoDNS for example) or
>switchin
On Jun 28, 2024, at 12:47, Ben Schwartz
wrote:
>
> Hi DNSOP,
>
> The practice of DNS Load Balancing -- sending different answers to different
> resolvers to optimize latency and avoid overload —
A request - can you call this “Traffic Engineering via DNS” (or “DNS Traffic
Engineering”)?
Whe
Paul Vixie writes:
> somebody asked me a few months ago why "it's always dns"? meaning,
> why are so many mysteries and outages ultimately traced down to
> something broken in dns?
Personally, even despite having the relevant haiku as my desktop
background, I push back on this when it rears its h
On Monday, July 1, 2024 2:54:55 AM PDT Davey Song wrote:
> Hi Paul,
>
> I’m sending this email off-list to respond to your comment.
in fact you cc'd the mailing list, so i shall do likewise in my reply.
> ... However, the fact is that DNS has been widely used
> as a direction system for a long t
Hi Paul,
I’m sending this email off-list to respond to your comment.
davey, "another indirection" means both more round trips and more
> complexity,
> and will find few friends.
>
I do hope the DNS caters to the requirements without another indirection. I
said "another indirection" because peopl
On 1 Jul 2024, at 07:19, Paul Vixie wrote:
> joe, let's figure out how to "rigidly constrain" again. expressing fixed
> policy
> which can operate inside the recursive system would be a whole lot easier to
> diagnose whenever it's unreliable, but avoid the additional round trips that
> the CDN w
somebody asked me a few months ago why "it's always dns"? meaning, why are so
many mysteries and outages ultimately traced down to something broken in dns?
i answered that dns as conceived worked very well, and the first round of
changes (ixfr, update, notify, edns) helped it work well even at s
People add tricks to DNS when DNS does not fit their needs. However, my
customers complained about the difficulties of deploying their DNS on
multiple platforms with different DNS tricks (GeoDNS for example) or
switching from one another.
I agree with Joe. DNS is a layer of indirection. If one ind
Hi Ben,
Good to hear from you about the side meeting on DNS load balance. We
recently came up with a draft on the security and robustness of the NS
selection algorithm and will submit it soon with the final editing.
Is this side meeting accessible on line? Looking forward to hearing from
your gu
I hold that ietf docs are pretty good at normating behaviour seen to be
used. Post fact "this is how it is" seems to work.
They're pretty terrible most of the time at ending behaviour not seen to be
directly harmful to making money.
They're functionally useless at wish fulfilment.
CDN operators
Bill Woodcock wrote on 2024-06-29 20:22:
On Jun 29, 2024, at 19:59, Paul Vixie ... wrote:
It's my hope that CDN support can be added to DNS in a way that allows all
answers to be identical. ... we have to move away from CNAME especially at the
apex. The great bogie man of CDN seems to be add
> On Jun 29, 2024, at 19:59, Paul Vixie
> wrote:
> It's my hope that CDN support can be added to DNS in a way that allows all
> answers to be identical. Modern clients even mobile ones are powerful enough
> to make application layer routing decisions locally. But we have to move away
> from CN
On 29 Jun 2024, at 20:13, Ray Bellis wrote:
> Can you please ensure that there's time on the agenda for discussion on why
> it remains a bad idea to use the internet's name to resource mapping scheme
> to perform what should be achieved in the routing layer?
This seems like a bit of an inflamm
It's my hope that CDN support can be added to DNS in a way that allows all
answers to be identical. Modern clients even mobile ones are powerful enough to
make application layer routing decisions locally. But we have to move away from
CNAME especially at the apex. The great bogie man of CDN seem
> On 29 Jun 2024, at 18:10, Ray Bellis wrote:
>
> The DNS was never designed intended to deliver different answers to different
> users. DNSSEC solidified that and the practise IMNSHO should be discouraged,
> not standardised.
While this is undoubtedly true Ray, that ship sailed a *long* ti
On 28/06/2024 17:47, Ben Schwartz wrote:
Hi DNSOP,
The practice of DNS Load Balancing -- sending different answers to
different resolvers to optimize latency and avoid overload -- has been
around for at least 25 years, and remains as popular as ever. It's
never really been supported in the
Side Meeting - DNS Load Balancing
Clarification: while you may use your Datatracker login email to make an
account on the IETF Slack, this Slack instance is not connected to the
Datatracker. You can use any of the offered login flows to connect. --Ben From:
Ben Schwartz Sent:
ZjQcmQRYFpfptBanner
Clarification: while you may use your Datatracker login email to make an
account on the IETF Slack, this Slack instance is not connected to the
Datatracker. You can use any of the offered login flows to connect.
--Ben
From: Ben Schwartz
Sent: Friday, June 28, 20
18 matches
Mail list logo
