This is a “you learn better when you write it down” sort of post. Never actually got into DNS record types – as a lot of things I’ve missed, there was just no need and I wasn’t curious enough. Although curiosity without regular application of that knowledge is rather pointless – “you soon will forget the tune that you play”, if you play it just once or twice.
That said, I’m gonna be needing this knowledge soon (I presume), so I thought I better do me a hint page (a “crib sheet”, as the dictionary suggests).
A record – “Address”, a connection of a name to an IP address like, for instance, “example.com. IN A 184.108.40.206” – where IN is for the Internet, i.e. “Internet Address…” Wildcards could be used for “all subdomains”
AAAA – “four times the size”, A-address for IPV6 addresses (see a note on IPV6 below)
CNAME – Canonical Name, specifies an alias for existing A record, like “subdomain.example.com CNAME example.com“. Useful to make sure you only have one IP address in A record, and others rely on A name – so if IP changes, it’s one place you have to change it at. Note: do not use CNAME aliases in MX records.
MX – Mail eXchange, specifies which server serves zone’s mail exchange purposes – like, for instance, “mydomain.com IN MX 0 mydomain.com.“; final dot is important, 0 is for priority: ther could be multiple MX records for the zone, and they processed in priority order (the lower the number the higher the priority). Same-priority records are processes in random order. Right-side name should be an A record.
PTR – specify pointer for a reverse DNS lookup, required to validate hostname identity in some cases – “220.127.116.11.in-addr.arpa. IN PTR name.net” (note that IP of name.net is 18.104.22.168)
NS – Name Server, specifies a (list of) authoritative DNS server for the domain, for instance: “example.com. IN NS ns1.live.secure.com“. This should be specified at authoritative server as well.
SOA – State Of Authority, an important record with zone’s name server details – “authoritative information about an Internet domain, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone“. Example: mydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. ( 2004123001 ; Serial number 86000 ; Refresh rate in seconds 7200 ; Update Retry in seconds 3600000 ; Expiry in seconds 600 ; minimum in seconds )
SRV – an option to specify a server for a Service, like “_http._tcp.example.com. IN SRV 0 5 80 www.example.com.” – here’s the service name (_http), priority (0), weight (5) for services with the same priority, and port (80) for the service.
NAPTR – recent and complex regexp-based name resolution I’m not keen to into.
There’s MUCH MORE of this crap, hope I won’t need to ever dig that deep
Haven’t updated this place for a while – need to get back on this new habit, really. Well, at least
I hope I do so in upcoming year (should be a big one anyways). So a quick update just before I tear the old calendar down from the wall (and I pity that, it’s the Futurama genuine 2013 calendar) – some records that date back as far as late October, some points I squeezed from that SECR conference I attended back then. These are quick and without any verbose explanation – rather “FTR” stuff to keep.
monitor user delivery/connection time, detect slow (comparing to others or expected), direct them to closer/… node/instance by default. Meaning, you have logs, so you have the time of requests processing. So if you have some requests of one kind taking (under circumstances – be it another location or another browser or something) – taking longer that requests of the same king in other set of circumstances, you might need to adjust delivery rules – redirect traffic, test under different environment etc.
config/(code?) deployment through the Dropbox – as simple as it sounds, “simple parts” (I’m thinking configs, but might be updates as well) distribution via Dropbox.
Initial project stage:
“visual brief” – ask the basic associations, like “fast”, “pretty”, … – give some appropriate images to pick from, iterate. Like, ask customer what impression his product is aiming to project. Say the answer is “paramount”. Then suggest few images – mountain, the Sun, the Earth and the Moon, big teacher and small student – and ask customer to pick one (or few). And then iterate with styles and colors and other ideas.
measure what you want to adjust (meaning parameters selected fro KPI estimation)
make user feedback easy (put feedback interface at a clearly visible place, make it simple)
get a cool team (people that fit together (this is important), motivated (not just money, also interested in what they’re doing), productive)
make internal communication easy (chat, video, whatever – to let teams or team members connect without any hassle)
ask testers to write test cases descriptions right after ticket is created (confirmed, put to backlog) and discuss/adjust along the way. I think this one is really beneficial if used the right way, although no personal experience here yet.
Well, that’s it for now – and probably for this year, too. See me (for I think I’m the only reader – or at least a writer – of this blog) in 2014!
37signals recently posted a great article on developers doing support: http://37signals.com/svn/posts/3676-everyone-on-support. I think it’s extraordinary good description of why, how and what for (i.e. what good does it do) developers should sometimes be involved in customer support. That’s what I sometimes do now (it’s occasional, unfortunately – mostly when questions are too deep into code for support) and did that a lot beck in RightMedia/Y! days, and I can say it’s all true. To a certain limit, of course (that I faced, too) – but if you do a balanced shifts, it plays nicely.