CAA support in AnyEvent::DNS

[Steve Atkins]

> On Aug 16, 2017, at 7:11 PM, Marc Lehmann <schmorp at schmorp.de> wrote:
> 
> On Tue, Aug 15, 2017 at 07:06:19AM -0700, Steve Atkins <steve at blighty.com> wrote:
>> I found I needed support for CAA records[1] in AnyEvent::DNS.
> 
> I would think that AnyEvent::DNS already supports caa records, it just
> doesn't use the caa name but gives you the numeric code, wouldn't that
> have worked for you?

It's dns_unpack that's the issue. Passing 257 rather than 'caa' in would
be easy enough, but dealing with the response being raw
bytes rather than a decoded structure would make for pretty ugly client code.

Pushing a clean enhancement upstream seemed a better thing to do than monkey
patching or maintaining a local fork, which were the other two things
I considered.

> 
>> Attached is a tiny patch to add support for them. It works for me, at least as far as
>> being able to resolve them for google.com.
> 
> I'm a bit split - on the one hand, the patch is simple (and I have applied
> it, so it will be in the next release), on the other hand, this will
> likely break all existing users of caa records with AnyEvent::DNS (which
> hopefully don't exist).

Thanks!

> 
> So at the moment, I am inclined to officially not accept further such
> patches on the ground of backwards compatibility, at leats in less obsucre
> cases.

I wonder how painful it'd be to distinguish between the request passing in
a string ('caa') rather than an integer (257) and decide whether to decode the
response or not based on that?

It's not like new RRs turn up terribly often, though, so meh.

Cheers,
  Steve