On Wed, Sep 19, 2018 at 09:48:18AM +0200, Petr Špaček wrote:
>
>
> On 19/09/2018 09:31, Mukund Sivaraman wrote:
> > On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote:
> >> On 18/09/2018 22:02, JW wrote:
> >>>
> >>> Original message
> >>> From: Mark Andrews
> >>>
>
On 19/09/2018 09:31, Mukund Sivaraman wrote:
> On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote:
>> On 18/09/2018 22:02, JW wrote:
>>>
>>> Original message
>>> From: Mark Andrews
>>>
I would also expect a relatively large client population using SRV records
> On 19 Sep 2018, at 5:26 pm, Stephane Bortzmeyer wrote:
>
> On Wed, Sep 19, 2018 at 07:24:25AM +1000,
> Mark Andrews wrote
> a message of 38 lines which said:
>
>> As for scripts, you upgrade the tools those scripts use:
>> curl(libcurl), wget, fetch for SH. File::Fetch for perl. Similar
On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote:
> On 18/09/2018 22:02, JW wrote:
> >
> > Original message
> > From: Mark Andrews
> >
> >> I would also expect a relatively large client population using SRV records
> >> given the rate Firefox and Chrome browsers are
On Wed, Sep 19, 2018 at 07:24:25AM +1000,
Mark Andrews wrote
a message of 38 lines which said:
> As for scripts, you upgrade the tools those scripts use:
> curl(libcurl), wget, fetch for SH. File::Fetch for perl. Similar
> for the other scripting languages. Very few applications actually
>
On 18/09/2018 22:02, JW wrote:
>
> Original message
> From: Mark Andrews
>
>> I would also expect a relatively large client population using SRV records
>> given the rate Firefox and Chrome browsers are upgraded. SRV lookups
>> work for lots ofother protocols. SRV records
> On 19 Sep 2018, at 6:02 am, JW wrote:
>
>
> Original message
> From: Mark Andrews
>
> > I would also expect a relatively large client population using SRV records
> > given the rate Firefox and Chrome browsers are upgraded. SRV lookups
> > work for lots ofother
Original message From: Mark Andrews
> I would also expect a relatively large client population using SRV records>
> given the rate Firefox and Chrome browsers are upgraded. SRV lookups> work
> for lots ofother protocols. SRV records also make it through> firewalls and
> IDS
> On 17 Sep 2018, at 5:43 pm, Mukund Sivaraman wrote:
>
> Hi Stephane
>
> On Mon, Sep 17, 2018 at 09:14:14AM +0200, Stephane Bortzmeyer wrote:
>> On Sun, Sep 16, 2018 at 03:26:56PM +0530,
>> Mukund Sivaraman wrote
>> a message of 66 lines which said:
>>
>>> Adding resolver support (to
Hi Evan
On Mon, Sep 17, 2018 at 04:11:24PM +, Evan Hunt wrote:
> On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote:
> > Similar things can be said of other proposals.
> >
> > * If SRV for HTTP is brought into use, what about X% of user agents that
> > don't have support for
On Mon, Sep 17, 2018 at 01:13:27PM +0530, Mukund Sivaraman wrote:
> Similar things can be said of other proposals.
>
> * If SRV for HTTP is brought into use, what about X% of user agents that
> don't have support for it?
>
> * If a new RR type is introduced, what about X% of resolvers that do
Hi Petr
On Mon, Sep 17, 2018 at 12:29:13PM +0200, Petr Špaček wrote:
> Originally I thought that current workarounds for CNAME at apex (which
> are almost everywhere) deal with it in a more deterministic way.
Do you mean the current workarounds in resolver implementations? These
can be brought
On 17/09/2018 11:30, Mukund Sivaraman wrote:
> Hi Ray
>
> On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote:
>> On 17/09/2018 08:43, Mukund Sivaraman wrote:
>>
>>> The suggestion is only to require support in resolvers going forward for
>>> CNAME co-existing with other types for now.
Hi Ray
On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote:
> On 17/09/2018 08:43, Mukund Sivaraman wrote:
>
> > The suggestion is only to require support in resolvers going forward for
> > CNAME co-existing with other types for now. That should not break any
> > detail of how DNS is used
On 17/09/2018 08:43, Mukund Sivaraman wrote:
> The suggestion is only to require support in resolvers going forward for
> CNAME co-existing with other types for now. That should not break any
> detail of how DNS is used today.
> Although it changes current DNS protocol, AFAICT there does
Hi Stephane
On Mon, Sep 17, 2018 at 09:14:14AM +0200, Stephane Bortzmeyer wrote:
> On Sun, Sep 16, 2018 at 03:26:56PM +0530,
> Mukund Sivaraman wrote
> a message of 66 lines which said:
>
> > Adding resolver support (to resolvers that don't have it, i.e.,
> > vs. RFC 1035) does not appear to
On 17/09/2018 08:11, Stephane Bortzmeyer wrote:
Since the main use case is "people with a domain name such as
example.com, who wants https://example.com/ to actually work, and who
hosts the stuff at a CDN where the IP address is wildly variable so
they cannot use A or records", I
On Sun, Sep 16, 2018 at 03:26:56PM +0530,
Mukund Sivaraman wrote
a message of 66 lines which said:
> Adding resolver support (to resolvers that don't have it, i.e.,
> vs. RFC 1035) does not appear to break current DNS, i.e., it can be
> proposed now.
[Algorithm deleted]
The difficult thing
On Mon, Sep 17, 2018 at 03:51:34AM +,
Evan Hunt wrote
a message of 124 lines which said:
> I don't see how we can responsibly declare a new standard which, if
> followed, will break every prior implementation. Apex CNAME is the
> sort of solution that's clear, simple, and wrong.
+1
>
It seems to me problematic to start with the statement that apex CNAME is
"deployed on the internet". Obviously it does occur, but it breaks things
when it does. Depending on various factors such as the order in which
responses are cached, the breakage is sometimes survivable, but you can't
put a
Mukund,
Thank you for reviving this conversation. I was just asked last week about the
status of this whole debate by someone who was seeking to set up “CNAME at
apex”-style records for a variety of domains, all of which would be pointed
over to links within various CDNs.
His challenge is
this proposal appears to make more sense. if cname cannot be used until
everybody has upgraded, then some other ?name RR could be used instead,
on a similar time line, and would have no impact on those who never
upgraded.
___
DNSOP mailing list
Hi Petr
Apologies for the delayed reply.
On Tue, Jun 19, 2018 at 03:18:22PM +0200, Petr Špaček wrote:
> 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
Anthony Eden 于2018年6月20日周三 上午12:06写道：
> 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:
>>>
On Fri, Jul 06, 2018 at 08:22:41AM +0200, Matthijs Mekking wrote:
> Me too :)
>
> https://github.com/each/draft-aname/pulls
Yes, sorry, my bad. I'll try to address the pull requests next week.
Should've done ages ago.
--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
John Levine wrote:
>
> You're probably right, but I think that ANAME would need as many
> upgrades, just in slightly different places.
ANAME should work without upgrades, because A and queries will get
the answers they expect. ANAME support is just a performance optimization
when the ANAME
In article <5b3e8242.1010...@redbarn.org> you write:
>i think you will find that there is no dnssec-compatible way to solve
>this problem without upgrades to both authority AND recursive AND stub
>dns agents, AND to the getnameinfo-or-similar API. if i'm right, it'll
>be necessary to make hard
On 07/05/2018 06:15 PM, Tony Finch wrote:
Tim Wicinski wrote:
The chairs have decided to set aside some time in Montreal and see if we
can work through this problem. We've asked Ondřej from ISC and Willem
from NLnetLabs to help guide the talk.
I was hoping that there would be another
Tim Wicinski wrote:
...
What we do know is:
- We're not going to do SRV records (sorry Mark).
- We're not going to ask the IAB to give a waiver on DNSSEC.
- We still bang into each other over this.
i think you will find that there is no dnssec-compatible way to solve
this problem
Paul Vixie wrote:
> Tony Finch wrote:
>
> Paul Wouters wrote:
>
> I understand, I just disagree this is the right way. I don't see why
> this entire problem shouldn't be resolved at the well, resolver level.
>
> I don't see how that can be deployed in a way that is compatible with
> existing
Tim Wicinski wrote:
>
> The chairs have decided to set aside some time in Montreal and see if we
> can work through this problem. We've asked Ondřej from ISC and Willem
> from NLnetLabs to help guide the talk.
I was hoping that there would be another revision of the draft following
IETF 101,
On 5 Jul 2018, at 8:28, Tim Wicinski wrote:
I admit I look at this
problem too much through the lens of someone who thinks about
operational
issues.
E, that's not a bad thing. This is DNSOP, not DNSEXT, after all.
The chairs have decided to set aside some time in Montreal and see if
All
Thanks for this highly entertaining and also information conversation. I
apologize for kicking up the dust but I feel this is one of those
conversations where the end-users/operators and protocol people are
disconnected.I do know when we talked with several DNS providers about
a standard
Tony Finch wrote:
Paul Wouters wrote:
I understand, I just disagree this is the right way. I don't see why
this entire problem shouldn't be resolved at the well, resolver level.
I don't see how that can be deployed in a way that is compatible with
existing software.
there are now a half
Paul Wouters wrote:
>
> I understand, I just disagree this is the right way. I don't see why
> this entire problem shouldn't be resolved at the well, resolver level.
I don't see how that can be deployed in a way that is compatible with
existing software.
Tony.
--
f.anthony.n.finch
On Mon, 25 Jun 2018, Tony Finch wrote:
Then you might as well use that mechanism to update A/ records and
skip the intermediate ANAME?
ANAME will add two things beyond a provisioning-only setup:
* a standard way to signal to dynamic auth servers where to get A/
records from
I
Paul Vixie wrote:
>
> what do you expect non-dynamic servers to do in the presence of ANAME? i
> assume you'll recommend that they also host real A and RRsets at the same
> name-node, which only a dynamic authoritative would ignore?
Yes.
> if so, there's a third work flow available, which
Tony Finch wrote:
ANAME will add two things beyond a provisioning-only setup:
* a standard way to signal to dynamic auth servers where to get A/
records from
* a way to signal to recursives that they might get a better answer if
they query the target themselves
Even for a
Paul Wouters wrote:
> On Mon, 25 Jun 2018, Tony Finch wrote:
>
> > That isn't required if the ANAME target records are fetched/updated by an
> > out-of-band provisioning process.
>
> Then you might as well use that mechanism to update A/ records and
> skip the intermediate ANAME?
ANAME will
On 25/06/2018 16:05, Paul Wouters wrote:
> Then you might as well use that mechanism to update A/ records and
> skip the intermediate ANAME?
+1
Apex records are a provisioning problem, not a protocol one.
Ray
___
DNSOP mailing list
On Mon, 25 Jun 2018, Tony Finch wrote:
That isn't required if the ANAME target records are fetched/updated by an
out-of-band provisioning process.
Then you might as well use that mechanism to update A/ records and
skip the intermediate ANAME?
Paul
Colm MacCárthaigh wrote:
> On Mon, Jun 25, 2018 at 7:02 AM, Tony Finch wrote:
> >
> > That isn't required if the ANAME target records are fetched/updated by an
> > out-of-band provisioning process. A server will want to do it this way if
> > its query rate is bigger than the number of ANAME
On Mon, Jun 25, 2018 at 7:02 AM, Tony Finch wrote:
> > Even that though requires that the authoritative server be capable of
> > waiting for an asynchronously retrieved value before it can respond.
> >
> > For some authoritative servers that might require a substantial redesign.
>
> That isn't
Ray Bellis wrote:
> On 22/06/2018 19:27, Evan Hunt wrote:
>
> > Minor clarification here: ANAME doesn't require the authoritative
> > server itself to do recursion; it requires it to have access to a
> > reursive server.
>
> Even that though requires that the authoritative server be capable of
>
Paul Vixie wrote:
> 神明達哉 wrote:
> >
> > I've always thought there's no point in standardizing ANAME-kind of
> > thing unless its ultimate goal includes the resolver-side support.
> > ...
>
> and to be clear, we already created a system like that: SRV. so if
> that's the only way we can do it,
On 22/06/2018 19:27, Evan Hunt wrote:
> Minor clarification here: ANAME doesn't require the authoritative
> server itself to do recursion; it requires it to have access to a
> reursive server.
Even that though requires that the authoritative server be capable of
waiting for an asynchronously
On Sun, Jun 24, 2018 at 07:42:36PM +, Viktor Dukhovni wrote:
> But that requires a new "XNAME" rrtype, whereas what the users want
> is a more flexible CNAME that coëxists with other RRtypes.
Ah. I didn't understand that you were proposing to reuse the CNAME
rrtype for this.
I think it would
On Sat, Jun 23, 2018 at 07:43:19PM -0700, Joe Abley wrote:
> > Yes, but if they have the NSEC bitmap, they can follow the XNAME
> > without asking again.
> > [...]
> > That's already handled by NSEC/NSEC3.
>
> I think a pragmatic solution needs to work in unsigned zones.
For unsigned zones a
On Sat, Jun 23, 2018 at 07:43:19PM -0700, Joe Abley wrote:
> I think a pragmatic solution needs to work in unsigned zones.
+1, but, an unsigned zone could still return an NSEC-style bitmap. It
wouldn't be provably correct, but neither is any other unsigned response.
You could actually add the
Joe Abley wrote:
On Jun 23, 2018, at 22:45, Paul Vixie wrote:
Joe Abley wrote:
I think a pragmatic solution needs to work in unsigned zones.
...
can someone ask the IAB to rule on whether any new internet technology standard
should address unsigned DNS zones, or for that matter, IPv4
On Sat, Jun 23, 2018 at 10:45 PM Paul Vixie wrote:
>
> Joe Abley wrote:
> > I think a pragmatic solution needs to work in unsigned zones.
> >
> > ...
>
> can someone ask the IAB to rule on whether any new internet technology
> standard should address unsigned DNS zones, or for that matter, IPv4
On Jun 23, 2018, at 22:45, Paul Vixie wrote:
> Joe Abley wrote:
>> I think a pragmatic solution needs to work in unsigned zones.
>>
>> ...
>
> can someone ask the IAB to rule on whether any new internet technology
> standard should address unsigned DNS zones, or for that matter, IPv4 networks?
Joe Abley wrote:
I think a pragmatic solution needs to work in unsigned zones.
...
can someone ask the IAB to rule on whether any new internet technology
standard should address unsigned DNS zones, or for that matter, IPv4
networks?
"let's move on."
--
P Vixie
Hi Victor,
On Jun 23, 2018, at 17:04, Viktor Dukhovni wrote:
> [...]
> Yes, but if they have the NSEC bitmap, they can follow the XNAME
> without asking again.
> [...]
> That's already handled by NSEC/NSEC3.
I think a pragmatic solution needs to work in unsigned zones.
The demand for this
On Tue, Jun 19, 2018 at 07:59:34AM -0700, Joe Abley 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),
On Sat, 23 Jun 2018, Evan Hunt wrote:
Either way we end up importing all of the failure modes of a recursive
server into an authoritative one.
I wasn't disagreeing about it being regrettable, I just wanted to nip in
the bud any repeat of the argument that the auth server would itself have
to
On Fri, Jun 22, 2018 at 03:18:43PM -0400, John R Levine wrote:
> > Minor clarification here: ANAME doesn't require the authoritative server
> > itself to do recursion; it requires it to have access to a reursive
> > server.
>
> I suppose, but that seems to me a distinction without a difference.
神明達哉 wrote:
At Fri, 22 Jun 2018 16:00:51 -0400,
Paul Vixie wrote:
...
Either way we end up importing all of the failure modes of a recursive
server into an authoritative one.
+1. authority servers cannot be coerce-able into doing work, whether
it's computation, memory allocation, or
We do what we should have done from the very beginning and have a rdata type
that combines A and records. Master servers automatically generate the
type and sign it from the A and resets. Address family is determined from
the rdata length.
We have a EDNS option that tells the
At Fri, 22 Jun 2018 16:00:51 -0400,
Paul Vixie wrote:
> >> Minor clarification here: ANAME doesn't require the authoritative server
> >> itself to do recursion; it requires it to have access to a reursive
> >> server.
> >
> > I suppose, but that seems to me a distinction without a difference.
>
The problem with SRV (and MX) is that you can’t tell what an empty additional
section means. (By “you” I mean anything in the resolver chain: app, stub,
recursor, etc.)
If the records are missing, does that mean there aren’t any? Does it mean
they were not cached? Does it mean the server
John R Levine wrote:
On Fri, 22 Jun 2018, Evan Hunt wrote:
Minor clarification here: ANAME doesn't require the authoritative server
itself to do recursion; it requires it to have access to a reursive
server.
I suppose, but that seems to me a distinction without a difference.
Either way we
On Fri, Jun 22, 2018 at 3:27 PM Warren Kumari wrote:
> On Fri, Jun 22, 2018 at 3:13 PM Mukund Sivaraman wrote:
>
>>
>> With additional-from-cache (default on), BIND will return address of
>> target of SRV if it is already in cache. The second RTT will get
>> amortized. It won't take a lot to
On Fri, Jun 22, 2018 at 3:13 PM Mukund Sivaraman wrote:
> On Fri, Jun 22, 2018 at 03:02:35PM -0400, Warren Kumari wrote:
> > On Fri, Jun 22, 2018 at 8:57 AM Joe Abley wrote:
> >
> > > On 19 Jun 2018, at 17:03, Ray Bellis wrote:
> > >
> > > > On 19/06/2018 17:44, Tony Finch wrote:
> > > >
> > >
On Fri, 22 Jun 2018, Evan Hunt wrote:
specified version of ANAME, and it avoids the ANAME ugliness of making
authoritative servers do recursive lookups.
Minor clarification here: ANAME doesn't require the authoritative server
itself to do recursion; it requires it to have access to a reursive
On Fri, Jun 22, 2018 at 03:02:35PM -0400, Warren Kumari wrote:
> On Fri, Jun 22, 2018 at 8:57 AM Joe Abley wrote:
>
> > On 19 Jun 2018, at 17:03, 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
> >
On Fri, Jun 22, 2018 at 8:57 AM Joe Abley wrote:
> On 19 Jun 2018, at 17:03, 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
> >>
On Tue, Jun 19, 2018 at 03:02:12PM -0400, John Levine wrote:
> 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.
Minor clarification here: ANAME doesn't require the
On 19 Jun 2018, at 17:03, 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
tjw ietf wrote:
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 “
there is a reason the spec doesn't support
Well define HTTP which is identical to SRV without the prefix.
None of this is hard to do. That’s 10 minutes work after IANA allocates the
code point.
--
Mark Andrews
On 20 Jun 2018, at 19:40, Jan Včelák wrote:
>> It's also their intransigence re: SRV which has caused the CNAME at the
>>
On 20/06/2018 10:40, Jan Včelák wrote:
> SRV also trades CNAME at apex for wildcard names support.
Yes, that's a fair point, and indeed one of the biggest issues with SRV.
Ray
___
DNSOP mailing list
DNSOP@ietf.org
> It's also their intransigence re: SRV which has caused the CNAME at the
> Apex issue. CNAME was *never* the right answer for doing application
> level indirection in HTTP space.
SRV also trades CNAME at apex for wildcard names support. There is a
plenty of services that employ wildcards to
> 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
hould be no more than 30
minutes work to add even if you are doing it in assembler. It might even be
faster in assembler. It uses all the same mechanisms to figure out the target.
> - Original Message -
> From: David Conrad
> Sent: 2018-06-19 - 18:44
> To: Ray Bellis
&
> 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
Vixie
- Original Message -
From: David Conrad
Sent: 2018-06-19 - 18:44
To: Ray Bellis
Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
> On Jun 19, 2018, at 2:03 PM, Ray Bellis wrote:
>> AIUI, a large part of the supposed issue with SRV was th
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
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 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.
... 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
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
92 matches
Mail list logo
