Re: CNAME records in place of A records
> On 9 Nov 2020, at 16:35, Matt Palmer 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.” It’s well worth reiterating. > - Matt > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: CNAME records in place of A records
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
Re: CNAME records in place of A records
> On 9 Nov 2020, at 12:01, Rob McEwen 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: ma...@isc.org
Re: CNAME records in place of A records
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
Re: CNAME records in place of A records
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
Re: Disney+ Geolocation (again)
Did you ask what the correct avenue was? I'm assuming you did. I'm also assuming they were of no additional help. - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Seth Mattinen" To: Nanog@nanog.org Sent: Sunday, November 8, 2020 11:20:17 AM Subject: Re: Disney+ Geolocation (again) On 11/8/20 8:58 AM, Mike Hammett wrote: > Ugh, they used to. > > I can't stand these consumer-focused organizations that are > irresponsible to the greater operator community. > > I was told to go to help.disneyplus.com to resolve this, which just gives you the "you're on a VPN" page if you type in "error 73". I called anyway, and as I assumed they can't help me as an ISP calling in. (I did test to confirm with a friend's account but I'm not the account holder.) Even then, that doesn't help the overall "yeah our service works with every major streaming service *except* Disney+, so if you use them you'll have to call to convince them you're not using a VPN." This isn't even a new network, I've had 74.118.152.0/21 allocated to me since 2005. Why people insist on reinventing the geolocation wheel is beyond me. ~Seth
Re: Disney+ Geolocation (again)
On 11/8/20 8:58 AM, Mike Hammett wrote: Ugh, they used to. I can't stand these consumer-focused organizations that are irresponsible to the greater operator community. I was told to go to help.disneyplus.com to resolve this, which just gives you the "you're on a VPN" page if you type in "error 73". I called anyway, and as I assumed they can't help me as an ISP calling in. (I did test to confirm with a friend's account but I'm not the account holder.) Even then, that doesn't help the overall "yeah our service works with every major streaming service *except* Disney+, so if you use them you'll have to call to convince them you're not using a VPN." This isn't even a new network, I've had 74.118.152.0/21 allocated to me since 2005. Why people insist on reinventing the geolocation wheel is beyond me. ~Seth
Re: Disney+ Geolocation (again)
Ugh, they used to. I can't stand these consumer-focused organizations that are irresponsible to the greater operator community. - Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP - Original Message - From: "Seth Mattinen" To: Nanog@nanog.org Sent: Sunday, November 8, 2020 9:24:11 AM Subject: Disney+ Geolocation (again) People can't watch Disney+. Looked at old emails, read them. Checked every geolocation site for my netblocks (which return ok). Emailed to netad...@disneystreaming.com They responded with "We do not service these requests via this email". Now what? Anyone have a secret contact that can actually help? ~Seth
Disney+ Geolocation (again)
People can't watch Disney+. Looked at old emails, read them. Checked every geolocation site for my netblocks (which return ok). Emailed to netad...@disneystreaming.com They responded with "We do not service these requests via this email". Now what? Anyone have a secret contact that can actually help? ~Seth
