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 22.214.171.124” – 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 – “126.96.36.199.in-addr.arpa. IN PTR name.net” (note that IP of name.net is 188.8.131.52)
- 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
- There’s also a number of decentralized DNS initiatives
Oh, and on IPV6:
- it’s 128-bit (IPV4 is 32)
- it’s recorded in hex numbers, 8 quads
- it has following structure:
global prefix subnet Interface ID
- local address is 0000:0000:0000:0000:0000:0000:0000:0001
- and IPV4 record in that case would look like 0000:0000:0000:0000:0000:0000:192.168.1.25
- zeroes could be omitted: ::1 or ::192.168.1.25
- to make sure address is shortened correctly, use ipv6calc util: ipv6calc –in ipv6addr –out ipv6addr –printuncompressed ::1
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.
- moodboards (MoodShare…) – pick lots of stuff on the screen, let customer select, SCAMPER (http://www.mindtools.com/pages/article/newCT_02.htm)
- try test using DB/ssh connect (separate config) to run local changes against test instance remotely
- togglers: big-feature switches, allow to disable/enable particular features separately, config- (or environment-) controlled way (triggers in cookies, ENV, config, URL etc.
- same tests on CI and local, local ran for feature-related validations (branches), CI for default
- think performance tests
- 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.