DNS zones, RFCs &/or best practices

[feren]

Dear Lazyweb,

I'm trying to find any form of documentation available to (in)validate a behavior on the Internet that involves DNS and lazy, web browsing users. It is not uncommon for DNS administrators to put something akin to the following in their zone files for a particular domain (assume best practices followed for SOA including proper $ORIGIN statements, etc):

                        IN      A       207.36.86.138
www                     IN      A       207.36.86.138

This has the effect of allowing somebody to type "http://black-panther.us/" into their web browser and get to my web page because an A RR (207.36.86.138) is returned that would be the same as if they typed in "http://www.black-panther.us/". As I said above, this is primarily done to allow lazy web browsers such as myself to type only the domain in the URL bar and get taken to the website. I could go so far as to say that this is now expected behavior on the public Internet. However, just because something is expected doesn't mean it's correct (the opposite is far too often the case, where broken behavior has come to be expected or even accepted as correct). Hence, I ask you, the all-knowing web: where is this behavior documented as being acceptable in the relevant RFCs or DNS best practices papers? So far I have reviewed a slew of RFCs, including 1912, 2181, and 1033, and I have yet to see this described as something that is actually approved and correct. RFC 2219 somewhat references the behavior I'm describing in the second paragraph of section 1 ("Rationale"), but is using it to outline a case for the remainder of the RFC. I've found no allusion to this in the "Best Practices" documentation I've scanned during my scrounging, either.

So is this just a common practice by lazy administrators like myself to keep lazy users like myself from kvetching, or is this actually documented somewhere as being appropriate?

I find it both amusing and, simultaneously, frustrating that I can tell you which RFC indicates an underscore cannot be used in a name (RFC 952) but I'm drawing a complete blank on this.

Comments

[frysco.livejournal.com]

To my knowledge, there isn't an RFC or IETF draft that specifies this as being required or any kind of standard. I'm not sure that I'd consider it a 'best practice' either.

I really think that this is something that is brought on by media outlets and people just dropping the 'www' from names when giving them out, becuase 'double-you, double-you, double-you' is a PITA to say when trying to get words out quickly - like in a radio commercial spot.

RFC 2219 also mentions that some web browsers try first, then www. if they get an NXDOMAIN. That's a reasonably acceptable way to do it, as long as they report back (should www. not be found either) that their initial requested URL wasn't found.

And you're right - just because something is 'expected' as being right behavior on the Internet, doesn't mean that it's correct or valid in terms of RFCs and IETF drafts. Of course, this is a common ploy used by some software vendors (eg, microsoft) that through sheer flooding of the marketplace due to marketshare dominance, they can bully the standards groups into making something that's expected into a standard.

[feren.livejournal.com]

I'm not terribly surprised that you're the first one to respond, Frysco. Hell, you'll probably be the only one. ;)

Okay, you have confirmed for me that there is nothing out there to say this is required or standardized (read: approved) behavior. I'll infer from your commentary that there is, reciprocally, no RFC or best practices document that says or even hints this should not be done. Dammit.

I'm okay with web browsers providing a "Value Add" for lazy users (in this case by prefacing with the "www") but I don't like to see kludges infiltrating protocols. Sometimes I hate the mentality (with regard to RFCs) of "that which is not explicitly forbidden is implicitly allowed." By using $ORIGIN, you're kluding a way of providing the label for the entry

    IN   A     207.36.86.138

While, after inserting $ORIGIN, it's a technically accurate record that fulfills the requirement listed under section 5 of RFC2181 ("Each DNS Resource Record (RR) has a label, class, type, and data,") it really violates the spirit of the specification on some fundamental levels.

[frysco.livejournal.com]

Actually, there's nothing wrong with that at all.

There is no difference to putting

 IN A 207.36.86.138

than there is to putting

black-panther.us. IN A 207.36.86.138

After all, this is already common usage for specifying the NS and MX RRtypes that are associated with a particular zone apex. There is nothing at all that denies putting an A RRtype for the zone apex either, or any other type of valid RRtype.

Wherein I show my ignorance...

[feren.livejournal.com]

I agree one hundred percent, this is done for MX and NS RRs all the time. However, I figured that was because you were describing/pointing at/choose-your-term a machine that provides that particular service for the (sub)domain itself. In the case of putting an A record for the domain itself, it strikes me that its not because the machine is providing a service to the domain but because you don't want to discourage a user who is too lazy/stupid/whatever to actually type in the proper URL.

[yotogi.livejournal.com]

Okay, then, educate me; unless you have something like a forums.black-panther.us or a suck-my.black-panther.us that users should be seeing first, why is this a problem for your domain?

[feren.livejournal.com]

[suck-my.black-panther.us ]

You've been reading through my zone file again, haven't you.

But seriously -- I have no "other" site that users should see as opposed to www.black-panther.us. Allowing the domain to resolve to the webserver isn't a "problem," it's simply a technical quirk I've been engaged in some discussion over. It struck me as an inelegance so I wanted some verification as to the legitimacy of the practice.

[yotogi.livejournal.com]

Honestly, I was just trying to throw a "big black dick" joke in there but I couldn't think of a way to cram it succinctly into a URL.

[feren.livejournal.com]

My domain lends itself to these sort of euphemisms, doesn't it?

[yotogi.livejournal.com]

Comedy, these days, is just easier for me than technical acumen. My networking skills are pretty rusty.

[points.livejournal.com]

Isn't this more of a use for a CNAME, though?

[feren.livejournal.com]

CNAME is one of the most hotly contested "features" of something as simple as DNS I've ever seen. For the most part I just try to stay out of the battle since nobody can really agree. Some folks love them and use them at any given opportunity, others abhor them and won't use them at all. Admittedly, there are cases where CNAMEs are good and times when they are bad. The biggest argument against them is that when they're widely deployed they can make a loop or needlessly obfuscate a zone, leading to more significant problems like additional records, or accidentally pointing non-tolerant records (MX or NS for example) at one.

My personal take on them is that they can create a performance penalty (if you have www.black-panther.us as a CNAME to panther.black-panther.us, you have to do a lookup for www and then for panther after you get the CNAME back) and should be used sparingly -- but can be useful when you've got a lot of records in a zone that all point back to one place (ex: a machine that's doing virtual hosting for a number of subdomains... like feren.black-panther.us, points.black-panther.us, etc and they all go to "www") and you know the "main" machine regularly changes provider space, resulting in an IP change. You make all the subs a CNAME to the main machine, then you only have to change one A record -- all the rest will naturally follow. That makes maintaining the zone file so much easier that I can see the attraction of it.

It's also really handy when you want to "follow" a machine outside of your domain. I know a lot of folks who use DynDNS for tracking their workstation at home on a cablemodem, then use a CNAME on their vanity domain to point to that DynDNS name.

But given the precautions on using CNAME I don't think this is a case where it would be applied.

[angelwind.livejournal.com]

Since I put my webmail on a subdomain, I tend to let the domain handlers sort it out, So my domain has a www.domain and a *.domain so that subdomains at least point to the right IP, and then let apache figure out what it needs to serve.