Erik,
In that case you should take a hard look at caching. The ESNI lookup needs to
retrieve the name and the SNI key of the published server. It will remain valid
as long as the key or the relationship between published and private does not
change. If it is cached, the only required real time
The need to bootstrap ESNI (encrypted SNI) keys via DNS is the forcing
function here for clients. They need to do something new here to address
that, and if that requires an additional lookup then there is opportunity
if other problems can be solved at the same time as long as we don't slow
down E
At Tue, 23 Jul 2019 17:04:43 +0200,
Matthijs Mekking wrote:
> But as soon as clients start querying for ANAME (and not address
> records) meaning it will chase the target itself, the DNS server
> actually does not have to do a target lookup anymore.
True, but my understanding is that the key dif
I was too late to join the virtual queue in the dnsop meeting (fighting
with the Meetecho UI), so I'll send a mail to the list:
Slide 5 of the presentation (Alias form) basically covers the ANAME
case, but still relies on the client to chase the target.
The ANAME record is flexible where the targ
Will AWS Support this?
That seems to be all I see deployed now
On Tue, Jul 9, 2019 at 8:44 PM Paul Vixie wrote:
>
>
> Joe Abley wrote on 2019-07-09 17:35:
> > On Jul 9, 2019, at 20:11, Paul Vixie wrote:
> >
> >> everything other than HTTPS can just use SRV.
> >>
> >> ANAME is (should be) toast
Joe Abley wrote on 2019-07-09 17:35:
On Jul 9, 2019, at 20:11, Paul Vixie wrote:
everything other than HTTPS can just use SRV.
ANAME is (should be) toast(ed).
Didn't we get to this point by acknowledging that there was a gap
between now and the glorious future where SRV and unnamed alter
On Jul 9, 2019, at 20:11, Paul Vixie wrote:
> everything other than HTTPS can just use SRV.
>
> ANAME is (should be) toast(ed).
Didn't we get to this point by acknowledging that there was a gap
between now and the glorious future where SRV and unnamed alternatives
for HTTPS, and that the gap was
On Tuesday, 9 July 2019 21:49:50 UTC Mark Andrews wrote:
> Which invariable ends up being needed to be split over multiple machines for
> different protocols. ANAME can’t do that splitting.
>
> ANAME if it continues to exist needs rules like MX. It also needs to be
> explicitly looked for by the
Which invariable ends up being needed to be split over multiple machines for
different protocols. ANAME can’t do that splitting.
ANAME if it continues to exist needs rules like MX. It also needs to be
explicitly looked for by the application. Add a flag to getaddrinfo() if one
wants to make t
Erik
Speaking as myself and not a chair, I see way too many use cases which are
API end points using ANAME like features. Those
aren't browser based.
I would hope for a solution which would work across all solution spaces -
not just web browsers.
Tim
(speaking only as myself)
On Mon, Jul 8, 20
Thanks for the feedback. I'll add the DNAME clarification in the next
version,
as well as better explain the FQDN separation motivation.
The alt-svc ALPN values come from rfc7838 (Alt-Svc) and rfc7301 (ALPN).
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
Hi, Erik,
One minor issue is that wherever CNAME is referenced, you probably want to
also include a reference to DNAME, including any implied or explicit
chaining of CNAMEs (which could be sequences of CNAME and/or DNAME modulo
their respective behavior.)
It might be a little clearer if the list
On 08/07/2019 22:17, Erik Nygren wrote:
For DNSOP folks, and ANAME proponents in-particular,
I/we are especially interested in understanding if this would address
enough of the customer use-cases driving ANAME were major
browsers to implement support for HTTPSSVC, or would any
limitations her
Ray, thanks for introducing this to dnsop!
I've published a -03 with some of the feedback received so far:
https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-03
For DNSOP folks, and ANAME proponents in-particular,
I/we are especially interested in understanding if this would address
en
For those not paying attention to the HTTP-bis working group, this DNS
RR was proposed there last week.
It appears to subsume the ALT-SVC proposal and also covers the use case
I had in mind with my HTTP Record draft (i.e. CNAME at the apex).
Given that it has someone from at least major brows
15 matches
Mail list logo
