Simple question about zone and CNAME

Lawrence K. Chen, P.Eng. lkchen at ksu.edu
Sat Apr 6 04:46:23 UTC 2013



----- Original Message -----
> 
> On Apr 5, 2013, at 3:48 PM, WBrown at e1b.org wrote:
> 
> >>> Incidentally, we have just been asked for an A record for
> >>> cam.ac.uk to
> >>> duplicate www.cam.ac.uk because, and I quote, "all the publicity
> > material
> >>> sent out by the nominator [for an award for the web site] gave
> >>> the URL
> >>> as http://cam.ac.uk/ and this has been retweeted around".
> >> 
> >> Yes, sadly I've lost that technical battle with marketing several
> >> places
> >> now.
> > 
> > And then there's theses folks:
> > 
> > http://no-www.org/
> > 
> 
> Oh wow!
> 
> Gee, thanks for that…
> 
> Sad panda,
> W
> 
> 

Wow...didn't know that site existed....  I've thought for a long time that all websites have to start with 'www.' was pretty antiquated.  And, such most of the sites I have set up don't use are that way.  Especially the domain I got for my url shortener....

OTOH, our old webmaster is now working in marketing....when it was mandated that all DNS requests would automatically have the www. version created or vice versa, depending on what was requested....also they automatically get both ksu.edu and k-state.edu forms, even if they only asked for one.  And, it just happens automatically with their request and isn't indicated that it happened....

So, up until a couple years ago...our webmail address had always been, and only "webmail.ksu.edu".  But, under the new direction....it has to work as "webmail.ksu.edu", "www.webmail.ksu.edu", "webmail.k-state.edu", "www.webmail.k-state.edu". and SSL certs to work for all those.

And, then somebody mentioned that m. was the prefix for mobile websites.  So, now we support "m.webmail" x2, "www.m.webmail" x2, and "m.www.webmail" x2...and ssl for all.  in fact the whole....everything has to have multiple names is causing problems, because now we need ssl certs to work for multiple names....  because people aren't typing just the name and getting redirected to the one https:// form that exists.  They'll https to one of the variants and complain they got a cert error and demand it be fixed.  Rather than use the one form that has always been used to get to the site, and the one form that is published.

Of course, sometimes the getting both ksu.edu and k-state.edu form is automatic, because their subdomain is an include file that is included in both files.  Though there are others, where the information had been entered by hand into both zones.  And, occasionally typos have gone undetected for years, because they never asked for the k-state.edu form...and it never worked because of a typo...until suddenly it does....

Of course, there are also places in the files where the ksu.edu form has a different IP address than the k-state.edu form (by one)....

The use of multiname certs to address this problem has only been a recent thing here, and it doesn't seem to be widely known.

Though apparently, my hosting provider doesn't support these....requiring me to buy unique IPs for each cert....unless I happen to buy my cert from them...in which case theirs will work both with and without the 'www.'  Though I have 3 domains pointed to the same site....

Also it seems that if I signup for cloudflare and move my NS to them, I can use just my domain name.  Except that my hosting provider has partnered with them, so that NS can stay with them....but then I can no longer use just my domain name (because they'll then use the CNAME method that cloudflare offers....which can't be done for the apex of my domain....so I can't use cloudflare.

Though DoS'ng my site was getting dropped of sharply a few days ago.  My site was seeing about 30x more traffic than usual.

I meant to see if there was anything piling on things at work...but guess I was busy enough to look, and nobody has asked me about the systems I take care of.

In November our authoritative-only nameservers were getting DoS'd....they saw 1 gigabit of traffic coming in for each of the IPs of our nameservers.  Only thing I could see in the logs was the nameserver couldn't reply to queries during the times.

I knew our pipe was big, but didn't realize it was big enough to have a sustained and solid 1 gigabit of junk at the my nameservers.

Hopefully they'll continue to exempt my DNS vlan (which has both authoritative-only nameservers and the recursive caching servers) from the packet inspection device that they say might've helped.  Because it was hard enough trying to explain the DNS interference it was causing. (and does cause to DNS servers elsewhere on campus) P2P isn't only thing on the Internet that are large UDP packets that look encrypted (which is the main purpose of the device -- like, they only update the signature file on the device when they see an uptick in DMCA notices 8-)

The main thing was there would be messages for managed-keys-zone and then after a day or so, bind would stop resolving queries completely.  Restarting it, would make it work again until it stops again....and so on.  So, I decided the workaround was to write an eventhandler for our nagios system to restart bind whenever it detected that it had stopped working.  Though it would recover fast enough, so often the event handler fires....nagios escalates and pages everybody....and a few seconds later its working, so it pages everybody that it has recovered.   So, basically, DNS downtimes got shorter...but pages got more frequent and more annoying....  Finally my manager asked what was up...and he made the exemption happen. 8-)

Since the only times that I've had nagios pages for DNS outages, have been prolonged Internet outages and problems in upgrading to the latest version of bind.   For the recent upgrade from 9.9.2-P1 to 9.9.2-P2, only had pages for one server out of the 20 that I upgrade each time.

L


More information about the bind-users mailing list