Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
> On 8 Nov 2018, at 2:30 pm, Brian Dickson > wrote: > > > > On Thu, Nov 8, 2018 at 10:06 AM Dan York wrote: > Brian, > > DY> Upgrading our DNS infrastructure is VERY difficult. Because it is still > massively distributed and decentralized (even though we do have ongoing > centralization/consolidation), getting a new RRTYPE deployed means: > > - upgrading all the authoritative servers to support the new RRTYPE > - upgrading all the *provisioning software* at the thousands of DNS > registries, DNS registrars, DNS hosting operators to support the new RRTYPE > - upgrading the *millions* of recursive resolvers to know what to do they > receive the new RRTYPE in a query response > > > Actually, for this specific case, the only places that require support (at > least initially) are: > • Authority servers (because, duh), unless they already support it, via > hard-coded types and RDATA generically (maybe not overly relevant, but > covering all cases) > • Authority provisioning systems for DNS hosting services (at least one > hosting service has to do so before the type is "live") (also possibly > supported by the hard-coded mechanism?) > • Clients (because someone has to request the new type) > For new RRtypes, registries, registrars, and their provisioning services do > NOT need to support them; the new types are in the zones only. > New RRtypes which do not require any "additional" processing, do NOT strictly > speaking require resolver support, since resolvers handle unknown RRtypes. > (Mark A can quote you the RFC, and I think has recently.) It's RFC 1034 and RFC 1035. AKA STD 13. The only components that have *ever* needed upgrading for a new type from the very beginning for a where the authoritative servers for the zone as they needed to be able to load the record. Recursive servers and stub resolvers where all supposed to treat unknown record types and blobs of data. DNS records are named TVLs, name compression was only every valid on well known types and the only possible well known types are those listed in STD13. Anything that dropped or blocked unknown types was not STD 13 compliant. RFC 3597 reduced the list of components that needed to be updated to NONE though it was still desirable to update the primary server and provisioning systems. RFC 1034 3. General lookup function This function retrieves arbitrary information from the DNS, and has no counterpart in previous systems. The caller supplies a QNAME, QTYPE, and QCLASS, and wants all of the matching RRs. This function will often use the DNS format for all RR data instead of the local host's, and returns all RR content (e.g., TTL) instead of a processed form with local quoting conventions. When the resolver performs the indicated function, it usually has one of the following results to pass back to the client: - One or more RRs giving the requested data. In this case the resolver returns the answer in the appropriate format. - A name error (NE). This happens when the referenced name does not exist. For example, a user may have mistyped a host name. - A data not found error. This happens when the referenced name exists, but data of the appropriate type does not. For example, a host address function applied to a mailbox name would return this error since the name exists, but no address RR is present. It is important to note that the functions for translating between host names and addresses may combine the "name error" and "data not found" error conditions into a single type of error return, but the general function should not. One reason for this is that applications may ask first for one type of information about a name followed by a second request to the same name for some other type of information; if the two errors are combined, then useless queries may slow the application. > On the plus side, I can confirm at least one hosting/authority service will > do this as soon as a stable spec is available (i.e. HTTP and a code point > early allocation). > > That should take what, a couple of weeks or so? > > It'd be nice to ask the browser folks to start using something that is > already deployed (however small the initial user base is, with the > expectation of viral uptake.) > > > DY> Which does means we do need to get started NOW [...] > > Thanks for bringing this all together, > Dan > > You're welcome, and thanks for participating in the discussion. > > Brian > ___ > 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] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
On Thu, Nov 8, 2018 at 11:47 AM Dan York wrote: > Brian, > > > On Nov 8, 2018, at 10:30 AM, Brian Dickson < > brian.peter.dick...@gmail.com> wrote: > > > > For new RRtypes, registries, registrars, and their provisioning services > do NOT need to support them; the new types are in the zones only. > > DY> (Experiencing a "DUH!" moment.) Yes, of course. It's zone data so > only those entities handling zone data need to care. In my > still-annoyingly-jet-lagged mind, I made the classic mistake of equating > "registrars" with "DNS hosting operators" because so many registrars are > *also* DNS hosting providers. > > No problem - it's very easy to mix up the pure math relationships "one to one" and "onto". (Don't try to, BTW, my brain still hurts from 3rd year pure math in 1986.) > > New RRtypes which do not require any "additional" processing, do NOT > strictly speaking require resolver support, since resolvers handle unknown > RRtypes. (Mark A can quote you the RFC, and I think has recently.) > > DY> Ah, interesting. Where the proposed HTTP RRtype has behavior similar > to the CNAME record, my assumption would be that resolver software would > need to know what to do once it receives the record. For that reason, > wouldn't all the resolvers (or at least an extremely high %) need to be > upgraded to support the new record? > > Yes and no. It requires EITHER the resolver OR the client to handle the name it gets back, and do another query for A/ on that, for whatever the client originally was looking for. I.e. an upgraded client (e.g. browser) could bootstrap the system prior to widespread resolver upgrades. Resolver upgrades would lower their own load, by making the parallel/serial re-queries un-necessary. Thus, it puts at least a modest incentive on resolvers to upgrade. It's kind of like DIY CNAME, except for only one iteration. (If you do a lookup on a name for A or , and the name is a CNAME-only thing in DNS, resolvers handle that already.) So, if the resolver is upgraded, it would return the HTTP answer plus A and records. If the resolver was not upgraded, it would return just the HTTP answer (an FQDN), and the client would have to ask for A and/or records at that name. (The resolver would still handle the chaining if the FQDN was a CNAME.) NB: client stub OS libraries for getaddrinfo return lists of A, , or both, depending on the AF_* parameter (AF_INET, AF_INET6, AF_ANY). Those might be multiple (parallel, possibly) DNS queries, but the API-calling code would be simple enough. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
On 08/11/2018 11:47, Dan York wrote: For that reason, wouldn't all the resolvers (or at least an extremely high %) need to be upgraded to support the new record? They don't _have_ to be, but performance is improved when they are (since only an upgraded resolver will include the A and answers in the additional section). The critical path is the browsers, since none of this works unless they start looking up the HTTP record. As a transition mechanism, site operators would still need to publish their existing A and records by whatever means they currently do (even if that's e.g. a CNAME flattening on the authority server). Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
Brian, > On Nov 8, 2018, at 10:30 AM, Brian Dickson > wrote: > > For new RRtypes, registries, registrars, and their provisioning services do > NOT need to support them; the new types are in the zones only. DY> (Experiencing a "DUH!" moment.) Yes, of course. It's zone data so only those entities handling zone data need to care. In my still-annoyingly-jet-lagged mind, I made the classic mistake of equating "registrars" with "DNS hosting operators" because so many registrars are *also* DNS hosting providers. > New RRtypes which do not require any "additional" processing, do NOT strictly > speaking require resolver support, since resolvers handle unknown RRtypes. > (Mark A can quote you the RFC, and I think has recently.) DY> Ah, interesting. Where the proposed HTTP RRtype has behavior similar to the CNAME record, my assumption would be that resolver software would need to know what to do once it receives the record. For that reason, wouldn't all the resolvers (or at least an extremely high %) need to be upgraded to support the new record? > On the plus side, I can confirm at least one hosting/authority service will > do this as soon as a stable spec is available (i.e. HTTP and a code point > early allocation). DY> :-) Good to know! Dan -- Dan York Director, Content & Web Strategy, Internet Society y...@isoc.org +1-802-735-1624 Jabber: y...@jabber.isoc.org Skype: danyork http://twitter.com/danyork http://www.internetsociety.org/ smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
On Nov 8, 2018, at 9:38 AM, p vixie ; wrote: If additional data is optional, so most resolvers can just pass it through, the DNS techs will say yes but the HTTP techs will say no. We have a bad track record of predicting what other groups will want from the DNS or use it for. Specifying what "HTTP techs" will say seems premature before a fully-fleshed proposal is taken to them. are you thinking i made that part up? did you not notice when they rejected SRV for two decades, or what reason they gave? (hint: "i solved the wildcard problem you weren't worried about, but the browser will still have to ask two questions on first reference, to get the cache populated, and additional data will only be included if the resolver has been upgraded to recognize this type code"... will not change the answer they gave to SRV.) feels a bit like ground-hog day in here. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
On Nov 8, 2018, at 9:38 AM, p vixie wrote: > > If additional data is optional, so most resolvers can just pass it through, > the DNS techs will say yes but the HTTP techs will say no. We have a bad track record of predicting what other groups will want from the DNS or use it for. Specifying what "HTTP techs" will say seems premature before a fully-fleshed proposal is taken to them. --Paul Hoffan smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
From my high tech gadget > On Nov 8, 2018, at 06:30, Ray Bellis wrote: > >> On 08/11/2018 04:13, Tim Wicinski wrote: >> >> I can't stress this enough - when you see ALIAS records at zone cuts >> that point to a database server, already, then we've missed the >> "server specific" ball. > > This sounds like it ought to be a very unusual configuration. > > Even with a zone cut, couldn't those DB servers have been addressed as > 'db.' instead? Sure but as more than one engineer whose been using this for several years asks “why should I change? This works now and you’re just cramping engineering velocity. “ And saying “it’s not standard” doesn’t hold water. Sure there are migration issues but if folks stay in their vendor ecosystem These are the questions we as operators are asked regularly. These are the questions DNSOP need to look forward on. > >> And can someone show a significant number of SRV examples outside of >> SIP and some gaming servers? > > Kerberos and AD both use SRV records. Bonjour uses SRV extensively. I forgot about AD. Those are set up by admins right? Doesn’t Bonjour create those records behind the scenes? People are saying a domain owner is going to log into godaddy and configure a SRV record. If you want to convince me SRV will work get the vendors to support it seamlessly. > Either way, SRV is only one of three different ways that services are > differentiated (per 5507). > > Ray > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
If additional data is optional, so most resolvers can just pass it through, the DNS techs will say yes but the HTTP techs will say no. - Original Message - From: Brian Dickson Sent: 2018-11-07 - 18:30 To: "dnsop@ietf.org WG" Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME > I'm going to start a clean, related thread, to discuss a bunch of > questions, that I think can help with the ongoing threads. > > Rationale: > I think many of the viewpoints some folks have are skewed by pre-existing > familiarity with the protocol, and implementations (including browsers, > libraries, stubs, forwarders, resolvers, and authorities, plus "specials"). > > What we may be forgetting are the USERS of these systems, and the use > cases. These matter both in terms of their diversity in their technical > savvy, but also in terms of their respective numbers. > > We can sometimes forget that registered domains (the entry point right > below the 'public suffix' level in the domain name system) number in the > 100s of millions, and the user base is global. > > Starting right from that point, it's safe to say that the vast majority of > registrants are not operating their own authority servers and editing zone > files. > > This means that they are doing something else, and they are not all doing > one single "something else", either; it is a mixed bag with no dominant > "pie slice". > > Why not SRV? > There are a number of reasons that SRV is not in widespread use, that have > to do with the mixed bag of ways those 100s of millions of registrants > operate their domains. > > Even if registrants use systems that expose SRV to them to configure, as an > RRtype, the other parts of SRV are not at all novice-friendly. From the > wikipedia page: > > _service._proto.name. TTL class SRV priority weight port target > > > This isn't at all friendly. The alternative is to put all of the above into > some kind of UI. But again, this puts several more roadblocks on uptake *by > users*. Regardless of the interface, the values need to be supplied, and > the input needs to be validated, with the ability for the user to > understand error messages and fix the input. There is no short cut for > understanding the values, and knowing about _service and _proto. If the > user doesn't get it right the first time, they are very likely to give up, > since there are so many variables. For HTTP as a use case, it is far too > complex. > > In other words, SRV is really only suitable for a tiny fraction of the > registrants. For them, there's still a learning curve, but they have a need > that only SRV can fill, and an incentive to do so. Those are typically > enterprises, large institutions, entities with actual IT staff. > > Yes, resolvers and authority software do SRV already, that isn't the point. > > If you are an SRV proponent, here's my recommendation: Find someone you are > acquainted with, who doesn't have any DNS familiarity, show them CNAME and > SRV, and ask them for their opinions. Please. > > Why is CNAME so abundantly used? > If we look at CNAME, it is much simpler, and probably one of the first > things anyone doing DNS every plays with. > (But even then, it isn't completely trivial, given the trailing dot problem > that pretty much everyone gets wrong at some point in their DNS career.) > Even for a novice: there is only one "variable", and lots of information > and advice on CNAMEs can be found online. The learning curve is gentle and > short. > > Why not CNAME? > The secondary issue with CNAME isn't just the apex issue, it is the > non-coexistence issue (of which apex is merely the poster child). > > Why a new RRtype? > Here's the TL;DR: on these issues, IMNSHO: browser vendors won't do stuff > that isn't really in widespread use, even if it is possibly easy to > implement. SRV isn't ever going to be truly widespread, as a percentage of > domains. > > We want a solution that is easy to deploy, easy to understand, easy to use, > SOLVES THE COEXISTENCE PROBLEM, and doesn't change the primary rules on > "stupid DNS tricks", i.e. that the tricks are client-oriented by way of the > resolver (or possibly client-subnet). > > This leads to the only logical outcome that is implementable, doesn't > require more than five minutes for any user to understand, doesn't require > (but supports optional) changes to resolvers, doesn't require any change to > authority serving beyond new RRtype(s), and thus can/will get brower > support (simply by the numbers): HTTP. > > Why should HTTP be so simple? > Because it is simple to use. > It looks just like a CNAME. > It can chain with CNAMEs and DNAMEs. > It works with stupid DNS tricks. > It gets the job done. > It is a common denominator. > That is a feature, not a bug. > > Why service-specific? > As Ray points out, MX is already there as a service-specic RRtype. > Other service-specific RRtypes may be needed, and new RRtypes are easy to > get now. >
[DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
I'm going to start a clean, related thread, to discuss a bunch of questions, that I think can help with the ongoing threads. Rationale: I think many of the viewpoints some folks have are skewed by pre-existing familiarity with the protocol, and implementations (including browsers, libraries, stubs, forwarders, resolvers, and authorities, plus "specials"). What we may be forgetting are the USERS of these systems, and the use cases. These matter both in terms of their diversity in their technical savvy, but also in terms of their respective numbers. We can sometimes forget that registered domains (the entry point right below the 'public suffix' level in the domain name system) number in the 100s of millions, and the user base is global. Starting right from that point, it's safe to say that the vast majority of registrants are not operating their own authority servers and editing zone files. This means that they are doing something else, and they are not all doing one single "something else", either; it is a mixed bag with no dominant "pie slice". Why not SRV? There are a number of reasons that SRV is not in widespread use, that have to do with the mixed bag of ways those 100s of millions of registrants operate their domains. Even if registrants use systems that expose SRV to them to configure, as an RRtype, the other parts of SRV are not at all novice-friendly. From the wikipedia page: _service._proto.name. TTL class SRV priority weight port target This isn't at all friendly. The alternative is to put all of the above into some kind of UI. But again, this puts several more roadblocks on uptake *by users*. Regardless of the interface, the values need to be supplied, and the input needs to be validated, with the ability for the user to understand error messages and fix the input. There is no short cut for understanding the values, and knowing about _service and _proto. If the user doesn't get it right the first time, they are very likely to give up, since there are so many variables. For HTTP as a use case, it is far too complex. In other words, SRV is really only suitable for a tiny fraction of the registrants. For them, there's still a learning curve, but they have a need that only SRV can fill, and an incentive to do so. Those are typically enterprises, large institutions, entities with actual IT staff. Yes, resolvers and authority software do SRV already, that isn't the point. If you are an SRV proponent, here's my recommendation: Find someone you are acquainted with, who doesn't have any DNS familiarity, show them CNAME and SRV, and ask them for their opinions. Please. Why is CNAME so abundantly used? If we look at CNAME, it is much simpler, and probably one of the first things anyone doing DNS every plays with. (But even then, it isn't completely trivial, given the trailing dot problem that pretty much everyone gets wrong at some point in their DNS career.) Even for a novice: there is only one "variable", and lots of information and advice on CNAMEs can be found online. The learning curve is gentle and short. Why not CNAME? The secondary issue with CNAME isn't just the apex issue, it is the non-coexistence issue (of which apex is merely the poster child). Why a new RRtype? Here's the TL;DR: on these issues, IMNSHO: browser vendors won't do stuff that isn't really in widespread use, even if it is possibly easy to implement. SRV isn't ever going to be truly widespread, as a percentage of domains. We want a solution that is easy to deploy, easy to understand, easy to use, SOLVES THE COEXISTENCE PROBLEM, and doesn't change the primary rules on "stupid DNS tricks", i.e. that the tricks are client-oriented by way of the resolver (or possibly client-subnet). This leads to the only logical outcome that is implementable, doesn't require more than five minutes for any user to understand, doesn't require (but supports optional) changes to resolvers, doesn't require any change to authority serving beyond new RRtype(s), and thus can/will get brower support (simply by the numbers): HTTP. Why should HTTP be so simple? Because it is simple to use. It looks just like a CNAME. It can chain with CNAMEs and DNAMEs. It works with stupid DNS tricks. It gets the job done. It is a common denominator. That is a feature, not a bug. Why service-specific? As Ray points out, MX is already there as a service-specic RRtype. Other service-specific RRtypes may be needed, and new RRtypes are easy to get now. (Perhaps we can anticipate what some of those are, and include those in the draft?) Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Any website publishers who use CDNs on the list?
> On 8 Nov 2018, at 5:07 am, Paul Vixie wrote: > > > > Tony Finch wrote: >> ... >> >> And even if you can get the recursive server addresses, you should still >> go through the name service switch to deal with names that aren't in the >> DNS. > > agreed. For A and , but not for HTTP, SRV and all the rest as there are no alternative data sources for those values. >> The custom DNS stub resolvers that I know about (adns, ldns, libevent) >> reimplement the libc resolver, with their own parsers for /etc/resolv.conf >> and all the rest. > > dns requests should almost universally go out via the open source "getdns" > API (https://getdnsapi.net/) at this point. if your code uses one of the > above methods, or getXbyY() in any form, please investigate. It really doesn’t matter which API you decide to use to lookup HTTP or SRV. They all get the same data. > -- > P Vixie > > ___ > 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] Further ANAME minimization /\ Ray convergence
On 11/07/2018 02:13 PM, Tim Wicinski wrote: > Tony says this: > > " It isn't a judgment about what's good, but an observation about what > is done." > > I can't stress this enough - when you see ALIAS records at zone cuts > that point to a database server, > already, then we've missed the "server specific" ball. > > And can someone show a significant number of SRV examples outside of SIP > and some gaming > servers? From data in our systems, most common in order is _autodiscover and other email/calendar related, then sip, then jabber/xmpp. After that, the numbers are far less significant. -- Michael Sheldon Dev-DNS Services GoDaddy.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
On 08/11/2018 04:13, Tim Wicinski wrote: I can't stress this enough - when you see ALIAS records at zone cuts that point to a database server, already, then we've missed the "server specific" ball. This sounds like it ought to be a very unusual configuration. Even with a zone cut, couldn't those DB servers have been addressed as 'db.' instead? And can someone show a significant number of SRV examples outside of SIP and some gaming servers? Kerberos and AD both use SRV records. Bonjour uses SRV extensively. Either way, SRV is only one of three different ways that services are differentiated (per 5507). Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
Tony says this: " It isn't a judgment about what's good, but an observation about what is done." I can't stress this enough - when you see ALIAS records at zone cuts that point to a database server, already, then we've missed the "server specific" ball. And can someone show a significant number of SRV examples outside of SIP and some gaming servers? On Thu, Nov 8, 2018 at 3:48 AM Richard Gibson wrote: > This is such a salient point, and always draws me back towards a desire > for accompanying questions. They wouldn't directly address exactly the > issue handled by ANAME (the addresses of one host corresponding to those > of a distinct [probably out-of-bailiwick] name), but might make it > moot—or at least tolerable—by tackling more fundamental progress > blockers. Support for covering apex A, apex , and service-specific > SRV (especially with target host addresses in the additional section of > the response) in a single transaction could absolve many sins. > > On 11/6/18 13:51, Ray Bellis wrote: > > IMHO, any record that doesn't support a service selector isn't doing > > its job properly. > > > > You _have_ to be able to say "if I want this service at this domain, I > > either prepend this prefix, or lookup this type", otherwise you're > > just forcing _all_ services to connect to the A and found there. > > > > A and should be for connecting to the right _host_, once you've > > established from the _service_ which host that is. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
This is such a salient point, and always draws me back towards a desire for accompanying questions. They wouldn't directly address exactly the issue handled by ANAME (the addresses of one host corresponding to those of a distinct [probably out-of-bailiwick] name), but might make it moot—or at least tolerable—by tackling more fundamental progress blockers. Support for covering apex A, apex , and service-specific SRV (especially with target host addresses in the additional section of the response) in a single transaction could absolve many sins. On 11/6/18 13:51, Ray Bellis wrote: IMHO, any record that doesn't support a service selector isn't doing its job properly. You _have_ to be able to say "if I want this service at this domain, I either prepend this prefix, or lookup this type", otherwise you're just forcing _all_ services to connect to the A and found there. A and should be for connecting to the right _host_, once you've established from the _service_ which host that is. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Any website publishers who use CDNs on the list?
Mr Paul is correct - getdns is the best path for developers. On Thu, Nov 8, 2018 at 1:07 AM Paul Vixie wrote: > > > Tony Finch wrote: > > ... > > > > And even if you can get the recursive server addresses, you should still > > go through the name service switch to deal with names that aren't in the > > DNS. > > agreed. > > > > > The custom DNS stub resolvers that I know about (adns, ldns, libevent) > > reimplement the libc resolver, with their own parsers for > /etc/resolv.conf > > and all the rest. > > dns requests should almost universally go out via the open source > "getdns" API (https://getdnsapi.net/) at this point. if your code uses > one of the above methods, or getXbyY() in any form, please investigate. > > -- > P Vixie > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Any website publishers who use CDNs on the list?
Tony Finch wrote: ... And even if you can get the recursive server addresses, you should still go through the name service switch to deal with names that aren't in the DNS. agreed. The custom DNS stub resolvers that I know about (adns, ldns, libevent) reimplement the libc resolver, with their own parsers for /etc/resolv.conf and all the rest. dns requests should almost universally go out via the open source "getdns" API (https://getdnsapi.net/) at this point. if your code uses one of the above methods, or getXbyY() in any form, please investigate. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Any website publishers who use CDNs on the list?
Vladimír Čunát wrote: > On 11/7/18 4:00 PM, Matthew Pounsett wrote: > > Can you point to a major browser that does *not* implement its own > > resolver already? > > I believe Firefox on Linux uses libc call (in my basically default > setup). There's a problem on Unix that there isn't a way to get the recursive server IP addresses from the libc resolver. In the IPv4 era it was often possible to dig around in the _res struct in a moderately portable way, if the libc resolver was derived from BIND, but that was thoroughly broken by the divergence in IPv6 support. And even if you can get the recursive server addresses, you should still go through the name service switch to deal with names that aren't in the DNS. The custom DNS stub resolvers that I know about (adns, ldns, libevent) reimplement the libc resolver, with their own parsers for /etc/resolv.conf and all the rest. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon: South or southwest 5 to 7, increasing gale 8 at times. Very rough, becoming high. Rain or thundery showers. Moderate or poor.___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Any website publishers who use CDNs on the list?
On 2018-11-05 06:10 -0500, Vladimír Čunát wrote: On 11/2/18 10:41 PM, Evan Hunt wrote: Speaking as a co-author of ANAME, I agree about this. URI, SRV, a proposed new HTTP RRtype, whatever - service lookup is absolutely the correct way to accomplish this goal. However, browser vendors are *not doing that*, and I've given up hope that they ever will. Trying to out-stubborn them has been ineffective. Yes, but I can understand that they're not too inclined - I believe it's not easy to portably get information about such RRTYPEs from the OS resolver, e.g. I can't see a way in POSIX. It seems there is a clear movement from many browsers to use DOH now for DNS matters. At which point they are able to get all DNS data in its full glory without any kind of OS or underlying libraries limitations, and hence could use SRV records like any other clients are doing for other protocols. -- Patrick Mevzek ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Any website publishers who use CDNs on the list?
On Mon, 5 Nov 2018 at 06:11, Vladimír Čunát wrote: > On 11/2/18 10:41 PM, Evan Hunt wrote: > > Speaking as a co-author of ANAME, I agree about this. URI, SRV, a > proposed > > new HTTP RRtype, whatever - service lookup is absolutely the correct way > to > > accomplish this goal. > > > > However, browser vendors are *not doing that*, and I've given up hope > that > > they ever will. Trying to out-stubborn them has been ineffective. > > Yes, but I can understand that they're not too inclined - I believe it's > not easy to portably get information about such RRTYPEs from the OS > resolver, e.g. I can't see a way in POSIX. Most http libraries would > need to deal with this somehow. It doesn't seem realistic to *wait* for > OS implementations or even APIs to improve. Overall it seems quite a > stalemate, I'm afraid, probably without an "ideal" solution within > reasonable timeframe. > Can you point to a major browser that does *not* implement its own resolver already? > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
On 11/6/18 6:28 PM, Tony Finch wrote: But thinking about the discussions from the weekend and yesterday, it occurs to me that it might make sense to simplify ANAME even further: * Make all authoritative processing optional, whether UPDATE style or dynamic on-demand. * The sibling address records have to be provisioned, to act as fallback records for clients/resolvers that don't (yet) do their own ANAME processing. (There may be some automated assistance.) That is indeed what I am aiming at, with the exception that sibling records may be provisioned to act as fallback records (they don't necessarily have to, but the ANAME algorithm may use them if they exist and if resolution of the target address records failed). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
