Re: [DNSOP] SRV and HTTP - 18:30 Tuesday (room change)
Room change - we're now in Square Dorchester (the bigger room). Cheers, > On 10 Jul 2018, at 10:25 pm, Mark Nottingham wrote: > > Sure, with the understanding that we'll probably start a few minutes after > that, given the session end at 16:20 (I'm chairing then, it usually takes a > little while to get out). > > I've reserved Barre Oblique from 18:30 until 19:30 on Tuesday. > > Cheers, > > >> On 11 Jul 2018, at 11:52 am, Dave Lawrence wrote: >> >> Dave Lawrence writes: >>> Mark Nottingham writes: I'll start collecting. How about Tuesday, say 6:45-7:45pm? >>> >>> Last session ends at 6:20 and social starts at 7, not sure how late >>> the last bus (if any?) will be leaving the hotel. >> >> Nevermind, walking distance to social, under 1km. Maybe still though >> shifting it a little earlier, like 18:30. >> >> ___ >> DRIU mailing list >> d...@ietf.org >> https://www.ietf.org/mailman/listinfo/driu > > -- > Mark Nottingham https://www.mnot.net/ > > -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
> On 12 Jul 2018, at 10:48 am, Nico Williams wrote: > > On Thu, Jul 12, 2018 at 08:51:43AM +1000, Mark Andrews wrote: > 1) is addressed by defining a new type(s) rather than using prefixes. >>> >>> While that is correct, and truly, it is trivial to implement, it is not >>> trivial to deploy: too many DNS hosting providers would have to update >>> UIs. >> >> Garbage. There really isn’t. People keep saying something can’t be done >> because there are too many X. X get replaced. X get updated. As for DNS >> hosting providers that support a given type, we create a site and report >> what software by version and date and what DNS hosting providers support >> the type native or unknown formats. > > I didn't mean to say not to go this way. On the contrary, we should. > Just that this is an issue. > >> We also don’t have to achieve 100%. People can move to DNS hosters that >> do support the type or host their own DNS. Every DNS hoster that provides >> slave/secondary services already supports they type as UNKNOWN has been out >> there so long. > > Ah yeah, that's true -- not a great UI, but it works. > > 2) is addressed by getting recursive servers to fill in missing > additional data before returning. Named has code in review for this for > SRV as proof of concept. >>> >>> That would be very nice indeed. Unbound will need that too. >>> > 3) is addressed by adding some signalling between the client and > recursive server to indicate if the additional section is complete or not. >>> >>> Well, OK, but as with (2) that requires recursive resolver critical >>> mass. Not necessarily a big deal, though it will take enough time that >>> many apps will need to support falling back to doing multiple queries >>> one by one. >> >> They can do the queries in parallel, that 2 RTTs. > > Yes, that's a big deal. It’s a self correcting problem though. Recursive nameservers do get upgraded. If we could have got people on board back when I first submitted https://datatracker.ietf.org/doc/draft-andrews-http-srv/ everyone would be using it and I suspect recursive servers would have been optimised to fetch the additional data before returning. There is nothing in the RFC’s that says you can’t stall the response to fetch additional data. This isn’t hard. It just requires people to stop arguing and “Just Do It”. Also writing documentation that says “if the query has these properties, fetch missing additional data” will help. We could have done 5 or 6 transitions since 2000 on both the DNS and HTTP sides. While there are long tails most of the world upgrades within 3 years. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
On Thu, Jul 12, 2018 at 08:51:43AM +1000, Mark Andrews wrote: > >>> 1) is addressed by defining a new type(s) rather than using prefixes. > > > > While that is correct, and truly, it is trivial to implement, it is not > > trivial to deploy: too many DNS hosting providers would have to update > > UIs. > > Garbage. There really isn’t. People keep saying something can’t be done > because there are too many X. X get replaced. X get updated. As for DNS > hosting providers that support a given type, we create a site and report > what software by version and date and what DNS hosting providers support > the type native or unknown formats. I didn't mean to say not to go this way. On the contrary, we should. Just that this is an issue. > We also don’t have to achieve 100%. People can move to DNS hosters that > do support the type or host their own DNS. Every DNS hoster that provides > slave/secondary services already supports they type as UNKNOWN has been out > there so long. Ah yeah, that's true -- not a great UI, but it works. > >>> 2) is addressed by getting recursive servers to fill in missing > >>> additional data before returning. Named has code in review for this for > >>> SRV as proof of concept. > > > > That would be very nice indeed. Unbound will need that too. > > > >>> 3) is addressed by adding some signalling between the client and > >>> recursive server to indicate if the additional section is complete or not. > > > > Well, OK, but as with (2) that requires recursive resolver critical > > mass. Not necessarily a big deal, though it will take enough time that > > many apps will need to support falling back to doing multiple queries > > one by one. > > They can do the queries in parallel, that 2 RTTs. Yes, that's a big deal. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
> On 12 Jul 2018, at 7:24 am, Nico Williams wrote: > >>> On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: >>> > On 11 Jul 2018, at 3:55 am, Joe Abley wrote: > > *cups hand to ear* > > Was that the sound of a distant desire to specify use of SRV for > HTTP? >>> >>> I think there are three main objections. >>> >>> 1) Wildcards don’t work with prefixes. >>> 2) Additional data isn’t always returned it may require multiple round >>> trips. >>> 3) Additional data processing doesn’t support negative responses. >>> >>> All of these issues are trivially easy to fix. It just require willingness >>> to implement. >>> >>> 1) is addressed by defining a new type(s) rather than using prefixes. > > While that is correct, and truly, it is trivial to implement, it is not > trivial to deploy: too many DNS hosting providers would have to update > UIs. Garbage. There really isn’t. People keep saying something can’t be done because there are too many X. X get replaced. X get updated. As for DNS hosting providers that support a given type, we create a site and report what software by version and date and what DNS hosting providers support the type native or unknown formats. We also don’t have to achieve 100%. People can move to DNS hosters that do support the type or host their own DNS. Every DNS hoster that provides slave/secondary services already supports they type as UNKNOWN has been out there so long. > Let me add my voice in favor of new RR types by which to replace SRV > RRs. URI is one of them, for the sorts of things we do in Kerberos for > KDC discovery, but no really appropriate for resolving HTTP authorities. > >>> 2) is addressed by getting recursive servers to fill in missing additional >>> data before returning. Named has code in review for this for SRV as proof >>> of concept. > > That would be very nice indeed. Unbound will need that too. > >>> 3) is addressed by adding some signalling between the client and recursive >>> server to indicate if the additional section is complete or not. > > Well, OK, but as with (2) that requires recursive resolver critical > mass. Not necessarily a big deal, though it will take enough time that > many apps will need to support falling back to doing multiple queries > one by one. They can do the queries in parallel, that 2 RTTs. > Nico > -- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
> > On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: > > > > > > On 11 Jul 2018, at 3:55 am, Joe Abley wrote: > > > > > > > > *cups hand to ear* > > > > > > > > Was that the sound of a distant desire to specify use of SRV for > > > > HTTP? > > > > I think there are three main objections. > > > > 1) Wildcards don’t work with prefixes. > > 2) Additional data isn’t always returned it may require multiple round > > trips. > > 3) Additional data processing doesn’t support negative responses. > > > > All of these issues are trivially easy to fix. It just require willingness > > to implement. > > > > 1) is addressed by defining a new type(s) rather than using prefixes. While that is correct, and truly, it is trivial to implement, it is not trivial to deploy: too many DNS hosting providers would have to update UIs. Let me add my voice in favor of new RR types by which to replace SRV RRs. URI is one of them, for the sorts of things we do in Kerberos for KDC discovery, but no really appropriate for resolving HTTP authorities. > > 2) is addressed by getting recursive servers to fill in missing additional > > data before returning. Named has code in review for this for SRV as proof > > of concept. That would be very nice indeed. Unbound will need that too. > > 3) is addressed by adding some signalling between the client and recursive > > server to indicate if the additional section is complete or not. Well, OK, but as with (2) that requires recursive resolver critical mass. Not necessarily a big deal, though it will take enough time that many apps will need to support falling back to doing multiple queries one by one. Nico -- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
On 11 Jul 2018, at 8:21, Mark Andrews wrote: > As for lib curl, there is not a RFC that says to lookup SRV records for HTTP > or HTTPS. Agree, and I have wanted it to be part of HTTP/2, or at least resolve this mess, but it did not happen. This is my recurring discussion with Daniel when we have beer :-D paf signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
> On Jul 10, 2018, at 7:22 PM, Mark Nottingham wrote: > > > >> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >> >> On Jul 10, 2018, at 18:02, Adam Roach wrote: >> >>> In large part because DNS provides "a richer scheme that accommodates >>> address families and multiple addresses with priorities". >> >> *cups hand to ear* >> >> Was that the sound of a distant desire to specify use of SRV for HTTP? >> > > I recently did some digging on this topic, and can try to characterise what > the issues / objections are. > > Would people be interested in a (hopefully brief) side meeting to discuss and > maybe come to a shared understanding of the problem space? Definitely. We (Traffic Server) added some support for SRV a while back, but it’s mostly a hack. Cheers, — Leif ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
> On 11 Jul 2018, at 3:53 pm, Patrik Fältström wrote: > > On 11 Jul 2018, at 3:30, Mark Andrews wrote: > >> I think there are three main objections. >> >> 1) Wildcards don’t work with prefixes. >> 2) Additional data isn’t always returned it may require multiple round trips. >> 3) Additional data processing doesn’t support negative responses. > > 4) Various libraries in PHP and ultimately lib curl do not include SRV in the > resolution Then PHP is not STD 13 compliant. Resolver libraries are supposed to be able resolve UNKNOWN records per STD 13 and that includes SRV. As for lib curl, there is not a RFC that says to lookup SRV records for HTTP or HTTPS. > 5) New resource record types are very hard to implement (same argument as why > we use TXT for SPF and not SPF for example) SPF was just plain unwillingness to complete the transition. The code was out there. It was being deployed. TXT to SPF transition was never part of the experiment, it was in addition to the experiment. No resources record is hard to implement. What hard is getting someone to commit 30 minutes to 1 hour of time to do something at all. That is what it takes most pieces of software to add a new record type. Thats been true since I started in the DNS back in the early 90’s. > 6) You "only" change hostname with SRV and not a "complete change of the URL >> All of these issues are trivially easy to fix. It just require willingness >> to implement. >> >> 1) is addressed by defining a new type(s) rather than using prefixes. >> 2) is addressed by getting recursive servers to fill in missing additional >> data before returning. Named has code in review for this for SRV as proof >> of concept. >> 3) is addressed by adding some signalling between the client and recursive >> server to indicate if the additional section is complete or not. > > 4) Is of course "just code" in lib curl and what not > > 5) Is like (4) but possibly harder if you want it implemented in PHP, > javascript etc and not in the underlying libraries > > 6) This is why I came up with URI which is supposed to be a competitor to > "well known URI" > > paf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
On 11 Jul 2018, at 5:16, John R Levine wrote: > It's always been my impression that the http crowd believe that the > overhead of a two DNS lookups is too slow, for some meaning of too slow. They rather stay in the space they know, HTTP resolution, and do multiple HTTP requests instead of multiple DNS requests. Just like we DNS people rather do more in DNS. paf signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
On 11 Jul 2018, at 3:30, Mark Andrews wrote: > I think there are three main objections. > > 1) Wildcards don’t work with prefixes. > 2) Additional data isn’t always returned it may require multiple round trips. > 3) Additional data processing doesn’t support negative responses. 4) Various libraries in PHP and ultimately lib curl do not include SRV in the resolution 5) New resource record types are very hard to implement (same argument as why we use TXT for SPF and not SPF for example) 6) You "only" change hostname with SRV and not a "complete change of the URL" > All of these issues are trivially easy to fix. It just require willingness > to implement. > > 1) is addressed by defining a new type(s) rather than using prefixes. > 2) is addressed by getting recursive servers to fill in missing additional > data before returning. Named has code in review for this for SRV as proof of > concept. > 3) is addressed by adding some signalling between the client and recursive > server to indicate if the additional section is complete or not. 4) Is of course "just code" in lib curl and what not 5) Is like (4) but possibly harder if you want it implemented in PHP, javascript etc and not in the underlying libraries 6) This is why I came up with URI which is supposed to be a competitor to "well known URI" paf signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
> On 11 Jul 2018, at 1:16 pm, John R Levine wrote: > >> On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote: >>> There's over 6000 service names defined for SRV. That's a lot of rrtypes. >> >> But HTTP/HTTPS is the one we have by far the most problems with. > > True, and there have been some proposals for DNS records to return http > parameters. > > It's always been my impression that the http crowd believe that the > overhead of a two DNS lookups is too slow, for some meaning of too slow. Which is predicated on the recursive server not filling in the additional section. Recursive servers can and do fill the additional section with SRV (starting with NAPTR records) then add A, and TLSA records. They can lookup missing record before returning the SRV or NAPTR records (there is code to do that for SRV). Its easy to do the same thing for other record types. > Regards, > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote: There's over 6000 service names defined for SRV. That's a lot of rrtypes. But HTTP/HTTPS is the one we have by far the most problems with. True, and there have been some proposals for DNS records to return http parameters. It's always been my impression that the http crowd believe that the overhead of a two DNS lookups is too slow, for some meaning of too slow. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
On Tue, Jul 10, 2018 at 11:08:37PM -0400, John Levine wrote: > There's over 6000 service names defined for SRV. That's a lot of rrtypes. But HTTP/HTTPS is the one we have by far the most problems with. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
In article <82099ded-ccb6-4cdc-bfe6-97b1ab3eb...@isc.org> you write: >1) Wildcards don’t work with prefixes. >1) is addressed by defining a new type(s) rather than using prefixes. There's over 6000 service names defined for SRV. That's a lot of rrtypes. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP - 18:30 Tuesday
Sure, with the understanding that we'll probably start a few minutes after that, given the session end at 16:20 (I'm chairing then, it usually takes a little while to get out). I've reserved Barre Oblique from 18:30 until 19:30 on Tuesday. Cheers, > On 11 Jul 2018, at 11:52 am, Dave Lawrence wrote: > > Dave Lawrence writes: >> Mark Nottingham writes: >>> I'll start collecting. How about Tuesday, say 6:45-7:45pm? >> >> Last session ends at 6:20 and social starts at 7, not sure how late >> the last bus (if any?) will be leaving the hotel. > > Nevermind, walking distance to social, under 1km. Maybe still though > shifting it a little earlier, like 18:30. > > ___ > DRIU mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/driu -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
> On 11 Jul 2018, at 11:51 am, Dave Lawrence wrote: > > Mark Nottingham writes: >> I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > Last session ends at 6:20 and social starts at 7, not sure how late > the last bus (if any?) will be leaving the hotel. It’s a 9 minute walk (4 blocks). -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
Dave Lawrence writes: > Mark Nottingham writes: > > I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > Last session ends at 6:20 and social starts at 7, not sure how late > the last bus (if any?) will be leaving the hotel. Nevermind, walking distance to social, under 1km. Maybe still though shifting it a little earlier, like 18:30. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
Mark Nottingham writes: > I'll start collecting. How about Tuesday, say 6:45-7:45pm? Last session ends at 6:20 and social starts at 7, not sure how late the last bus (if any?) will be leaving the hotel. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
Fine by me. > On 11 Jul 2018, at 11:32 am, Mark Nottingham wrote: > > I didn't find those, but I found many others. > > I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > > >> On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: >> >> >> >>> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: >>> >>> >>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: On Jul 10, 2018, at 18:02, Adam Roach wrote: > In large part because DNS provides "a richer scheme that accommodates > address families and multiple addresses with priorities". *cups hand to ear* Was that the sound of a distant desire to specify use of SRV for HTTP? >>> >>> I recently did some digging on this topic, and can try to characterise what >>> the issues / objections are. >> >> I think there are three main objections. >> >> 1) Wildcards don’t work with prefixes. >> 2) Additional data isn’t always returned it may require multiple round trips. >> 3) Additional data processing doesn’t support negative responses. >> >> All of these issues are trivially easy to fix. It just require willingness >> to implement. >> >> 1) is addressed by defining a new type(s) rather than using prefixes. >> 2) is addressed by getting recursive servers to fill in missing additional >> data before returning. Named has code in review for this for SRV as proof >> of concept. >> 3) is addressed by adding some signalling between the client and recursive >> server to indicate if the additional section is complete or not. >> >> >>> Would people be interested in a (hopefully brief) side meeting to discuss >>> and maybe come to a shared understanding of the problem space? >>> >>> Cheers, >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > -- > Mark Nottingham https://www.mnot.net/ > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
I didn't find those, but I found many others. I'll start collecting. How about Tuesday, say 6:45-7:45pm? > On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: > > > >> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: >> >> >> >>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>> >>> On Jul 10, 2018, at 18:02, Adam Roach wrote: >>> In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities". >>> >>> *cups hand to ear* >>> >>> Was that the sound of a distant desire to specify use of SRV for HTTP? >>> >> >> I recently did some digging on this topic, and can try to characterise what >> the issues / objections are. > > I think there are three main objections. > > 1) Wildcards don’t work with prefixes. > 2) Additional data isn’t always returned it may require multiple round trips. > 3) Additional data processing doesn’t support negative responses. > > All of these issues are trivially easy to fix. It just require willingness > to implement. > > 1) is addressed by defining a new type(s) rather than using prefixes. > 2) is addressed by getting recursive servers to fill in missing additional > data before returning. Named has code in review for this for SRV as proof of > concept. > 3) is addressed by adding some signalling between the client and recursive > server to indicate if the additional section is complete or not. > > >> Would people be interested in a (hopefully brief) side meeting to discuss >> and maybe come to a shared understanding of the problem space? >> >> Cheers, >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org -- Mark Nottingham https://www.mnot.net/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: > > > >> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >> >> On Jul 10, 2018, at 18:02, Adam Roach wrote: >> >>> In large part because DNS provides "a richer scheme that accommodates >>> address families and multiple addresses with priorities". >> >> *cups hand to ear* >> >> Was that the sound of a distant desire to specify use of SRV for HTTP? >> > > I recently did some digging on this topic, and can try to characterise what > the issues / objections are. I think there are three main objections. 1) Wildcards don’t work with prefixes. 2) Additional data isn’t always returned it may require multiple round trips. 3) Additional data processing doesn’t support negative responses. All of these issues are trivially easy to fix. It just require willingness to implement. 1) is addressed by defining a new type(s) rather than using prefixes. 2) is addressed by getting recursive servers to fill in missing additional data before returning. Named has code in review for this for SRV as proof of concept. 3) is addressed by adding some signalling between the client and recursive server to indicate if the additional section is complete or not. > Would people be interested in a (hopefully brief) side meeting to discuss and > maybe come to a shared understanding of the problem space? > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SRV and HTTP
Yes On Tue, Jul 10, 2018 at 9:22 PM, Mark Nottingham wrote: > > > > On 11 Jul 2018, at 3:55 am, Joe Abley wrote: > > > > On Jul 10, 2018, at 18:02, Adam Roach wrote: > > > >> In large part because DNS provides "a richer scheme that accommodates > address families and multiple addresses with priorities". > > > > *cups hand to ear* > > > > Was that the sound of a distant desire to specify use of SRV for HTTP? > > > > I recently did some digging on this topic, and can try to characterise > what the issues / objections are. > > Would people be interested in a (hopefully brief) side meeting to discuss > and maybe come to a shared understanding of the problem space? > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Ólafur Gudmundsson | Engineering Director www.cloudflare.com blog.cloudflare.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
