Forums

Confused about CNAME

I have purchased a domain www.beacatworks.net. When I go to this URL, I get a blank page. Here is what I have done so far: 1. Created my app on dscapuano.pythonanywhere.com 2. Added a CNAME record at the site where I purchased my domain name pointing to dscapuano.pythonanywhere.com. 3. domain name is registered as beancatworks.net.
4. This points to a subdomain - www.beancatworks.net 5. my CNAME record is under the subdomain pointing to dscapuano.pythonanywhere.com.

Does not work, and I am confused about some items in the forums. For example, I have two entries in my Web panel: dscapuano.pythonanywhere.com and www.beancatworks.net.
Currently I have both of them pointing to my app at ~/beancatworks....

What am I doing wrong?

Thanks, dc

That all sounds correct. When did you make the change? I think it may just be that the DNS changes need time to propagate -- from here, I see both beancatworks.net and www.beancatworks.net having an A record pointing to 107.23.45.102, which appears to be a server in Amazon EC2 but not one of ours.

$ dig beancatworks.net

; <<>> DiG 9.7.3 <<>> beancatworks.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10176
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;beancatworks.net.              IN      A

;; ANSWER SECTION:
beancatworks.net.       86400   IN      A       107.23.45.102

;; Query time: 72 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Mon Feb 18 18:01:05 2013
;; MSG SIZE  rcvd: 50

$ dig www.beancatworks.net

; <<>> DiG 9.7.3 <<>> www.beancatworks.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54922
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.beancatworks.net.          IN      A

;; ANSWER SECTION:
www.beancatworks.net.   79813   IN      A       107.23.45.102

;; Query time: 0 msec
;; SERVER: 172.16.0.23#53(172.16.0.23)
;; WHEN: Mon Feb 18 18:01:16 2013
;; MSG SIZE  rcvd: 54

Still doesn't appear to have been updated, and the TTL is only 24 hours so I wonder if something funny's happened.

If your DNS provider allows it, it might be worth cranking down the TTL to something like 1800 just while you're getting things working. This isn't being a particularly good netizen long-term as it increases load on DNS servers as they have to re-check your records more frequently, but it can make it less tedious to track down issues.

Just don't forget to put it back up when you're done (as I just realised I did exactly that on my domain - oops).

I don't know a TTL from a hound dog.
Anyhow, the registrar does seem to have anything on their web page for domain names about this.

I have been playing with this for a while now. Seems I changed the A record to 108.175.3.229, but that is the IP of the registrar.
Then I played some more and now, according to the registrars page, I have no A record, only a CNAME record. the CNAME is dscapuano.pythonanywhere.com. DIG does not show a CNAME, but I don't know if it should.
Perhaps I have to wait some more?

Less confused, but frustrated.

Assuming you are using an automated registrar, then any changes you make should be reflected, as viewed in your account with them, pretty much immediately. But viewing the changes from your account with them is different from what you'll see publicly until a queried DNS server does a new look-up to acquire the changes. And that new look-up delay is determined by the TTL (scroll down to the DNS records section) that you set on your authoritative DNS servers. TTL is just seconds the record is to be considered good for. So for instance if you have a TTL of 300 set, a querying DNS server should cache the record for 5 minutes before expiring the record and asking the authoritative server for the record again. These TTL's are often set for a time in days and thus you won't see changes until the caches expire and new requests are made.

HTH

Hey dsc,

Maybe you could post a screenshot of the registrars configuration section through to our support email?

Finally got this to work. Here's the rub: 1. This particular registrar (1&1) does not require a subdomain to cover the "www" part. They automatically change "abc.com" to "www.abc.com".
2. I added the CNAME to "abc.com", and deleted the subdomain "www.abc.com" since I don't need it anymore. 3. This still didn't work and I was getting the old "forbidden" screen. 4. That's when I added a "forward" to pythonanywhere.com. 5. That worked! I don't know why it needed that forward AND the CNAME.

It's a shame that all of these registrars have different ways of doing this. What a pain...

I'm afraid I still can't see any evidence of a CNAME in your DNS records - it looks like www.beancatworks.net still goes to the registrar's IP (via an A record), but they're responding to HTTP requests with a 302 Found response which redirects to your PA site. So, it doesn't sound like you need both CNAME and redirect set up - it just sounds like the CNAME hasn't been added and the redirect is why your website is working.

This probably isn't a big deal since it's now working, but in your shoes I'd try and get to the bottom of why the CNAME doesn't seem to be taking effect. Adding CNAMEs is one of the most basic features of a registrar and really should be more straightforward than it sounds.

Since the redirect solution works for now, however, perhaps it's worth waiting a few days to see whether the DNS irons itself out without further intervention.

Oh dear. This isn't so much an official PythonAnywhere response but rather a rant resulting from a delicious birthday dinner, but it is depressing to see how hard it is for everyone to get DNS setting sorted. @dc, you're in good company. We've had nightmares ourselves and I'm in the middle of a lengthy discussion about this stuff with a respected author of a well-known Python library, and if he has trouble, how are the rest of us to work it out?

I think the problem is that DNS is complicated, but the normal use cases for it are simple - and DNS providers try to provide an interface that handles every case, no matter how tricky, but unfortunately that makes the simple cases hard.

We did a straw poll around the office the other day to see if there was a domain registrar we could recommend for the interface they offered for their bundled DNS, and not one of us was willing to definitively say "these guys have it worked out". We, as a company, use joker.com, and I also use them personally, but an unbiased observer would undoubtedly attribute my comfort with them to either extended usage or Stockholm Syndrome.

So one thing we have considered is operating our own DNS service. But (a) it's hardly core to our mission of making Python easily usable online, and (b) the people who've implemented the cruddy interfaces we've all encountered are presumably not stupid, so perhaps it's just really hard to get right, especially when people start asking for something semi-obscure like an SPF record or Google Webmaster Tools verification text record

I guess, ultimately, we're not sure what we should do.

@dc we'll have a proper look tomorrow and see if we can make any solid suggestions for your specific setup (Cartroo's analysis sounds right) but if you could send us screenshots of the pages where you set it up, we might be able to help better.

@giles: Happy Birthday!!

I think the issue is the usual problem with user interfaces, in that they often try to be all things to all people. DNS is complicated, and many people don't fully understand its full subtleties (myself most certainly included). Part of the problem is that the DNS protocol itself is designed to be generic and extensible - essentially it's just a distributed database. The uses to which it's put, however, have many more constraints upon it, and that's where the complexity arrives.

I don't believe one interface can successfully appeal to people who don't really understand DNS and just want a few A records and CNAMEs, and also to a power user who wants to create arbitrary TXT and SRV records. Therefore, I think providers should either pick one target market or the other, or offer two different interfaces - so you start simple, but can switch to "advanced mode" at your own risk.

The "simple mode" would be a "wizard" interface, where you select from a few limited options, and the user could be prompted by plain language questions asking what they're trying to do. This would have the advantage that adding obscure records for SPF or Google domain validation or similar could be written in as specific "macros" which do the right thing. The downside is, of course, the lack of flexibility.

The "advanced mode" would basically be "here's a zone file, knock yourself out" - perhaps wrapped up in a pretty GUI to prevent basic syntax mistakes, but essentially raw access to records.

As compromises go the GoDaddy interface isn't too bad. It shows a page with a set of tables, each of which represents a type of record - it supports A, AAAA, CNAME, MX, TXT, SRV and NS records, which should be enough for all but the most advanced users. There are a few special links for specific tasks (for example, the TXT section has an "Add SPF record" link) which is somewhat like a "wizard" interface, but only has limited options.

In terms of PA offering a DNS management service, I'd say it has good potential to make life easy for users with simple requirements - offering a totally generic DNS service is quite a lot of UI work, though (although there are already plenty of providers making good business out of offering a very cut-down DNS interface). I think the "simple user" interface is probably the best fit with PAs currently offerings, as advanced users are hard to cater for and aren't going to find it tricky to set up CNAMEs and the like.

I agree it's not core functionality, but it might be a reasonable value-add for paid accounts which streamlines people use of the bread and butter PA services.

OTOH, it would mean dealing with BIND, which is never a pleasant prospect (unless you want to go with djbdns or something).

@giles: Belated Happy Birthday!

Thanks, guys :-)

@Cartroo -- I think you're right, a simple interface for common tasks and then a full-on interface for power users would make sense. Heigh ho, another thing for the list...

where are the basic pythonanywhere instructions for doing this?

On the help page, but quoting them here:

Every domain registrar has a slightly different interface. So it is hard to give a precise answer. But in general you need to create a CNAME record for "www" that points to your-username.pythonanywhere.com.