> On Mar 26, 2019, at 7:23 PM, Brian Dickson
> wrote:
>
> We need to start with the base requirements, which is, "I want an apex RR
> that allows HTTP browser indirection just as if there was a CNAME there”.
Yes, THIS.
In response to the discussion last November, I put together this draft
> On 26 Mar 2019, at 18:23, Brian Dickson wrote:
>
> The options are, new RRtypes that require resolver upgrades, or RRtypes that
> are handled by the client application (browser), which benefit from (but do
> not require) resolver upgrades.
The current draft is neither of those (and I
On Tue, Mar 26, 2019 at 9:20 PM Brian Dickson
wrote:
>
>
>
> On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja wrote:
>>
>> On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson
>> > We need to start with the base requirements, which is, "I want an apex RR
>> > that allows HTTP browser indirection just as
On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja wrote:
> On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson
> > We need to start with the base requirements, which is, "I want an apex
> RR that allows HTTP browser indirection just as if there was a CNAME there".
> > Sibling records do not behave like
On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson
> We need to start with the base requirements, which is, "I want an apex RR
> that allows HTTP browser indirection just as if there was a CNAME there".
> Sibling records do not behave like CNAMEs, no matter what extra hacks get
> applied; CNAME
On Tue, Mar 26, 2019 at 6:02 PM Olli Vanhoja wrote:
> On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát
> wrote:
> >
> > I'm not convinced that the resolver parts will be important, regardless
> of what exact mechanism will be chosen. My reasoning is that you can't
> rely on any changes there
On 3/26/19 6:01 PM, Olli Vanhoja wrote:
I think it's totally wrong to*choose* here what we think is the best
method to solve the issue.
I think it goes the direction you'll like. My understanding of the
current plan (of open-source implementors) is to have an RFC specifying
*as little* as
Hello everybody,
(sorry for crossposting, but the side meeting was mentioned during today's
dnsop session).
I was able to organize a bigger room - the meeting will be held in TYROLKA.
Date and Time remain unchanged (Wed, 2019-03-27, 14:00-15:00)
Thanks & enjoy your evening,
Alex
Von:
On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát wrote:
>
> I'm not convinced that the resolver parts will be important, regardless of
> what exact mechanism will be chosen. My reasoning is that you can't rely on
> any changes there being widely deployed soon, and there might not be enough
>
On 3/26/19 5:10 PM, Tony Finch wrote:
I haven't seen any objections to support for ANAME in recursive servers
so I'm surprised you think that is problematic enough to be removed.
I'm not convinced that the resolver parts will be important, regardless
of what exact mechanism will be chosen.
On 3/26/19 5:10 PM, Tony Finch wrote:
Matthijs Mekking wrote:
I think that would be the wrong direction. I believe there is a need to
standardize the ANAME resolution process and so my suggestion would be to
reduce the scope by focusing just on how to do that on the provisioning side
(and
I stand corrected indeed, I just went to the mailing list to find the
latest version of the draft and noticed there were many fundamental
arguments.
Matthijs
On 3/26/19 5:19 PM, Tony Finch wrote:
Matthijs Mekking wrote:
The last draft did not see a lot of comments.
I thought there was
I think the one proposal was very client-specific, which kind of ruled it
out for a generic "aname" type.
That was Ray's "HTTP" RRtype, that I did a deep dive on.
Basically, you are correct; the easiest path forward would be for client
software upgrades to get actual DNS records (rather than rely
Matthijs Mekking wrote:
>
> The last draft did not see a lot of comments.
I thought there was quite a lot of very informative and robust discussion
in November.
https://mailarchive.ietf.org/arch/msg/dnsop/fmMGXQA0ryaJdtjSCVEsQ9ZiF2M
Matthijs Mekking wrote:
>
> I think that would be the wrong direction. I believe there is a need to
> standardize the ANAME resolution process and so my suggestion would be to
> reduce the scope by focusing just on how to do that on the provisioning side
> (and leave secondary servers and
Hi Tony,
On 3/26/19 4:32 PM, Tony Finch wrote:
I'm overloaded at the moment so I wasn't able to rev the draft in time for
IETF 104. I was planning to (basically) re-focus on the meaning of the
bits on the wire, and remove any requirements about how zone contents are
provisioned. Instead there
I'm overloaded at the moment so I wasn't able to rev the draft in time for
IETF 104. I was planning to (basically) re-focus on the meaning of the
bits on the wire, and remove any requirements about how zone contents are
provisioned. Instead there would be a series of examples of existing
That was me on the mic.
To clarify:
DNS open source implementers discussed it earlier this week to see if
there is still appetite for ANAME. The last draft did not see a lot of
comments. To get things moving again we thought it might be a good idea
to make a document with reduced scope.
On Mar 26, 2019, at 3:35 PM, Olli Vanhoja mailto:o...@zeit.co>>
wrote:
Did someone say that there will be a side meeting about mvp ANAME
during this week? If so, I couldn't find that from the calendar.
I believe it was a comment from someone at the mic that the *authors* were
going to have
No
I said I want to reset and work toward an interim.
>From my high tech gadget
> On Mar 26, 2019, at 15:35, Olli Vanhoja wrote:
>
> Did someone say that there will be a side meeting about mvp ANAME
> during this week? If so, I couldn't find that from the calendar.
>
>
Did someone say that there will be a side meeting about mvp ANAME
during this week? If so, I couldn't find that from the calendar.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
I support these as a combined draft to be worked on by the DNSOP WG and
I'm willing to contribute editing/verbage.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Tue, Mar 26, 2019 at 2:19 PM Dave Lawrence wrote:
>
> On the other hand I have direct operational experience that says if a
> problem is being caused not by a generalized DOS or other transient
> network issue, then it can indeed take multiple days to resolve.
> Start of a long weekend?
On Tue, Mar 26, 2019 at 12:48 PM Tony Finch wrote:
>> I think the suggested max stale timer of 7 days is excessive. The aim is
>> to cope with an outage, so I think 1 day is much more reasonable (though I
>> have configured my servers with a 1 hour limit).
Olli Vanhoja writes:
> I agree. At
On Tue, Mar 26, 2019 at 12:48 PM Tony Finch wrote:
>
> Dave Lawrence wrote:
> > Ray Bellis writes:
> > > Serve stael must not become a vector whereby malware can keep its C
> > > systems artificially alive even if the parent has removed the C domain
> > > name.
> >
> > I wholeheartedly agree
Dave Lawrence wrote:
> Ray Bellis writes:
> > Serve stael must not become a vector whereby malware can keep its C
> > systems artificially alive even if the parent has removed the C domain
> > name.
>
> I wholeheartedly agree with this ideal, and am very open to
> considering text improvements.
On Tue, 26 Mar 2019 at 10:48, Paul Vixie wrote:
>
>
> Ian Swett wrote on 2019-03-25 01:28:
> > One way DoH may be faster than DoT in the near future is that DoH can go
> > over HTTP/3 via QUIC and avoid head of line blocking like Do53.
> Do53/UDP has no HoL prolem.
>
> nor does Do853/TCP.
>
TCP
Hi all,
I made an Extended DNS Errors implementation in Unbound during the
IETF104 hackathon. Implementing the code that handles the errors was
rather straightforward, the difficult part is (as Stéphane already
pointed out) finding the right locations in the code for the individual
errors. Some
On Mon, Feb 18, 2019 at 02:06:59PM -0800,
internet-dra...@ietf.org wrote
a message of 48 lines which said:
> Title : In Case of DNSSEC Validation Failures, Do Not
> Change Resolvers
> Author : Jason Livingood
> Filename:
Puneet Sood wrote on 2019-03-25 08:07:
Hi Paul,
On Sun, Mar 24, 2019 at 12:37 PM Paul Vixie wrote:
i object to serve-stale as proposed. my objection is fundamental and
goes to the semantics. no editorial change would resolve the problem.
i would withdraw that objection if this draft
On Mon, 25 Mar 2019 at 16:05, Tony Finch wrote:
> Ted Lemon wrote:
>
> > This is equally an argument for doing DNS over DTLS. This would give
> > similar performance to DoH over QUIC.
>
> If I understand it correctly, DTLS leaves MTU and fragmentation up to the
> application protocol. The DNS
I support adoption too and have (the version in this draft) of ZONEMD
provisioned already in the net-dns.org. zone.
Dick Franks worked on a ZONEMD verifier for Net::DNS during the
Hackathon last Saturday/Sunday (remotely).
On 10-03-19 15:31, Tim Wicinski wrote:
>
> The chairs feel the document
Ian Swett wrote on 2019-03-25 01:28:
One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.
Do53/UDP has no HoL prolem.
nor does Do853/TCP.
only Do53/TCP had an HoL problem, so, it was never widely used, and
33 matches
Mail list logo
