@mholt

Continuing the discussion from #153 (comment):

Hmm, now that you mention it, that might actually be necessary in a lot of cases right now. It would be valid for an implementation to do something like return libdns.Address structs for A/AAAA RRs and libdns.Record for all other record types, so if you want to make sure that you always have a specific record type (for a type switch), you'd have to run RR().Parse() first.

Ahh, good point.

So I had a big long reply drafted up to this, documenting my thought process that you spurred on, but then my browser tab closed and I lost it.

Basically... yeah, let's document that providers should return specific type structs rather than RR.

There's just no way to technically enforce and require that they do without being evil:

// remove RR() from the RR struct, then:

type Record interface {
    RR() RR
    mustUseOurTypes() unexportedType
}

This is the only way I can think of that would prevent them from defining their own types that implement the Record interface (making type assertions difficult again), and force that they don't return RR structs.

(I also like the flexibility (for input purposes) of RR also being a Record.)

Some providers define provider-specific RR types, so we should probably document if libdns implementations are allowed to define custom Record types. For example, lots of providers define ANAME/ALIAS RR types that act like “a CNAME at the zone root” and URL/REDIRECT RR types that perform an HTTP redirect to the specified URL (by having the provider host an HTTP server at those addresses).

I guess our options are

1. Allow libdns implementations to define provider-specific Record types

2. Document that libdns implementations aren't allowed to define provider-specific Record types

   a. Without technically enforcing it

   b. With technically enforcing it

3. Define ANAME/ALIAS and URL/REDIRECT types in libdns itself

The advantage to (1) is that it would let implementations easily add the necessary semantics to any of their special records (see #153 (comment)), but it would also make type assertions/switches a little more complicated. (2a) is the path of least resistance and is what you're suggesting right now, but for some RR types it might be a little awkward to deal with all of the data as just the Data string field. (2b) is the same as (2a), except that you lose the benefit of RR being a Record. (3) has the benefit of letting you express these fairly common records in a provider-independent manner, but it would be tricky for us to define specific semantics for these records since they're ultimately provider-specific.

To me, either (1) or (2a) seem like the best options, so we should probably pick one and document it somewhere.