DNS WTF



  • I'm pretty certain an RFC is crying somewhere... Whatever happened to the nice '301 Moved Permanently'?

     ;; QUESTION SECTION:
    ;caldeck.com.                   IN      SOA

    ;; ANSWER SECTION:
    caldeck.com.            85702   IN      CNAME   dpweb.vendaregroup.com.



  • Um, looks potentially WTFy. Little explanation to the non DNS experts would be nice to fully appreciate the flavor though.



  • Humm. As far as I can tell, this is totally valid (and no RFC is crying out loud ;-)).

    Besides taking a little longer to look up (if dpweb.vendaregroup.com isn't served by the same nameservers as caldeck.com, which could be considered a little WTFy), I wouldn't see a WTF here... Especially as it makes changing RR-data for more than one domain (which might also be aliased like this) so much easier.



  • [quote user="PSWorx"]Um, looks potentially WTFy. Little explanation to the non DNS experts would be nice to fully appreciate the flavor though.
    [/quote]

    Absolutely, I have no idea of what the problem is here. 



  • [quote user="PSWorx"]Um, looks potentially WTFy. Little explanation to the non DNS experts would be nice to fully appreciate the flavor though.
    [/quote]

    A CNAME in DNS is an alias for another DNS name. So in the example, "caldeck.com" is given the alias "dpweb.vendaregroup.com". That means that people who use that DNS server to lookup "caldeck.com" will be given a new DNS name to look up, "dpweb.vendaregroup.com".

    It's not a WTF, IMO. First, it's perfectly valid DNS. Likely caldeck.com got bought out by vendaregroup.com and wish all requests for caldeck.com to be forwarded to vendaregroup.com. The original poster is saying, "why can't the caldeck.com server stay up, but send HTTP 301 (permanently moved) response headers to the browser?" The answer, of course, is that likely the caldeck.com server was retasked. Or dismantled. Maybe sold. I dunno.

    But I have to say "non-WTF" on this one.



  • The only WTF here is the suggestion to use a 301 redirect. Nothing is wrong with this DNS setup. This is the only correct way to configure a hostname for remote web hosting. vendaregroup.com is the hosting company that runs the server on which the caldeck.com site is hosted. You could use an A record, but that requires you to keep it in sync with the hosting company - this sort of thing is why CNAME exists. (There are valid objections to the way in which CNAME is implemented, but that's outside the scope of this topic)

    If you used a 301 redirect, then (a) you would have to run a web server yourself, and (b) it wouldn't bloody work at all. Instead of seeing caldeck.com in your web browser, you would see dpweb.vendaregroup.com, which (you will note if you click on the links) is a totally different site. (They are, however, both fake sites designed to generate ad revenue - looks like one of the major domain squatting companies)



  • Wouldn't you usually use CNAME in place of A records, not in place of SOA (Start Of Authority)?

    ; <<>> DiG 9.3.2 <<>> soa caldeck.com
    ;; global options: printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7266
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;caldeck.com. IN SOA

    ;; ANSWER SECTION:
    caldeck.com. 86400 IN CNAME dpweb.vendaregroup.com.

    ;; AUTHORITY SECTION:
    vendaregroup.com. 1800 IN SOA ns1.vendaregroup.com. hostmaster.vendaregroup.com. 2006080706 900 1800 1209600 14400

    ;; Query time: 364 msec
    ;; SERVER: 213.xxx.xx.xx#53(213.xxx.xx.xx)
    ;; WHEN: Fri Dec 22 10:44:45 2006
    ;; MSG SIZE rcvd: 113



  • If a record is a CNAME, there's absolutely no possibility that it have any other record or record type attached (like an SOA, in this case).

    So, either you get a CNAME and only a CNAME (because the record name caldeck.com isn't canonical), which means that the SOA-record for caldeck.com is the same as the SOA-record of dpweb.vendaregroup.com, pretty much as asking for any other record type means it's the same as the record of that type for the canonical name, or you get a "true" SOA-record, which means that caldeck.com can't be CNAME'd anymore.

    So, this behaviour is totally expected.


Log in to reply