[DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
Hi everybody, Your input on the initial implementation described below would be most appreciated. I see this as a dns operations issue since it does not describe an on-the wire change, except when we do AXFR perhaps. It is mostly a feature. However, even features could have interoperability issues, and it would be nice if we were aligned. The last forwared paragraph below says Please let us know your thoughts based on the semantics outlined above. Would this work for you? Do you miss anything? Is there a need for multiple ALIAS statements for load balancing? Are we needlessly incompatible with existing implementations? Is there standardization work we could align against? Thanks! Bert - Forwarded message from bert hubert bert.hub...@netherlabs.nl - Date: Sun, 21 Sep 2014 12:54:07 +0200 From: bert hubert bert.hub...@netherlabs.nl To: pdns-us...@mailman.powerdns.com Subject: [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS Hi everybody, Based on strong user interest, we are fast-tracking the implementation of ALIAS/ANAME records, to solve the 'CNAME at apex' problem. Because of the fast-tracking, we need rapid feedback to see if we got it right (see the end of the mail for details). In short, you can CNAME 'www.yourdomain.com' to a CDN or somewhere else, but you can't CNAME 'yourdomain.com', since that breaks DNS. This blogpost by CloudFlare expands on the problem: https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root Today, we implemented ALIAS support as an experimental PowerDNS feature, which allows the following: $ORIGIN example.com. @ IN SOA ns1 ahu 2014091619 7200 3600 1209600 3600 @ IN NS ns1 @ IN NS ns2 www IN CNAME xs.powerdns.com. ns1 IN A 1.2.3.4 ns2 IN A 4.3.2.1 @ IN ALIAS www.powerdns.com. @ IN MX 25 outpost.ds9a.nl. elsewhere IN CNAME @ The branch can be found on https://github.com/PowerDNS/pdns/tree/alias and we should have packages soon. The current semantics for the ALIAS pseudo-record are that they only match if no real record did. So in the case above, an MX query for example.com would return 25 outpost.ds9a.nl. But a query for would return the IPv6 address obtained by following the www.powerdns.com CNAME chain to xs.powerdns.com. This also works for all other record types, btw. Our implementation uses a defined resolver to look up the actually requested record, and adds the data found to the packet built so far. This means that querying 'elsewhere.example.com' will include a CNAME to example.com, which in turn will lead to processing of the ALIAS record. Finally, for TTL, we currently use what the resolver gave us. But perhaps we could use the TTL of the ALIAS record instead, or as a maximum? Or minimum? Please let us know your thoughts based on the semantics outlined above. Would this work for you? Do you miss anything? Is there a need for multiple ALIAS statements for load balancing? Are we needlessly incompatible with existing implementations? Is there standardization work we could align against? Your input is highly welcome! Bert PS: the above is currently not yet supported for DNSSEC domains! -- PowerDNS Website: http://www.powerdns.com/ Contact us by phone on +31-15-7850372 ___ Pdns-users mailing list pdns-us...@mailman.powerdns.com http://mailman.powerdns.com/mailman/listinfo/pdns-users - End forwarded message - ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On Sun, Sep 21, 2014 at 08:13:46AM -0700, Paul Hoffman wrote: - What happens / should happen if the @ IN MX 25 outpost.ds9a.nl. record is not in the zone file and the server gets an MX query for example.com? It proxies that on as an MX query for www.powerdns.com and puts back the answer. So ALIAS is type transparent. PS: the above is currently not yet supported for DNSSEC domains! Can you say (much) more about that aside? Does it mean that the server will fail to load the zone if there is DNSSEC records and ALIAS pseudo-records? Or that the DNSSEC gets broken? Or that the ALIAS gets broken? Or... ? In the current branch, it will load the zone, but neglect to add signatures for the proxied records. In other words, if you do DNSSEC, it will load the zone but make you BOGUS. This is not a fundamental problem as long as we have keys. If you don't have the keys, we can't sign any how. We'll add the signing code shortly, we just haven't typed it in yet. An interesting opening is that we'd be signing potentially unsigned data this way. Potentially, we should check for the AD bit. But first let's see how this idea fits. Bert ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
bert hubert mailto:bert.hub...@netherlabs.nl Sunday, September 21, 2014 4:52 AM ... PS: the above is currently not yet supported for DNSSEC domains! i'd be very interested in a standards-track (interoperable; including DNSSEC support and AXFR/IXFR) version of this feature. my hope is that you will remove out-of-zone capability here, that is, the target of ALIAS should have to be authority data in the same zone. this would simplify the DNSSEC case, but more importantly, it would avoid having authority servers make upstream queries. if you decide to work on this, i'll contribute as at least a reviewer and perhaps (if invited) as an editor. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On 21 September 2014 19:14, bert hubert bert.hub...@netherlabs.nl wrote: On Sun, Sep 21, 2014 at 08:13:46AM -0700, Paul Hoffman wrote: PS: the above is currently not yet supported for DNSSEC domains! Can you say (much) more about that aside? Does it mean that the server An interesting opening is that we'd be signing potentially unsigned data this way. Potentially, we should check for the AD bit. But first let's see how this idea fits. Must validate the response. Otherwise bad actor can just toss in a bogus AD bit! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
Hi, This topic has come up here many times before, and there always seems to be interest. A fielded implementation and Paul's suggestion of an interoperable spec both seem like healthy developments. Suzanne On Sep 21, 2014, at 2:37 PM, Paul Vixie p...@redbarn.org wrote: bert hubert Sunday, September 21, 2014 4:52 AM ... PS: the above is currently not yet supported for DNSSEC domains! i'd be very interested in a standards-track (interoperable; including DNSSEC support and AXFR/IXFR) version of this feature. my hope is that you will remove out-of-zone capability here, that is, the target of ALIAS should have to be authority data in the same zone. this would simplify the DNSSEC case, but more importantly, it would avoid having authority servers make upstream queries. if you decide to work on this, i'll contribute as at least a reviewer and perhaps (if invited) as an editor. -- Paul 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] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On 9/21/14 1:14 PM, Suzanne Woolf wrote: Hi, This topic has come up here many times before, and there always seems to be interest. A fielded implementation and Paul's suggestion of an interoperable spec both seem like healthy developments. As always I stand ready to revive https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit if there is interest. Doug ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 9/21/14 2:04 PM, Doug Barton wrote: | On 9/21/14 1:14 PM, Suzanne Woolf wrote: | Hi, | | This topic has come up here many times before, and there always | seems to be interest. A fielded implementation and Paul's | suggestion of an interoperable spec both seem like healthy | developments. | | As always I stand ready to revive | https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit | if there is interest. I should add that I'll be at the DNS-OARC and ICANN meetings here in LA in October if anyone wants to discuss the issue. Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUHz28AAoJEFzGhvEaGryEe4UH/1jcKEiGJY2mbTdC6AM+nJ0H H/ZrPk4LqDilCTMS5Qn7o6HJ4TzJWqbFhaUdBo/TYlxQ67cna+Imcf4A9qzDEmG6 r5Ux58J9BLoC6PkeOKPVJDG7iqR+bUuLwoCpPmry4y2nL5yV7Q1J8uzpQoByoIHX IoHdTHeQ6TPIUfxkQPNf99FNSumqzlz76xjMXuwZsqMrf1ktbFkgpUDE1ZLWVk1l k6rkdY0q5W/CeCY3hUyWqlX49/su8J4Zeu4OoTlwcstzJirwLFv6GfO1ofzHx8HM 1bTZpSYXO/FV0CWde53G5aDL78IfsFsKwxXPA8s+Ham4KEOK7FrCXdJ/ytyWkv4= =ROL9 -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On Sep 21, 2014, at 2:04 PM, Doug Barton do...@dougbarton.us wrote: On 9/21/14 1:14 PM, Suzanne Woolf wrote: This topic has come up here many times before, And like the joke about the weather... and there always seems to be interest. A fielded implementation There are at least three implementations of ‘alias mechanism for zone apex’ I’m aware of (DNS Made Easy’s ANAME, PowerDNS’s ANAME (same thing?), and CloudFlare’s “CNAME Flattening”). Not sure if they interoperable (or even if there is a need for interoperability). and Paul's suggestion of an interoperable spec both seem like healthy developments. As always I stand ready to revive https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit if there is interest. Given the end of the DNSEXT working group, perhaps there is sufficient interest to have a BOF (Bar, Beach, or otherwise) in Honolulu? Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
David Conrad mailto:d...@virtualized.org Sunday, September 21, 2014 2:10 PM ... There are at least three implementations of 'alias mechanism for zone apex' I'm aware of (DNS Made Easy's ANAME, PowerDNS's ANAME (same thing?), and CloudFlare's CNAME Flattening). Not sure if they interoperable (or even if there is a need for interoperability). from the point of view of many operators and implementers (so, like dns made easy, powerdns, and cloudflare from your example above) there is almost certainly a disadvantage to interoperability and standardization here, that being economic, in that as long as this feature remains incompatible, a single vendor is likely to gain business via lock in. my reason for preferring a standardized way to do this is to make it possible for a registrant to get primary name service from one vendor and secondary name service from one or more others vendors. i don't think it makes sense to question, inside the IETF, whether a vendor-independent interoperable standard is desirable. we can ask questions of the form but is this good engineering? or is this the best way to do it? or even what should the applicability statement be? but since the IETF's stated purpose is to promote interoperable standards, if we want to argue about whether we need an interoperable standard for this widely-used feature, we should move that thread to a non-IETF forum where it would not be a nonsequitur. -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
Paul, On Sep 21, 2014, at 2:23 PM, Paul Vixie p...@redbarn.org wrote: (or even if there is a need for interoperability) i don't think it makes sense to question, inside the IETF, whether a vendor-independent interoperable standard is desirable. Who said anything about desirability? The reason for my parenthetical was that in at least one implementation, the existence of the ‘alias mechanism for zone apex’ is never externally visible, so the question of whether or not that implementation is interoperable would be moot. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On Sun, Sep 21, 2014 at 11:37 AM, Paul Vixie p...@redbarn.org wrote: i'd be very interested in a standards-track (interoperable; including DNSSEC support and AXFR/IXFR) version of this feature. my hope is that you will remove out-of-zone capability here, that is, the target of ALIAS should have to be authority data in the same zone. But then the feature is pointless; you could just include the record directly at the apex if you knew what the value should be. -- Colm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS
On Sep 21, 2014, at 5:10 PM, David Conrad d...@virtualized.org wrote: On Sep 21, 2014, at 2:04 PM, Doug Barton do...@dougbarton.us wrote: On 9/21/14 1:14 PM, Suzanne Woolf wrote: This topic has come up here many times before, And like the joke about the weather... and there always seems to be interest. A fielded implementation There are at least three implementations of ‘alias mechanism for zone apex’ I’m aware of (DNS Made Easy’s ANAME, PowerDNS’s ANAME (same thing?), and CloudFlare’s “CNAME Flattening”). Not sure if they interoperable (or even if there is a need for interoperability). I'm personally fine with a discussion here of whether an interoperable standard is worth the effort, likely to be adopted, etc. Previous versions of this discussion have included use cases where interoperability is part of the value of an alias feature-- for example, if I'm a domain owner who wants both to determine the behavior of an alias in terms of what a client sees and to have flexibility across managed-DNS providers, I want a standard to hold my vendors to. and Paul's suggestion of an interoperable spec both seem like healthy developments. As always I stand ready to revive https://tools.ietf.org/html/draft-barton-clone-dns-labels-fun-profit if there is interest. Given the end of the DNSEXT working group, perhaps there is sufficient interest to have a BOF (Bar, Beach, or otherwise) in Honolulu? As a first cut, the general topic is IMO on charter for the WG, if people seriously want to work on this. I like David's idea of an informal BOF. I'm not sure of logistical constraints for the venue in Honolulu but I'm happy to work on pulling something together. Descriptions of the workings of the known alias features currently in the world would be helpful inputs, along with any specific use cases or problem statements people have in mind. The goal would be to get a preliminary idea of whether there's useful work to be done on the subject within the IETF process, beyond periodic bull sessions on the list, and if so, what's the most effective way to proceed. best, Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
