Category Archives: Support

Basic DNS records list

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 69.9.64.10” – 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 – “16.3.0.122.in-addr.arpa. IN PTR name.net” (note that IP of name.net is 122.0.3.16)
  • 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:
2001:0db8:3c4d:0015:0000:0000:abcd:ef12
______________|____|___________________
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

SECR-2013 notes at the end of 2013

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.

OPs/delivery:

  • 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)

CI

  • 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

KPI (http://management.about.com/cs/generalmanagement/a/keyperfindic.htm):

  • measure what you want to adjust (meaning parameters selected fro KPI estimation)

Dev points:

  • 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)

QA:

  • 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!

Developers on support

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.