Re: [Captive-portals] Discovering captive portal API URL via DNS?

What about those resolvers that collapse CNAME responses, effectively eliding them? I assume that you are going to explicitly say that this has to be directed to the resolver provided in network configuration. If that resolver is outside the network or less tightly secured than DHCP/RAs, then

Re: [Captive-portals] Discovering captive portal API URL via DNS?

That's not strictly true (or it needn't be strictly true). The text in #section-3 as worded allows for a portal that lets the clear-text query through but still adds the API link rel into the response. If the text somehow doesn't allow this, we could make it more explicit. If there are 2

Re: [Captive-portals] Discovering captive portal API URL via DNS?

If we have a way to discover the portal via DNS, then maybe we don't need at all? The problem with is that it cannot be used once the portal is open, so if the device logs in, and then disconnects and reconnects, it doesn't work. On Wed, Sep 4, 2019 at 10:05 AM Erik Kline wrote: > Chair hat

Re: [Captive-portals] Discovering captive portal API URL via DNS?

Chair hat off, co-author hat on. We can certain craft some text to round out https://tools.ietf.org/html/draft-ietf-capport-rfc7710bis-00#section-4 when the time comes. Certainly DHCP/RA would retain highest precedence. RFC 7553 URI records would obviate the inevitable discussion about the

Re: [Captive-portals] Discovering captive portal API URL via DNS?

I like that idea, combined with well known. Ex: https:///.well-known/capport-api/xyz Ideally there would be some standardized precedence order as there are different cases for each of these. An example would be a common DNS a service