> On 20 Jun 2018, at 12:06 pm, Paul Ebersman wrote:
>
> bellis> AIUI, a large part of the supposed issue with SRV was the
> bellis> inertia of the installed base of browsers that wouldn't know how
> bellis> to access them.
>
> drc> I thought the more fundamental problem was the additional
bellis> AIUI, a large part of the supposed issue with SRV was the
bellis> inertia of the installed base of browsers that wouldn't know how
bellis> to access them.
drc> I thought the more fundamental problem was the additional latency
drc> caused by the second lookup since SRV specified domain
> On 20 Jun 2018, at 8:56 am, Paul Vixie wrote:
>
> Neither. There were additional data rules to mostly prevent a second lookup,
> and even in those days, browsers cached hostname to address mappings.
>
> Browsers didn't adopt because srv didn't solve geo or topology optimization.
> For a
On Tue, Jun 19, 2018 at 2:56 PM Wessels, Duane
wrote:
> >
> > * If the goal is to support secure acquisition of the zone outside the
> DNS protocol, then it can't do that. But neither is ZONEMD needed for that
> - we can use an out of band signature using a variety of methods.
>
> Yes, this is
> On 20 Jun 2018, at 9:15 am, Mukund Sivaraman wrote:
>
> On Tue, Jun 19, 2018 at 02:11:02PM -0400, Shumon Huque wrote:
>> On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček wrote:
>>
>>>
>>> I think we need to first answer question why existing technologies do
>>> not fit the purpose.
>>>
>>
>>
On Tue, Jun 19, 2018 at 04:31:55PM +0200, Petr Špaček wrote:
> I wonder if this proposal is worth the complexity ... If we wanted plain
> checksum we could use TSIG with built-in key (all zeroes or so) and to get
> checksum for the network part with negligible implementation complexity.
> (TSIG
On Tue, Jun 19, 2018 at 02:11:02PM -0400, Shumon Huque wrote:
> On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček wrote:
>
> >
> > I think we need to first answer question why existing technologies do
> > not fit the purpose.
> >
>
> This is a reasonable question.
>
> I noticed that the draft
> On 20 Jun 2018, at 8:44 am, David Conrad wrote:
>
> On Jun 19, 2018, at 2:03 PM, Ray Bellis wrote:
>> AIUI, a large part of the supposed issue with SRV was the inertia of the
>> installed base of browsers that wouldn't know how to access them.
>
> I thought the more fundamental problem was
Neither. There were additional data rules to mostly prevent a second lookup,
and even in those days, browsers cached hostname to address mappings.
Browsers didn't adopt because srv didn't solve geo or topology optimization.
For a design change of this size, more payback was needed.
--
Paul
On Jun 19, 2018, at 2:03 PM, Ray Bellis wrote:
> AIUI, a large part of the supposed issue with SRV was the inertia of the
> installed base of browsers that wouldn't know how to access them.
I thought the more fundamental problem was the additional latency caused by the
second lookup since SRV
SIG(0) has miles of potential. Active Directory shows that hosts updating
their own addresses is useful.
SIG(0) provides a similar mechanism without the overhead of AD. It actually
works well today if you spend the time to hook it into a system. What’s needed
is for OS vendors to ship
SIG(0) was implemented in BIND 9 back when BIND 9 was basically the only modern
implementation, and no one used it then. The fact that no servers have
implemented it since then means that there really isn’t any demand.
Brian
> On Jun 19, 2018, at 2:20 PM, Mark Andrews wrote:
>
> SIG(0) is
But if nobody uses that and nobody else implements this, it sort of beats the
usefulness of the feature.
Ondrej
--
Ondřej Surý — ISC
> On 19 Jun 2018, at 23:20, Mark Andrews wrote:
>
> SIG(0) is much superior for machines updating their own data to TSIG as you
> don’t need a secondary
On Tue, Jun 19, 2018 at 2:51 PM 神明達哉 wrote:
> At Mon, 18 Jun 2018 17:51:26 -0400,
> Shumon Huque wrote:
>
> > Client applications delegate address sorting to name resolution functions
> > like getaddrinfo() - correct?
> >
> > Doing some quick tests of getaddrinfo() just now on a recent *NIX
>
SIG(0) is much superior for machines updating their own data to TSIG as you
don’t need a secondary storage for the TSIG key. You can replace a master
server without having to worry about transferring TSIG secrets off a dead
machine. You just copy the zone from a slave and go.
There are
But is it really used like this? Or will it ever?
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 19 Jun 2018, at 23:04, Tony Finch wrote:
>
> Ondřej Surý wrote:
>>
>> Do people think the SIG(0) is something that we should keep in DNS and
>> it will be used in the future or it is a good candidate
Ray Bellis wrote:
> On 19/06/2018 17:44, Tony Finch wrote:
>
> > SRV should have been part of the fix (and it was invented early
> > enough to be!) but it wasn't a complete fix without support from the
> > application protocols.
>
> AIUI, a large part of the supposed issue with SRV was the
Oh, what about this?
https://tools.ietf.org/html/draft-sury-dnsext-cname-dname-00
:-)
O.
--
Ondřej Surý
ond...@isc.org
> On 19 Jun 2018, at 15:18, Petr Špaček wrote:
>
> Hello dnsop,
>
> beware, material in this e-mail might cause your head to explode :-)
>
> This proposal is based on
On Tue, Jun 19, 2018 at 2:56 PM Wessels, Duane
wrote:
>
> > On Jun 19, 2018, at 11:11 AM, Shumon Huque wrote:
> >
> >
> > On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček wrote:
> >
> > I think we need to first answer question why existing technologies do
> > not fit the purpose.
> >
> > This is a
> On 19 Jun 2018, at 15:02, John Levine wrote:
>
> In article
> you
> write:
>> This sounds like a lot of work and likely to cause camel indigestion.
>
> Agreed but it doesn't seem all that much less work than a well
> specified version of ANAME, and it avoids the ANAME ugliness of making
In article
you write:
>This sounds like a lot of work and likely to cause camel indigestion.
Agreed but it doesn't seem all that much less work than a well
specified version of ANAME, and it avoids the ANAME ugliness of making
authoritative servers do recursive lookups.
> On Jun 19, 2018, at 11:11 AM, Shumon Huque wrote:
>
>
> On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček wrote:
>
> I think we need to first answer question why existing technologies do
> not fit the purpose.
>
> This is a reasonable question.
>
> I noticed that the draft doesn't mention
At Mon, 18 Jun 2018 17:51:26 -0400,
Shumon Huque wrote:
> Client applications delegate address sorting to name resolution functions
> like getaddrinfo() - correct?
>
> Doing some quick tests of getaddrinfo() just now on a recent *NIX machine,
> it appears to return addresses sorted roughly in
On Tue, Jun 19, 2018 at 10:32 AM Petr Špaček wrote:
>
> I think we need to first answer question why existing technologies do
> not fit the purpose.
>
This is a reasonable question.
I noticed that the draft doesn't mention SIG(0) at all. One of the main
motivators of the draft is stated to be
... going wildly off-topic now ...
Jared Mauch wrote:
>
> Throw some shade at SMTP as well, if I send mail to
> ja...@cname.nether.net and that pointed to @nether.net it would end up
> as @nether.net in the messages :-)
Not always - Exim doesn't do that rewrite, for example. CNAME-driven
On Tue, Jun 19, 2018 at 4:47 PM, Lanlan Pan wrote:
>
>
> Petr Špaček 于2018年6月19日周二 下午9:19写道：
>
>> Hello dnsop,
>>
>> beware, material in this e-mail might cause your head to explode :-)
>>
>> This proposal is based on following observations:
>> - It seems that DNS protocol police lost battle
On Tue, Jun 19, 2018 at 11:24 AM, Ray Bellis wrote:
> On 19/06/2018 15:43, tjw ietf wrote:
>
> > I find it personally appalling we can spend so many cycles injecting
> > dns into http but we can’t be bothered to fix what end users want.
>
> It's the HTTP folks that are putting most of those
> On Jun 19, 2018, at 11:24 AM, Ray Bellis wrote:
>
> On 19/06/2018 15:43, tjw ietf wrote:
>
>> I find it personally appalling we can spend so many cycles injecting
>> dns into http but we can’t be bothered to fix what end users want.
>
> It's the HTTP folks that are putting most of those
On 19/06/2018 15:43, tjw ietf wrote:
> I find it personally appalling we can spend so many cycles injecting
> dns into http but we can’t be bothered to fix what end users want.
It's the HTTP folks that are putting most of those cycles into DNS into
HTTP.
It's also their intransigence re: SRV
On Jun 19, 2018, at 10:20, Tony Finch wrote:
> Petr Špaček wrote:
>>
>> Given that resolver side somehow works already ...
>> could we standardize this obvious violation of RFC 1035?
>
> The feature I would like is CNAME and other data (typically CNAME + MX +
> TXT), because I have a lot of
Petr Špaček 于2018年6月19日周二 下午9:19写道：
> Hello dnsop,
>
> beware, material in this e-mail might cause your head to explode :-)
>
> This proposal is based on following observations:
> - It seems that DNS protocol police lost battle about CNAME at apex,
>is is deployed on the Internet.
> - Major
With all of you here.
As an Operator who gets these requests regularly (just 10 minutes ago!) when
you tell users the world of BIND/PowerDNS/NSD/Knot do not support such a
mechanism they say “we’re off to use route 53. okthxbai “
I find it personally appalling we can spend so many cycles
Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
Wessels, Duane:
On May 25, 2018, at 11:33 AM, 神明達哉 wrote:
At Wed, 23 May 2018 15:32:11 +,
"Weinberg, Matt" wrote:
We’ve posted a new version of draft-wessels-dns-zone-digest. Of note,
this -01 version includes the following changes:
[...]
Petr Špaček wrote:
>
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?
The feature I would like is CNAME and other data (typically CNAME + MX +
TXT), because I have a lot of deeply hierarchial subdomains in my main
zone. CNAME at apex
Hello dnsop,
beware, material in this e-mail might cause your head to explode :-)
This proposal is based on following observations:
- It seems that DNS protocol police lost battle about CNAME at apex,
is is deployed on the Internet.
- Major DNS resolvers like BIND, Unbound, PowerDNS Recursor,
Florian Weimer wrote:
* Paul Vixie:
in other words we should re-order rrsets by default, so that very few
people or agents are ever prone to think their order is stable. the spec
says they are unordered, but human nature says, expect more of what
you're seeing.
But the client has to sort
On Tuesday, June 19, 2018 01:21 CEST, Shumon Huque wrote:
> On Mon, Jun 18, 2018 at 7:05 PM Darcy Kevin (FCA)
> wrote:
>
> > RFC 6724 specifically says: "Rules 9 and 10 MAY be superseded if the
> > implementation has other
> > means of sorting destination addresses. For example, if the
> >
37 matches
Mail list logo
