On Fri, Jun 15, 2018 at 01:12:31PM -0400, Andrew Sullivan wrote:
> I believe that RRsets are unordered sets by definition. So I supect
> that if people are relying on the order in which they come off the
> wire, they're making a mistake.
A data point here may be useful. PowerDNS has in many case
On Fri, Jun 15, 2018 at 8:12 PM, Shumon Huque wrote:
> On Fri, Jun 15, 2018 at 6:40 PM Mark Andrews wrote:
>
>> What we should be asking is why a service that needs multiple machines
>> isn’t using SRV. It has randomisation between servers explicitly defined
>> along with proportional load balan
Yeah, good point about side channels. Let's stick to recommending
randomization!
Shumon.
On Fri, Jun 15, 2018 at 8:01 PM Colm MacCárthaigh wrote:
>
> I think so too; and I wouldn't be so strict on backwards compatibility
> there.
>
> That behavior is a side-channel that defeats DNS privacy in s
On Fri, Jun 15, 2018 at 6:40 PM Mark Andrews wrote:
> What we should be asking is why a service that needs multiple machines
> isn’t using SRV. It has randomisation between servers explicitly defined
> along with proportional load balancing.
>
That would be nice, but sadly major applications lik
I think so too; and I wouldn't be so strict on backwards compatibility
there.
That behavior is a side-channel that defeats DNS privacy in some cases.
E.g. I can query a record, watch you send an encrypted query, then query
the record again, and tell what you queried. Within some probability at
lea
On Fri, Jun 15, 2018 at 5:55 PM Colm MacCárthaigh wrote:
>
> Just a question on this: was the old/classic behavior really
> random/shuffled? Or was it that bind would "rotate" through iterations
> where the order was the same each time if you think of the rrset list as a
> ring, but with a differ
What we should be asking is why a service that needs multiple machines isn’t
using SRV. It has randomisation between servers explicitly defined along with
proportional load balancing.
It also addresses CNAME at the apex which quite frankly is only used to find
the name of the HTTP server for t
Just a question on this: was the old/classic behavior really
random/shuffled? Or was it that bind would "rotate" through iterations
where the order was the same each time if you think of the rrset list as a
ring, but with a different start and end point within that ring? (That's
what's described he
Erik Nygren wrote:
...
This ambiguity in the current specifications results in this
mismatch between the pedantic (rrsets are explicitly unordered, and a
consistent order is a subset of that) and the current reality
(applications and services rely on resolvers-at-scale to be
explicitly incons
On Fri, Jun 15, 2018 at 04:17:00PM -0400, Erik Nygren wrote:
> Software should have safe defaults that matches common expectations.
> Those common expectations, as demonstrated by the configuration of all
> of the large public resolvers I've tested, as well as by how common
> software behaves,
I a
On Fri, Jun 15, 2018 at 3:52 PM, Mukund Sivaraman wrote:
> On Fri, Jun 15, 2018 at 02:38:00PM -0400, Bob Harold wrote:
> > Round-robin is a documented feature that many applications use. Removing
> > it from DNS resolvers, and then having to add it to a much larger number
> of
> > applications,
On Fri, Jun 15, 2018 at 02:38:00PM -0400, Bob Harold wrote:
> Round-robin is a documented feature that many applications use. Removing
> it from DNS resolvers, and then having to add it to a much larger number of
> applications, does not seem like a good trade-off.
The _default_ in BIND 9.12 was
> On Jun 15, 2018, at 2:01 PM, Peter van Dijk
> wrote:
>
> Hello Andrew,
>
> On 15 Jun 2018, at 19:12, Andrew Sullivan wrote:
>
>> I believe that RRsets are unordered sets by definition. So I supect
>> that if people are relying on the order in which they come off the
>> wire, they're makin
On Fri, Jun 15, 2018 at 2:28 PM Shumon Huque wrote:
> On Fri, Jun 15, 2018 at 1:13 PM Andrew Sullivan
> wrote:
>
>> On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote:
>> > A number of folks have been bitten by a bug in bind 9..12 where it
>> silently
>> > changes the default sorting of
On Fri, Jun 15, 2018 at 1:13 PM Andrew Sullivan
wrote:
> On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote:
> > A number of folks have been bitten by a bug in bind 9..12 where it
> silently
> > changes the default sorting of rrsets to always be sorted (even if the
> > authoritative resp
Hello Andrew,
On 15 Jun 2018, at 19:12, Andrew Sullivan wrote:
> I believe that RRsets are unordered sets by definition. So I supect
> that if people are relying on the order in which they come off the
> wire, they're making a mistake.
This. One hundred million times, this.
Kind regards,
--
P
Andrew Sullivan wrote:
On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote:
A number of folks have been bitten by a bug in bind 9..12 where it silently
changes the default sorting of rrsets to always be sorted (even if the
authoritative response wasn't sorted).
I believe that RRsets
On Fri, Jun 15, 2018 at 11:45:19AM -0400, Erik Nygren wrote:
> A number of folks have been bitten by a bug in bind 9..12 where it silently
> changes the default sorting of rrsets to always be sorted (even if the
> authoritative response wasn't sorted).
I believe that RRsets are unordered sets by d
Erik Nygren wrote:
> A number of folks have been bitten by a bug in bind 9.12 where it silently
> changes the default sorting of rrsets to always be sorted (even if the
> authoritative response wasn't sorted).
Huh, I noticed this and put the workaround in my config but I didn't
realise it counte
> On Jun 15, 2018, at 11:45 AM, Erik Nygren wrote:
>
> A number of folks have been bitten by a bug in bind 9..12 where it silently
> changes the default sorting of rrsets to always be sorted (even if the
> authoritative response wasn't sorted). This causes problems for services
> assuming a
A number of folks have been bitten by a bug in bind 9.12 where it silently
changes the default sorting of rrsets to always be sorted (even if the
authoritative response wasn't sorted). This causes problems for services
assuming at least some degree of round-robin behavior by clients as now
many cl
Reviewer: Joel Halpern
Review result: Ready with Issues
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For mor
22 matches
Mail list logo
