CNAME records in place of A records
Hi, Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this?
Hi, They will set a dynamic IP address on the server, or use a CDN service. --- Jun Tanaka [dovid@telecurve.com - Fri, 6 Nov 2020 05:07:26 -0500]:
Hi,
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this?
It's not a security thing. We do this with the the resellers who white label our VOIP. CNAMEs allow us to be flexible with our own hosts and infrastructure without having all of our resellers change DNS records. ________________________________ Ray Orsini Chief Executive Officer OIT, LLC 305.967.6756 x1009 | 305.571.6272 ray@oit.co | www.oit.co oit.co/ray How are we doing? We'd love to hear your feedback. https://go.oit.co/review From: NANOG <nanog-bounces+ray=oit.co@nanog.org> on behalf of Dovid Bender <dovid@telecurve.com> Sent: Friday, November 6, 2020 5:07:26 AM To: NANOG <nanog@nanog.org> Subject: CNAME records in place of A records Hi, Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this?
Interesting. We got a few requests at the same time which is what made we wonder. I wanted to make sure that there wasn't something I was missing. On Fri, Nov 6, 2020 at 5:25 AM Ray Orsini <ray@oit.co> wrote:
It's not a security thing. We do this with the the resellers who white label our VOIP. CNAMEs allow us to be flexible with our own hosts and infrastructure without having all of our resellers change DNS records. [image: OIT Website] <https://www.oit.co/> Ray Orsini Chief Executive Officer OIT, LLC *305.967.6756 x1009* <305.967.6756%20x1009> | *305.571.6272* *ray@oit.co* <ray@oit.co> | [image: https://www.oit.co] <https://www.oit.co/> * www.oit.co* <https://www.oit.co/> oit.co/ray [image: Facebook] <https://go.oit.co/facebook> [image: LinkedIn] <https://go.oit.co/linkedin> [image: Twitter] <https://go.oit.co/twitter> [image: YouTube] <https://go.oit.co/youtube>
*How are we doing? We'd love to hear your feedback. https://go.oit.co/review* <https://zoom.us/webinar/register/2015851001337/WN_otbRE8XZSVOitAPS_qZ9Zg> ------------------------------ *From:* NANOG <nanog-bounces+ray=oit.co@nanog.org> on behalf of Dovid Bender <dovid@telecurve.com> *Sent:* Friday, November 6, 2020 5:07:26 AM *To:* NANOG <nanog@nanog.org> *Subject:* CNAME records in place of A records
Hi,
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this?
While the change from A to CNAME itself is probably not based on security considerations, a CNAME pointing to a CDN or similar can result in future security issues, i.e. you want to closely monitor your externally pointing CNAMEs when you get rid of external services: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers On 06.11.20 05:34, Dovid Bender wrote:
Interesting. We got a few requests at the same time which is what made we wonder. I wanted to make sure that there wasn't something I was missing.
On Fri, Nov 6, 2020 at 5:25 AM Ray Orsini <ray@oit.co <mailto:ray@oit.co>> wrote:
It's not a security thing. We do this with the the resellers who white label our VOIP. CNAMEs allow us to be flexible with our own hosts and infrastructure without having all of our resellers change DNS records. OIT Website <https://www.oit.co/> Ray Orsini Chief Executive Officer OIT, LLC
*305.967.6756 x1009* <tel:305.967.6756%20x1009> | *305.571.6272*
*ray@oit.co* <mailto:ray@oit.co> | https://www.oit.co <https://www.oit.co/> * www.oit.co* <https://www.oit.co/>
oit.co/ray <http://oit.co/ray>
Facebook <https://go.oit.co/facebook>
LinkedIn <https://go.oit.co/linkedin>
Twitter <https://go.oit.co/twitter>
YouTube <https://go.oit.co/youtube>
*How are we doing? We'd love to hear your feedback. https://go.oit.co/review* <https://zoom.us/webinar/register/2015851001337/WN_otbRE8XZSVOitAPS_qZ9Zg>
------------------------------------------------------------------------ *From:* NANOG <nanog-bounces+ray=oit.co@nanog.org <mailto:oit.co@nanog.org>> on behalf of Dovid Bender <dovid@telecurve.com <mailto:dovid@telecurve.com>> *Sent:* Friday, November 6, 2020 5:07:26 AM *To:* NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> *Subject:* CNAME records in place of A records Hi,
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this?
Hi, 1. I know y'all know it, but too often I come across customers using CDN Dashboard without 2FA. In my experience this has been the most abused security vector in the cases I saw. 2. Matthias point is extremely valid. I would add: Externally monitoring the signature of the non static objects (html, javascript) returned by the CDN. While you can easily recover from image defacing, having your customers getting their private information (creds, identity, CC) stolen is another ball game. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 11/6/20 11:57 AM, Matthias Luft via NANOG wrote:
While the change from A to CNAME itself is probably not based on security considerations, a CNAME pointing to a CDN or similar can result in future security issues, i.e. you want to closely monitor your externally pointing CNAMEs when you get rid of external services: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers
On 06.11.20 05:34, Dovid Bender wrote:
Interesting. We got a few requests at the same time which is what made we wonder. I wanted to make sure that there wasn't something I was missing.
On Fri, Nov 6, 2020 at 5:25 AM Ray Orsini <ray@oit.co <mailto:ray@oit.co>> wrote:
It's not a security thing. We do this with the the resellers who white label our VOIP. CNAMEs allow us to be flexible with our own hosts and infrastructure without having all of our resellers change DNS records. OIT Website <https://www.oit.co/> Ray Orsini Chief Executive Officer OIT, LLC
*305.967.6756 x1009* <tel:305.967.6756%20x1009> | *305.571.6272*
*ray@oit.co* <mailto:ray@oit.co> | https://www.oit.co <https://www.oit.co/> * www.oit.co* <https://www.oit.co/>
oit.co/ray <http://oit.co/ray>
Facebook <https://go.oit.co/facebook>
LinkedIn <https://go.oit.co/linkedin>
Twitter <https://go.oit.co/twitter>
YouTube <https://go.oit.co/youtube>
*How are we doing? We'd love to hear your feedback. https://go.oit.co/review* <https://zoom.us/webinar/register/2015851001337/WN_otbRE8XZSVOitAPS_qZ9Zg>
------------------------------------------------------------------------ *From:* NANOG <nanog-bounces+ray=oit.co@nanog.org <mailto:oit.co@nanog.org>> on behalf of Dovid Bender <dovid@telecurve.com <mailto:dovid@telecurve.com>> *Sent:* Friday, November 6, 2020 5:07:26 AM *To:* NANOG <nanog@nanog.org <mailto:nanog@nanog.org>> *Subject:* CNAME records in place of A records Hi,
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this?
Are you using A records in a domain you own and pointing at their IPs? I'm not aware of any security vulnerability exploiting A vs CNAME. If they are hosting on a domain they own vs one you own, the use of a CNAME would allow them to change the A record IP without less impact to you, it would also allow them to remove the A record and effectively stop traffic targeting the host via a resolved IP. On Fri, Nov 6, 2020, 4:08 AM Dovid Bender <dovid@telecurve.com> wrote:
Hi,
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this?
----- On Nov 6, 2020, at 2:07 AM, Dovid Bender <dovid@telecurve.com> wrote: Hi,
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this?
Security-wise, you should be good. But make sure you're not attempting to deliver e-mail to such a domain; CNAMEs cannot be used in MX records. Thanks, Sabri
On 11/6/20 2:49 PM, Sabri Berisha wrote:
----- On Nov 6, 2020, at 2:07 AM, Dovid Bender <dovid@telecurve.com> wrote:
Hi,
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this?
Security-wise, you should be good. But make sure you're not attempting to deliver e-mail to such a domain; CNAMEs cannot be used in MX records.
Or NS records, since you mentioned it. :) Doug
On Fri, Nov 06, 2020 at 05:07:26AM -0500, Dovid Bender wrote:
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this?
The closest thing to a *security* issue I can think of is IP agility in the face of DDoS attacks -- most booter-style attacks are dumb as rocks, and null-routing the target IP and moving all the customers on that IP to another one is the easiest solution. However, there are many *other* great reasons to get customers to CNAME onto their SaaS vendors, including: * No need to coordinate routine renumbering events; * IPv6 support; * CAA record (SSL cert issuance) support; and * no doubt a bunch of other reasons I've forgotten for the moment. Basically, if you sign up for a SaaS that uses your own domain and they *don't* give you a CNAME target to point at, I'd be very cautious, because they're either *very* new to the game, or they're probably also operationally deficient in a lot of other areas, too. - Matt
On 11/8/2020 7:10 PM, Matt Palmer wrote:
On Fri, Nov 06, 2020 at 05:07:26AM -0500, Dovid Bender wrote:
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this? The closest thing to a *security* issue I can think of is IP agility in the face of DDoS attacks -- most booter-style attacks are dumb as rocks, and null-routing the target IP and moving all the customers on that IP to another one is the easiest solution.
However, there are many *other* great reasons to get customers to CNAME onto their SaaS vendors, including:
* No need to coordinate routine renumbering events; * IPv6 support; * CAA record (SSL cert issuance) support; and * no doubt a bunch of other reasons I've forgotten for the moment.
Basically, if you sign up for a SaaS that uses your own domain and they *don't* give you a CNAME target to point at, I'd be very cautious, because they're either *very* new to the game, or they're probably also operationally deficient in a lot of other areas, too.
- Matt
except - don't forget that the root of a domain (that domain without "www." or any other label) - cannot have a CNAME as the "A" record - fwiw... -- Rob McEwen, invaluement
On 9 Nov 2020, at 12:01, Rob McEwen <rob@invaluement.com> wrote:
On 11/8/2020 7:10 PM, Matt Palmer wrote:
On Fri, Nov 06, 2020 at 05:07:26AM -0500, Dovid Bender wrote:
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this? The closest thing to a *security* issue I can think of is IP agility in the face of DDoS attacks -- most booter-style attacks are dumb as rocks, and null-routing the target IP and moving all the customers on that IP to another one is the easiest solution.
However, there are many *other* great reasons to get customers to CNAME onto their SaaS vendors, including:
* No need to coordinate routine renumbering events; * IPv6 support; * CAA record (SSL cert issuance) support; and * no doubt a bunch of other reasons I've forgotten for the moment.
Basically, if you sign up for a SaaS that uses your own domain and they *don't* give you a CNAME target to point at, I'd be very cautious, because they're either *very* new to the game, or they're probably also operationally deficient in a lot of other areas, too.
- Matt
except - don't forget that the root of a domain (that domain without "www.” or any other label) - cannot have a CNAME as the "A" record - fwiw…
Which is why there are HTTPS and SVCB records coming and SRV exists. You don’t need CNAME, you need indirection. Indirection does require a small amount of client support.
-- Rob McEwen, invaluement
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Sun, Nov 08, 2020 at 08:01:12PM -0500, Rob McEwen wrote:
except - don't forget that the root of a domain (that domain without "www." or any other label) - cannot have a CNAME as the "A" record - fwiw...
Yes. I didn't think that was something that needed to be explained on NANOG, though. - Matt
On 9 Nov 2020, at 16:35, Matt Palmer <mpalmer@hezmatt.org> wrote:
On Sun, Nov 08, 2020 at 08:01:12PM -0500, Rob McEwen wrote:
except - don't forget that the root of a domain (that domain without "www." or any other label) - cannot have a CNAME as the "A" record - fwiw...
Yes. I didn't think that was something that needed to be explained on NANOG, though.
Given the number of ISPs (and others) that ask ISC to support CNAME at the APEX to whom we have to politely say: “No. It is not permitted by this part of RFC 1034.” <quoted text> It’s well worth reiterating.
- Matt
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Den 09-11-2020 kl. 01:10 skrev Matt Palmer:
On Fri, Nov 06, 2020 at 05:07:26AM -0500, Dovid Bender wrote:
Sorry if this is a bit OT. Recently several different vendors (in completely different fields) where they white label for us asked us to remove A records that we have going to them and replace them with CNAME records. Is there anything *going around* in the security aranea that has caused this? The closest thing to a *security* issue I can think of is IP agility in the face of DDoS attacks -- most booter-style attacks are dumb as rocks, and null-routing the target IP and moving all the customers on that IP to another one is the easiest solution.
DNSSEC? A lot of public sector/government stuff, at least around here, should have had DNSSEC enabled already. e-Boks, as being the stuff that all state/municipalities sends electronic communication through (unless you're excluded from "electronic mail"): -> https://dnssec-analyzer.verisignlabs.com/www.e-boks.dk Sure, there DNSSEC on the actual domain name, but the CNAME *destination* does not. Or for another examples: -> https://dnssec-analyzer.verisignlabs.com/www.nsa.gov There is also DNSSEC enabled on this domain too, but again, the CNAME *destination* does not. Wasn't there once a phrase saying something like "a chain is no stronger than its weakest link"? What if the SaaS provider is actually the weakest link?
However, there are many *other* great reasons to get customers to CNAME onto their SaaS vendors, including:
* No need to coordinate routine renumbering events; * IPv6 support; * CAA record (SSL cert issuance) support; and * no doubt a bunch of other reasons I've forgotten for the moment.
Renumbering and CAA record indeed two potential good reasons for using the CNAME, as they wouldn't require clients to perform any manual actions on their end. However, I haven't seen anything pointing the direction that "IPv6 support" and "CNAME" would have anything to do with each other. In the end, using A/AAAA directly is the matter of knowing what you do, and if you really do, IPv6 support with or without the CNAME wouldn't really matter.
Basically, if you sign up for a SaaS that uses your own domain and they *don't* give you a CNAME target to point at, I'd be very cautious, because they're either *very* new to the game, or they're probably also operationally deficient in a lot of other areas, too.
Providing the CNAME, or even requiring the use of it, could also mean that you should indeed take a close look, at the areas where the SaaS provider giving you them become "operationally deficient" too. Hasn't DNS often been criticized of being one common thing that often make websites slow? -> https://github.com/PowerDNS/pdns/issues/6874 Real life example from one of the many "SaaS" vendors (in the example, CDN providers) out there, providing the CNAME, and - obviously depending on how you look at it, may operate certain things in a very silly way. My truth? There is too many things out there, making it impossible to blindly believe that SaaS vendors would always be right, or that their decisions are always the best. Your truth? I believe you need to figure out that one yourself. Just my two cents. -- Med venlig hilsen / Kind regards, Arne Jensen
participants (12)
-
Alain Hebert -
Arne Jensen -
Doug Barton -
Dovid Bender -
Jun Tanaka -
Kevin East -
Mark Andrews -
Matt Palmer -
Matthias Luft -
Ray Orsini -
Rob McEwen -
Sabri Berisha