dns-01 walkthrough #2

Open
opened 2019-06-07 01:37:56 +00:00 by coolaj86 · 0 comments
Owner

How to pass the test

There are 3 tests that will need to pass for 3 domains.

If your domain were "example.co.uk", those domains would be:

  • example.co.uk (will need a TXT record _random-thing.example.co.uk)
  • foo.example.co.uk (will need a record _random-thing.foo.example.co.uk)
  • *.foo.example.co.uk (also needs a _random-thing.foo.example.co.uk, same as the non-wildcard)

With some DNS services you'll get a oversimplified API and you'll be able to do something like this:

request.post(
  "https://sillydns.com/api/domain/_random-thing.foo.example.co.uk/txt/xxxx",
  { auth: { user: "joe", pass: "easytoguess" } }
);

However, with most of them you'll need to do something like this:

request.post(
  "https://normaldns.com/api/zone/example.co.uk/records",
  { headers: { Authorization: "xxxs_secret_xxx" },
    json: { host: "_random-thing.foo", ttl: 300, value: [ "xxxx" ] }
 }
);

How DNS APIs are structured

DNS is to Domains as Time is to Timezones

(Technical vs Political)

DNS Records are grouped into DNS Zones.

The most common grouping happens to be a "Domain"

Hence we have "http://example.com " with the TLD .com but we also have "http://example.co.uk " with the "TLD" .co.uk.

A "Second-Level" Domain

When you buy a domain, the service you buy it from typically sets up a DNS Zone for you.

If you bought example.com then you might want to set up domains such as:

  • example.com
  • www.example.com
  • foo.example.com
  • *.foo.example.com

The records in the default zone would be

  • @
  • www.
  • foo.
  • *.foo.

Where does a Record go?

In order set a record, you have to know which zone it belongs to.

Consider the following:

  • example.com
  • www.example.com
  • foo.bar.example.com

How would a computer determine the zone?

Tt's a trick question - a computer can't. A human can - because we understand the political conventions - but a computer can only know by asking.

You might think you just count 2 parts, after all, but that would be wrong because:

  • example.co.uk (and many others) have three parts
  • .google is wholly its own thing (<domains.google>, for example)
  • foo.example.com could be delegated to a zone (common in enterprise)

In truth, a "Zone" is just a hierarchical collection of records - such as "everything under example.com" or "everything under foo.bar.example.com". There are common political conventions, but the technical specification is quite generic.

The Process

  1. Get an account and api token (may require purchasing a domain)
  2. Fetch a list of Zones (often called "domains") from the account
  • You'll need to handle paging through the list in many cases
  1. Find a Zone that matches the domain, then strip off the zone to get the prefix
  • foo.bar.example.com becomes a record foo.bar for the zone example.com
  1. Set a record in that Zone (often called "domain records") using the prefix

Well, that's the process for set, but get and remove are pretty similar - you can figure it out.

# How to pass the test There are 3 tests that will need to pass for 3 domains. If your domain were "example.co.uk", those domains would be: * `example.co.uk` (will need a TXT record `_random-thing.example.co.uk`) * `foo.example.co.uk` (will need a record `_random-thing.foo.example.co.uk`) * `*.foo.example.co.uk` (_also_ needs a `_random-thing.foo.example.co.uk`, same as the non-wildcard) With some DNS services you'll get a oversimplified API and you'll be able to do something like this: ```js request.post( "https://sillydns.com/api/domain/_random-thing.foo.example.co.uk/txt/xxxx", { auth: { user: "joe", pass: "easytoguess" } } ); ``` However, with most of them you'll need to do something like this: ```js request.post( "https://normaldns.com/api/zone/example.co.uk/records", { headers: { Authorization: "xxxs_secret_xxx" }, json: { host: "_random-thing.foo", ttl: 300, value: [ "xxxx" ] } } ); ``` # How DNS APIs are structured > DNS is to Domains as Time is to Timezones > > (Technical vs Political) DNS **Records** are grouped into DNS **Zones**. The most common grouping *happens* to be a "Domain" Hence we have "http://example.com " with the TLD .com but we also have "http://example.co.uk " with the "TLD" .co.uk. ### A "Second-Level" Domain When you buy a domain, the service you buy it from typically sets up a DNS Zone for you. If you bought `example.com` then you might want to set up _domains_ such as: * example.com * www.example.com * foo.example.com * *.foo.example.com The _records_ in the default _zone_ would be * @ * www. * foo. * *.foo. ### Where does a Record go? In order set a **record**, you have to know which **zone** it belongs to. Consider the following: * example.com * www.example.com * foo.bar.example.com How would a computer determine the **zone**? Tt's a trick question - a computer _can't_. A human can - because we understand the political conventions - but a computer can only know by asking. You might think you just **count 2 parts**, after all, but that would be wrong because: * example.co.uk (and many others) have three parts * .google is wholly its own thing (<domains.google>, for example) * foo.example.com _could_ be delegated to a zone (common in enterprise) In truth, a "Zone" is just a hierarchical collection of records - such as "everything _under_ example.com" or "everything _under_ foo.bar.example.com". There are common political conventions, but the technical specification is quite generic. # The Process 1. Get an account and api token (may require purchasing a domain) 2. Fetch a list of Zones (often called "domains") from the account * You'll need to handle _paging_ through the list in many cases 3. Find a Zone that matches the domain, then strip off the zone to get the prefix * `foo.bar.example.com` becomes a record `foo.bar` for the zone `example.com` 4. Set a record in that Zone (often called "domain records") using the prefix Well, that's the process for `set`, but `get` and `remove` are pretty similar - you can figure it out.
Sign in to join this conversation.
No Label
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coolaj86/acme-challenge-test.js#2
No description provided.