Re: [DNSOP] Minimum viable ANAME
On Wed, 19 Sep 2018, Tony Finch wrote: If I look up foo and it has an ANAME to bar, which of these do I get back? ; ANSWER SECTION foo. A 1.2.3.4 ; ADDITIONAL SECTION foo. ANAME bar. bar. A 1.2.3.4 The model is that this is a replacement for manually copying address records, with added hints to resolvers that they might want to re-do the copying in order to get geo-optimized answers or other complicated tricks. Exactly. And some dns server addonn can go look through the zone files and find ANAME records, and do the query/updating via a cron job and reload or something. This is a simle solution that works. With this model, signing only happens where it currently happens. Good. Although if you want to return bar's IP if it is different from foo's IP and for resolvers that don't understand ANAME, you have to synthesize these, but at least then it is nor worse then DNS64 with respect to DNSSEC. PS: I still think fixing apex CNAME is a better way to go. There are still DNS servers out there running on 1990s semantics, so I don’t think CNAME can be fixed any time soon - much of my practical annoyance comes from people asking for CNAME and MX and this combination is doom on a stick because it involves crazy MTA DNS message handlers, not just DNS servers. My guess at deployment timelines is: I agree, CNAME is tainted. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minimum viable ANAME
> On 19 Sep 2018, at 21:14, John Levine wrote: > If I look up foo and it has an ANAME to bar, which of these do I get > back? ; ANSWER SECTION foo. A 1.2.3.4 ; ADDITIONAL SECTION foo. ANAME bar. bar. A 1.2.3.4 The model is that this is a replacement for manually copying address records, with added hints to resolvers that they might want to re-do the copying in order to get geo-optimized answers or other complicated tricks. > The second is a lot more like what CNAME does, and also avoids having > to sign on the fly. With this model, signing only happens where it currently happens. > PS: I still think fixing apex CNAME is a better way to go. There are still DNS servers out there running on 1990s semantics, so I don’t think CNAME can be fixed any time soon - much of my practical annoyance comes from people asking for CNAME and MX and this combination is doom on a stick because it involves crazy MTA DNS message handlers, not just DNS servers. My guess at deployment timelines is: * minimal ANAME can be deployed unilaterally on the provisioning side 20 years ago and similar features are widely available (you are ahead of me on this one, John!); if resolvers implement it there will be useful amounts of deployed support within a few years * browser-friendly SRV replacement: two years to standardization; another two years watching caniuse before we can maybe think about not copying A records around; even more years before it becomes as portable on the provisioning side as ANAME is now * fix CNAME, at least 10 years Tony. -- f.anthony.n.finchhttp://dotat.at ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minimum viable ANAME
In article you write: >Authoritative servers / zone transfers >-- > >No special new behaviour. > > >Additional section processing >- > >This applies to auth and rec servers. In response to an A / / >ANAME query, include any sibling A / / ANAME records, and any >ANAME target A / records. When DO=1, include DNSSEC proofs of >nonexistence for missing RRsets. If I look up foo and it has an ANAME to bar, which of these do I get back? foo. ANAME bar. foo. A 1.2.3.4 foo. ANAME bar. bar. A 1.2.3.4 The second is a lot more like what CNAME does, and also avoids having to sign on the fly. There is of course the question of whether caches and stubs will treat them like cname results or like cache poisoning. R's, John PS: I still think fixing apex CNAME is a better way to go. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minimum viable ANAME
Paul Wouters wrote: > > The design goals of a solution in this space should be: > > - Fully supports DNSSEC > - Does not require AUTH server changes other then supporting a new > RRTYPE presentation / wire format and/or serving a new RRTYPE as > Additional Data. > - All optimization work is done on the resolver. If this includes > 'rewriting' A/ records, DNSSEC proofs MUST be included for > stub clients doing validation. My suggestion does all of that. https://www.ietf.org/mail-archive/web/dnsop/current/msg24206.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger, Fisher: Southwest 6 to gale 8, occasionally severe gale 9 at first, decreasing 4 or 5 later. Rough or very rough, becoming high for a time in northwest Fisher, becoming slight or moderate in Tyne and Dogger. Rain or showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minimum viable ANAME
On Wed, 19 Sep 2018, Paul Vixie wrote: Tony Finch wrote: Anthony Eden wrote: FWIW, there's still always https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ I get the impression that a lot of the objection to the current ANAME draft is that it specifies that auth servers do ANAME target lookups and record substitution; your draft says the same thing. I think those objections are reasonable, but I don't think the problem lookups are particularly important (or even helpful). +1. 4. Security Considerations To function properly with DNSSEC-aware resolvers, authoritative name servers MUST sign the materialized records produced by the ALIAS resolution. Implementors MAY either materialize A and records offline and sign the resulting records at that time, or sign the resulting materialized records at request time. This is not a proper Security Consideration section. Please see https://tools.ietf.org/html/rfc3552 What is described here is a fundamental flaw in this proposal. That fact is even more clear by the MAY in that section, which basically says "you can address this security issue or not, whatever" A mechanism could be designed that is more generally usable. Forcing a authoritative servers to do DNS lookups is asking for trouble. Some deployments combine auth+recursive and such a server now needs a working resolv.conf, and one that cannot point to itself. Clearly this is going to break stuff. We have known for decades that combining authoritative plus recursive was a bad idea, yet here it is again glueing these two parts together so the auth server needs resolving code. The place to do anything is on the resolver, the authoritative server should just serve blobs. Synthesizing (here called "materialising" ?) records is awful. It does not work with offline DNSSEC signers, and if we want to solve this properly, we can do so easilly with a solution that does not have this limitation. The design goals of a solution in this space should be: - Fully supports DNSSEC - Does not require AUTH server changes other then supporting a new RRTYPE presentation / wire format and/or serving a new RRTYPE as Additional Data. - All optimization work is done on the resolver. If this includes 'rewriting' A/ records, DNSSEC proofs MUST be included for stub clients doing validation. for example, why not serve an ALIAS record as additional data to A/ queries? Then resolvers that dont support this are as bad of as now. Resolvers supporting this, will pick up the ALIAS, resolve it, put those A/ records in cache, and serve any clients asking for these A/ with the A/, ALIAS and target A/ records. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minimum viable ANAME
Tony Finch wrote: Anthony Eden wrote: FWIW, there's still always https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ I get the impression that a lot of the objection to the current ANAME draft is that it specifies that auth servers do ANAME target lookups and record substitution; your draft says the same thing. I think those objections are reasonable, but I don't think the problem lookups are particularly important (or even helpful). +1. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minimum viable ANAME
Anthony Eden wrote: > FWIW, there's still always > https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ I get the impression that a lot of the objection to the current ANAME draft is that it specifies that auth servers do ANAME target lookups and record substitution; your draft says the same thing. I think those objections are reasonable, but I don't think the problem lookups are particularly important (or even helpful). Tony. -- f.anthony.n.finchhttp://dotat.at/ Northwest Fitzroy: Southwesterly 5 to 7, occasionally gale 8 in far northwest. Moderate or rough, occasionally very rough in far northwest. Rain. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minimum viable ANAME
FWIW, there's still always https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/ (also available at https://github.com/aeden/alias-rr-type) which can be revived if there is interest. Sincerely, Anthony Eden On Wed, Sep 19, 2018 at 9:56 AM Tony Finch wrote: > I think there's still a need to standardize ANAME, to provide at least > some level of zone file portability between the various existing > proprietary versions of this feature. And to provide something usable > by zone publisters on a much shorter timescale than a nsa SRV-alike. > > So here's a sketch of a reduced ANAME: > > > Primary servers / zone provisioning > --- > > For each ANAME record, poll the target address records periodically > (according to the relevant TTLs). When the target addresses don't > match the owner's addresses, UPDATE the zone so they match. > > > Authoritative servers / zone transfers > -- > > No special new behaviour. > > > Additional section processing > - > > This applies to auth and rec servers. In response to an A / / > ANAME query, include any sibling A / / ANAME records, and any > ANAME target A / records. When DO=1, include DNSSEC proofs of > nonexistence for missing RRsets. > > As usual for additional section processing, you don't have to include > records that aren't available, so (for instance) auth servers don't > have to include out-of-zone data in the response. > > > Recursive servers > - > > When responding to a query with DO=0 or when the ANAME owner's zone is > unsigned, a recursive server can substitute the target addresses in > place of the owner's addresses. > > > Rationale > - > > The primary server behaviour is an "as if" description: that's what > it looks like for the purpose of interop with secondary servers and > zone files. > > There doesn't seem to be any point in making secondary servers do > anything: their view of the target address records will be just as > wrong or right as the primary server's. Zone publishers that want > clever auth servers will use some kind of multi-headed CDN distributed > stunt DNS server, and we aren't going to standardize that. > > Putting cleverness in resolvers compensates for the lack of cleverness > in secondary servers. > > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Hebrides: Cyclonic 5 to 7 becoming west or southwest 7 to severe gale 9. > Rough > or very rough becoming very rough or high. Showers. Good, occasionally > poor. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- DNSimple.com http://dnsimple.com/ Twitter: @dnsimple ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Minimum viable ANAME
I think there's still a need to standardize ANAME, to provide at least some level of zone file portability between the various existing proprietary versions of this feature. And to provide something usable by zone publisters on a much shorter timescale than a nsa SRV-alike. So here's a sketch of a reduced ANAME: Primary servers / zone provisioning --- For each ANAME record, poll the target address records periodically (according to the relevant TTLs). When the target addresses don't match the owner's addresses, UPDATE the zone so they match. Authoritative servers / zone transfers -- No special new behaviour. Additional section processing - This applies to auth and rec servers. In response to an A / / ANAME query, include any sibling A / / ANAME records, and any ANAME target A / records. When DO=1, include DNSSEC proofs of nonexistence for missing RRsets. As usual for additional section processing, you don't have to include records that aren't available, so (for instance) auth servers don't have to include out-of-zone data in the response. Recursive servers - When responding to a query with DO=0 or when the ANAME owner's zone is unsigned, a recursive server can substitute the target addresses in place of the owner's addresses. Rationale - The primary server behaviour is an "as if" description: that's what it looks like for the purpose of interop with secondary servers and zone files. There doesn't seem to be any point in making secondary servers do anything: their view of the target address records will be just as wrong or right as the primary server's. Zone publishers that want clever auth servers will use some kind of multi-headed CDN distributed stunt DNS server, and we aren't going to standardize that. Putting cleverness in resolvers compensates for the lack of cleverness in secondary servers. Tony. -- f.anthony.n.finchhttp://dotat.at/ Hebrides: Cyclonic 5 to 7 becoming west or southwest 7 to severe gale 9. Rough or very rough becoming very rough or high. Showers. Good, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
On Wed, Sep 19, 2018 at 09:48:18AM +0200, Petr Špaček wrote: > > > On 19/09/2018 09:31, Mukund Sivaraman wrote: > > On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote: > >> On 18/09/2018 22:02, JW wrote: > >>> > >>> Original message > >>> From: Mark Andrews > >>> > I would also expect a relatively large client population using SRV > records > given the rate Firefox and Chrome browsers are upgraded. SRV lookups > work for lots ofother protocols. SRV records also make it through > firewalls and IDS today. > > >>> > >>> Hi Mark, > >>> > >>> I agree SRV is the obvious choice for a greenfield protocol but there is > >>> HTTP code sprinkled /everywhere/. I can't imagine all those forgotten > >>> scripts, lonely IOT devices, and troubleshooting guides are going to be > >>> as easy to solve as updating chrome and firefox. > >>> > >>> Whatever the solution, I feel it should be as transparent to the client > >>> as possible. CNAME would fit this bill but the negative impact is > >>> largely unknown. > >> > >> TL;DR: Experiments with CNAME @ apex showed that it is not going to work > >> if the domain has e.g. MX records for e-mail. > >> > >> Ondrej Sury describes his experimental results in presentation here: > >> https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/dns_hackathon-presentation.pdf > > > > Aren't these results with current state of implementations? A cached > > CNAME is expected to be matched against future type queries when > > following RFC 1034/1035 behavior. > > > > A change in behavior where resolvers expect that CNAME (as a fallback > > type) will co-exist with other types will work properly. > > Well, I started this thread because I naively thought that we can get > away with *current* behavior which kind of works because of various > non-standard workarounds. Experiment above proved me wrong so this seems > like dead-end to me - it will have similar upgrade problem as any other > new mechanism. That's fair, but it would have lower implementation complexity which is my concern. I much prefer SRV (that Mark's been pushing for several years now) that is simpler and elegant. A relaxed fallback-CNAME resolver implementation would not break the DNS, so IMO that proposal should still be carried through so some X years later most deployed resolvers will be capable of handling it. Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
On 19/09/2018 09:31, Mukund Sivaraman wrote: > On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote: >> On 18/09/2018 22:02, JW wrote: >>> >>> Original message >>> From: Mark Andrews >>> I would also expect a relatively large client population using SRV records given the rate Firefox and Chrome browsers are upgraded. SRV lookups work for lots ofother protocols. SRV records also make it through firewalls and IDS today. >>> >>> Hi Mark, >>> >>> I agree SRV is the obvious choice for a greenfield protocol but there is >>> HTTP code sprinkled /everywhere/. I can't imagine all those forgotten >>> scripts, lonely IOT devices, and troubleshooting guides are going to be >>> as easy to solve as updating chrome and firefox. >>> >>> Whatever the solution, I feel it should be as transparent to the client >>> as possible. CNAME would fit this bill but the negative impact is >>> largely unknown. >> >> TL;DR: Experiments with CNAME @ apex showed that it is not going to work >> if the domain has e.g. MX records for e-mail. >> >> Ondrej Sury describes his experimental results in presentation here: >> https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/dns_hackathon-presentation.pdf > > Aren't these results with current state of implementations? A cached > CNAME is expected to be matched against future type queries when > following RFC 1034/1035 behavior. > > A change in behavior where resolvers expect that CNAME (as a fallback > type) will co-exist with other types will work properly. Well, I started this thread because I naively thought that we can get away with *current* behavior which kind of works because of various non-standard workarounds. Experiment above proved me wrong so this seems like dead-end to me - it will have similar upgrade problem as any other new mechanism. -- Petr Špaček @ CZ.NIC ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
> On 19 Sep 2018, at 5:26 pm, Stephane Bortzmeyer wrote: > > On Wed, Sep 19, 2018 at 07:24:25AM +1000, > Mark Andrews wrote > a message of 38 lines which said: > >> As for scripts, you upgrade the tools those scripts use: >> curl(libcurl), wget, fetch for SH. File::Fetch for perl. Similar >> for the other scripting languages. Very few applications actually >> make socket calls directly for http. > > I hope it is true but I'm not so sure. Any hard data somewhere? My > purely anecdotal evidence is that I've seen "applications actually > make socket calls directly for http", one reason probably being it is > widely teached in schools. And the number of such applications that connect to names that are served by CDN and are also at zone apexes such that CNAME doesn’t work is ~0%. Such applications need to be upgraded. I’m sure CDN’s could give Agent string counts for sites where they are doing DNS hacks for apex names so we could see actual data. It will be in their logs. I’m sure there are employees of such companies reading this. > HTTP/2 is a good thing here since it is much harder to do it yourself, > so people will rely on libraries :-) -- 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] abandoning ANAME and standardizing CNAME at apex
On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote: > On 18/09/2018 22:02, JW wrote: > > > > Original message > > From: Mark Andrews > > > >> I would also expect a relatively large client population using SRV records > >> given the rate Firefox and Chrome browsers are upgraded. SRV lookups > >> work for lots ofother protocols. SRV records also make it through > >> firewalls and IDS today. > >> > > > > Hi Mark, > > > > I agree SRV is the obvious choice for a greenfield protocol but there is > > HTTP code sprinkled /everywhere/. I can't imagine all those forgotten > > scripts, lonely IOT devices, and troubleshooting guides are going to be > > as easy to solve as updating chrome and firefox. > > > > Whatever the solution, I feel it should be as transparent to the client > > as possible. CNAME would fit this bill but the negative impact is > > largely unknown. > > TL;DR: Experiments with CNAME @ apex showed that it is not going to work > if the domain has e.g. MX records for e-mail. > > Ondrej Sury describes his experimental results in presentation here: > https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/dns_hackathon-presentation.pdf Aren't these results with current state of implementations? A cached CNAME is expected to be matched against future type queries when following RFC 1034/1035 behavior. A change in behavior where resolvers expect that CNAME (as a fallback type) will co-exist with other types will work properly. Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
On Wed, Sep 19, 2018 at 07:24:25AM +1000, Mark Andrews wrote a message of 38 lines which said: > As for scripts, you upgrade the tools those scripts use: > curl(libcurl), wget, fetch for SH. File::Fetch for perl. Similar > for the other scripting languages. Very few applications actually > make socket calls directly for http. I hope it is true but I'm not so sure. Any hard data somewhere? My purely anecdotal evidence is that I've seen "applications actually make socket calls directly for http", one reason probably being it is widely teached in schools. HTTP/2 is a good thing here since it is much harder to do it yourself, so people will rely on libraries :-) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex
On 18/09/2018 22:02, JW wrote: > > Original message > From: Mark Andrews > >> I would also expect a relatively large client population using SRV records >> given the rate Firefox and Chrome browsers are upgraded. SRV lookups >> work for lots ofother protocols. SRV records also make it through >> firewalls and IDS today. >> > > Hi Mark, > > I agree SRV is the obvious choice for a greenfield protocol but there is > HTTP code sprinkled /everywhere/. I can't imagine all those forgotten > scripts, lonely IOT devices, and troubleshooting guides are going to be > as easy to solve as updating chrome and firefox. > > Whatever the solution, I feel it should be as transparent to the client > as possible. CNAME would fit this bill but the negative impact is > largely unknown. TL;DR: Experiments with CNAME @ apex showed that it is not going to work if the domain has e.g. MX records for e-mail. Ondrej Sury describes his experimental results in presentation here: https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/dns_hackathon-presentation.pdf Petr Špaček @ CZ.NIC > Perhaps defining a set of default protocols for SRV where it could > simulate a CNAME-like response if https/http SRV records are found? > > /John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
