Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
On Fri, Nov 9, 2018 at 12:09 PM Paul Vixie wrote:
> Brian Dickson wrote:
> > Paul Vixie wrote:
>
i don't love the dnssec implications of this, including proof of
> nonwildcard.
>
I'm not 100% sure, but I think the generic DNSSEC response handling already
covers this.
If the response does not include the QTYPE, the NSEC/NSEC3 record proving
non-existent is required (already).
That the types are "type-specific thing" vs "wildcard-type thing", doesn't
even require special handling.
> it's pretty not-practical at this point to add a feature whose first
> real utility will come after the last resolver understands and
> implements it.
>
I think that overstates the deployment issue; in 1990, there weren't any
public resolvers that could be used (at least not that I'm aware of, or
maybe they were but got closed down later.)
Currently, the feature becomes usable when some fraction of the
{standard,open} resolvers have deployed support, and/or enough of the
clients (browsers) provide support, or both, plus some significant
support/deployment in authorities.
The efficiencies/optimizations on queries are something that might be
signaled via EDNS (either an OPT or a flag), regarding support for the new
slew of types.
Clients could have multiple resolvers configured, and prefer ones that
support the new types (as signaled by EDNS).
Those resolvers that provide support, and resolve the RDATA names to A/
and return those (from cache or proactively), minimize the need for
parallel queries and the corresponding query load.
Clients can learn (or be configured, or whatever) about resolver support
and tune their query logic based on that support.
That would put some degree of competitive pressure on resolver operators,
as well as providing a signal on client-side support. Client queries with
EDNS signal, to resolvers that do not support, still provide meaningful
uptake signal level to resolver operators.
The remaining two elements are authority server (software/operator)
support, and end-user (registrant) use. Competitive pressure in the market
place is beneficial once the first entrant deploys. EDNS signaling can help
there too, even when no response would have been provided (due to lack of
actual RRtype(s) at owner name).
I'm optimistic that there's a clean, scalable, flag-day-less, incremental
way forward.
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
Brian Dickson wrote: Paul Vixie wrote: ... i regret not adding ANY as an RR type (not just a Q type) back when the DNS was small and i supported 90% of it. what we actually needed is a wildcard on types so that if there's no more-specific type you get thatone, which would have an rdata of the target name, but act like PTR (which the DNS requester has to follow) rather than like CNAME (which the recursive has to follow.) ... Funny anecdote: I was actually going to add a suggestion for a "fall-back catch-all" aka wildcard RR type, to the first message in this new thread, but was concerned about muddying the waters. I'll just point out the semantics of having both service-specific, and wildcard, service-RRtypes, and their poster-child use cases. Semantics: 1. Client queries for service-specific RRtype 2. If present, the response is returned, optionally with A/ (i.e. if resolver is upgraded) 3. If absent, but a wildcard service RRtype is present, the wildcard is returned, optionally with A/ (ditto) 4. If neither is present, noerror/nodata response, possibly with A/ of original owner (i.e. if resolver is upgraded) i don't love the dnssec implications of this, including proof of nonwildcard. Typical instructions to domain owner: * If all your services are on some third party at the same FQDN, put in a wildcard pointing there * If most of your services are on one third party at the same FQDN, put in a wildcard pointing there, with any other type-specific services which are on other third parties, added with pointers to each of them * If you are wanting to ensure only responses for specific types, use those types and do not use the wildcard type. The logic required on authority servers is exactly analogous to wildcard names. Look up the specific thing first, and if absent, look up the wildcard. Return what you find. The logic required on resolvers is similarly analogous, including the logic for following the RHS returned with any such record type: rewrite the query and rerun resolution (just like CNAMEs). it's pretty not-practical at this point to add a feature whose first real utility will come after the last resolver understands and implements it. ... Minimizes level of effort on nearly-trivial zones; gives control for zones operated by folks who want control; minimizes total minimum record count (provably) in all situations. Easy to add more types without ANY logic-flow changes to any implementations (assuming RDATA is just an FQDN), beyond adding new types to the enum set of "things like this". Are we converging on consensus, possibly? no. these are the weeds. the time to have done this was 1990. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fundamental ANAME problems
I have finally reviewed the latest draft directly, and like the overall direction but have a small number of issues (however, the issues theirselves are somewhat fundamental). They broadly break down into concerns about zone transfers and TTL stretching, and ultimately seem to stem from a disagreement with my position that the proper conception of ANAME sibling address records is as fallback data to be used in cases where ANAME target resolution fails or is never attempted. First, I am troubled by the requirement that ANAME forces the zone into a dynamic zone. That a primary master would dynamically replace sibling records on its own, update the zone serial, and then propagate that dynamic data via zone transfer overrides user conception about the state of a zone, induces undesirable churn between authoritative nameservers, /and/ stretches the TTLs of ANAME targets on downstream servers by the amount of time between successive updates. These consequences are just too much for what is supposed to be a low-impact feature. Anyone willing to opt-in to them should be updating the ANAME sibling address records on their own, not forcing authoritative server implementations to choose between taking on that dirty work or being labeled noncompliant. Second, and relatedly, I think the TTLs of replacement records established for non-transfer responses are too high. Respecting the TTL of every record in a chain that starts with the ANAME requires the TTL of final replacement records to be no higher than the minimum TTL encountered over the chain, potentially /reduced/ nondeterministically to mitigate query bunching. I would therefore add language encouraging resolvers synthesizing those records to engage in best-effort determination of original TTLs by (e.g., by directly querying authoritative servers and refreshing at 50% remaining), but *requiring* them to decrement TTLs of records for which they are not authoritative. And finally, back on the question of what ANAME sibling address records actually represent, I think that NXDOMAIN and NODATA results should be treated as errors for the purposes of ANAME sibling replacement. This position can be justified on both practical and principled grounds—replacing functional records with an empty RRSet is undesirable for DNS users (or at least the sample of them that are Oracle+Dyn customers), and could inappropriately stretch the maximum specified ANAME sibling TTL (on the ANAME record itself) to the SOA MINIMUM value (which is doubly bad, because it results in extended caching of the /least/ valuable state). And adding insult to injury, resolvers in general will not even have the SOA, and will need to perform more lookups in order to issue a proper negative response of their own. Let's please just eliminate all of that by specifying that ANAME processing can never replace something with nothing. P.S. There is a typographical error in Appendix D; "RRGIG" should be "RRSIG". P.P.S. I think it has been discussed before, but this document should also introduce and use a new "Address RTYPE" registry or subregistry, rather than forever constraining ANAME exclusively to A and . On 11/2/18 17:00, Richard Gibson wrote: I haven't reviewed the full draft yet, but am happy to see some people echoing my sentiments from earlier versions [1]. I particularly wanted to agree with some statements from Bob Harold. On 11/2/18 15:20, Bob Harold wrote: Another option to give users is a non-updating fallback A record, that could point to a web redirect. That saves all the hassle of updates. YES! This means a slightly worse fallback-only experience for users behind ANAME-ignorant resolvers that query against ANAME-ignorant authoritatives (the introduction of ANAME awareness to /either/ component allowing an opportunity to provide better address records by chasing the ANAME target), but provides a dramatic reduction in the amount of necessary XFR traffic. And even more importantly, it forces TTL stretching to be an explicit decision on the part of those administrators who choose to perform manual target resolution and update their zones to use them as fallback records (as they would do now to approximate ANAME anyway), rather than an inherent and enduring aspect of the functionality. Treating ANAME-sibling address records as fallback data also supports better behavior for dealing with negative results from resolving ANAME targets (NODATA, NXDOMAIN, signature verification failure, response timeout, etc.)—serve the fallbacks. My preference would be a *NAME record that specifies which record types it applies to. So one could delegate A and at apex to a web provider, MX to a mail provider, etc. That would also be valuable at non-apex names. But I am happy to support ANAME as part of the solution. I agree on both counts (arbitrary type-specificity and deferment to a later date). [1]:
Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
On 09/11/2018 09:30, Paul Vixie wrote: i regret not adding ANY as an RR type (not just a Q type) back when the DNS was small and i supported 90% of it. what we actually needed is a wildcard on types so that if there's no more-specific type you get that one, which would have an rdata of the target name, but act like PTR (which the DNS requester has to follow) rather than like CNAME (which the recursive has to follow.) interesting... :) i am loath to create per-service record types. that's why SRV. if you really want every client of a service to query for something other than /A, can you try to fix what's wrong with SRV regarding wildcards, but avoid a new type code for every new thing like MX and HTTP as they come along in the decades to follow? Creating per-service record types is the IAB's preferred option (per RFC 5507). Is fixing wildcards for SRV even possible without a major forklift upgrade to the DNS? also, does SSH count as a service? what about FTP? Gopher? RSync? NNTP? IMAP(S)? My line of thinking is that in this context a service is "a domain-wide facility that's exposed to third parties where it is strongly preferred that the third party use the bare domain name directly because that domain name is used in end-user identities or to identify the endpoint". For me, that would include: SMTP, HTTP(s), SIP, XMPP So, with respect to your list: SSH - no, it's for managing a specific host FTP - maybe, but is still well served by the "ftp." convention Gopher - yes, if it still has any use? Rsync - maybe - it's most often used for host-to-host transfers, but arguably a domain could offer file dist via rsync::, although again the "rsync." prefix would usually suffice. NNTP - probably not, end users see the hostname in their config but "news." etc is fine. IMAP - I believe there's already mechanisms for discovering IMAP servers via SRV, although AIUI it's usually a one-off configuration-time search, not per-session. it may not be too late to think architectural thoughts like "what will the internet engineering community think, 50 years from now, that we should have done for them?" I hope that's what I'm trying to do. It would be real bad if some alternative to "the web" comes along in 10 years time but we can't differentiate it in the DNS because too many A and records are assumed (absent a service identifier) to be dedicated to "the web". i don't think you mean "actual". anycasted addresses act like host addresses in all ways (answering UDP, answering TCP SYN, answering ICMP) but are not "actual" hosts. i think i know what you _mean_ here and if so i agree with that. but 1.1.1.1 answers both HTTPS and DNS, and would surely get an and A in your model, but is not a "host", and its DNS owner would not be a "hostname". perhaps you mean "effective host" which could be real or virtual? Yes, indeed, that is a more accurate definition. regards, 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
Ray Bellis wrote: On 09/11/2018 07:14, Tony Finch wrote: But remember: the goal is to make the DNS easier to use for people who don’t know about the restrictions on CNAMEs. I'd say the goal is to make the DNS *possible* to use for people who don't know about the restrictions on CNAMEs. i regret not adding ANY as an RR type (not just a Q type) back when the DNS was small and i supported 90% of it. what we actually needed is a wildcard on types so that if there's no more-specific type you get that one, which would have an rdata of the target name, but act like PTR (which the DNS requester has to follow) rather than like CNAME (which the recursive has to follow.) I concede that ANAME perhaps makes that easier than HTTP does, but it does so at the expense of significant complexity in authority servers by still requiring A and lookups to be somehow "magic", and doesn't fix the architectural problem of lack of a service identifier. i am loath to create per-service record types. that's why SRV. if you really want every client of a service to query for something other than /A, can you try to fix what's wrong with SRV regarding wildcards, but avoid a new type code for every new thing like MX and HTTP as they come along in the decades to follow? also, does SSH count as a service? what about FTP? Gopher? RSync? NNTP? IMAP(S)? it may not be too late to think architectural thoughts like "what will the internet engineering community think, 50 years from now, that we should have done for them?" My long-term goal would be to never have an A or record appear in the DNS other than at the owner name of an actual hostname. i don't think you mean "actual". anycasted addresses act like host addresses in all ways (answering UDP, answering TCP SYN, answering ICMP) but are not "actual" hosts. i think i know what you _mean_ here and if so i agree with that. but 1.1.1.1 answers both HTTPS and DNS, and would surely get an and A in your model, but is not a "host", and its DNS owner would not be a "hostname". perhaps you mean "effective host" which could be real or virtual? -- P Vixie ___ 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 09/11/2018 07:14, Tony Finch wrote: But remember: the goal is to make the DNS easier to use for people who don’t know about the restrictions on CNAMEs. I'd say the goal is to make the DNS *possible* to use for people who don't know about the restrictions on CNAMEs. I concede that ANAME perhaps makes that easier than HTTP does, but it does so at the expense of significant complexity in authority servers by still requiring A and lookups to be somehow "magic", and doesn't fix the architectural problem of lack of a service identifier. My long-term goal would be to never have an A or record appear in the DNS other than at the owner name of an actual hostname. 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
> On 8 Nov 2018, at 20:13, Mark Andrews wrote: > >> On 9 Nov 2018, at 5:27 am, Tony Finch wrote: >> >> HTTP RRs risk adding a third option, where the web provider has to have >> documentation asking whether the DNS provider supports HTTP RRs and if so >> the site admin needs both these addresses and this hostname. > > The providers that use CNAME add HTTP to that description and say to add HTTP > at the zone apexes or anywhere else another record is published at the same > name. [ I think you mean “web providers” here, i.e., not us. ] But remember: the goal is to make the DNS easier to use for people who don’t know about the restrictions on CNAMEs. Any time we say, “oh, those other people need to to explain things at greater length to make our stuff easier to use”, we are not solving the problem. The end goal is to simplify documentation used by non-experts that deals with 3rd party web providers and 3rd party DNS providers. Tony. -- f.anthony.n.finchhttp://dotat.at ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Further ANAME minimization /\ Ray convergence
It should be pointed out that the Autodiscover subsystem of Microsoft Office uses SRV in a very *degenerate* way. It ignores all fields other than target. In my testing, I believe I also proved that it doesn't fail over if presented multiple SRV RRs in a response. So, basically it's a one-to-one mapping between a (fixed-prefix + domain-specific-suffix) name and a hostname, something that syntactically could have been accomplished more simply using, say, PTR (which, contrary to common misconception, is *not* limited to reverse lookups). Personally, I would exclude Autodiscover from any list of "things which use SRV", since its use is not consistent with the spirit or the letter of the SRV RFCs. - Kevin On Wed, Nov 7, 2018 at 4:46 PM Michael J. Sheldon wrote: > > > 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 > ___ 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 9 Nov 2018, at 5:27 am, Tony Finch wrote: > > Ray Bellis wrote: >> 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). > > The transition mechanism is really important if zone publishers are going > to use HTTP records. It needs to be automated and invisible to the web > site admin. If you require people to provide both a target hostname and > the corresponding addresses, you are making it too hard. You aren't > removing the friction caused by the restrictions on CNAMEs. > > At the moment the options for setting up 3rd party hosting are: > > * Just use address records. Lots of places prefer this because it >always works, at the cost of less flexible static server setup. > > * Use a CNAME for www and address records for the bare domain. Maybe the >address records refer to a server that is more limited in some way >than the CNAME target (no geoIP, just a redirector, ...) > > HTTP RRs risk adding a third option, where the web provider has to have > documentation asking whether the DNS provider supports HTTP RRs and if so > the site admin needs both these addresses and this hostname. And the > addresses can't refer to a redirector, so this thord option opens a new > trap for the unwary. The providers that use CNAME add HTTP to that description and say to add HTTP at the zone apexes or anywhere else another record is published at the same name. > What I would like is to eliminate the wrong choices on the DNS provider > side of things, so that the web site admin can provide a target hostname > which will work on any name, just like they can with address records. Providers that synthesis A and records using proprietary methods just add the HTTP record as a complementary record. Providers that use CNAME at the apex set the CNAME TTL to 0 and add HTTP along side the CNAME. This will allow them to be able to see which clients support HTTP if they wish. HTTP lookups needs to be made *before* A and lookups get the HTTP records into the resolver’s cache. > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Fitzroy, Sole: Cyclonic 5 to 7, becoming southerly or southwesterly 7 to > severe gale 9. Very rough or high. Rain or showers. Good, occasionally poor. > > ___ > 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
Ray Bellis wrote: > 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). The transition mechanism is really important if zone publishers are going to use HTTP records. It needs to be automated and invisible to the web site admin. If you require people to provide both a target hostname and the corresponding addresses, you are making it too hard. You aren't removing the friction caused by the restrictions on CNAMEs. At the moment the options for setting up 3rd party hosting are: * Just use address records. Lots of places prefer this because it always works, at the cost of less flexible static server setup. * Use a CNAME for www and address records for the bare domain. Maybe the address records refer to a server that is more limited in some way than the CNAME target (no geoIP, just a redirector, ...) HTTP RRs risk adding a third option, where the web provider has to have documentation asking whether the DNS provider supports HTTP RRs and if so the site admin needs both these addresses and this hostname. And the addresses can't refer to a redirector, so this thord option opens a new trap for the unwary. What I would like is to eliminate the wrong choices on the DNS provider side of things, so that the web site admin can provide a target hostname which will work on any name, just like they can with address records. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fitzroy, Sole: Cyclonic 5 to 7, becoming southerly or southwesterly 7 to severe gale 9. Very rough or high. Rain or showers. Good, occasionally poor. ___ 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
Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME Date: Thu, Nov 08, 2018 at 09:30:44AM +0700 Quoting Brian Dickson (brian.peter.dick...@gmail.com): > I'm going to start a clean, related thread, to discuss a bunch of > questions, that I think can help with the ongoing threads. So, if we just invent something that can be whacked into a TXT record, all will be fine? -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE SA0XLR+46 705 989668 On the road, ZIPPY is a pinhead without a purpose, but never without a POINT. signature.asc Description: PGP signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
