Zone file comments

[nalberti]

Hi,

First of all THANK YOU! this saved me a heap of time converting zone files!

I just noticed a small error on conversion though, we have some zone files commented with a leading "#", checking the bind zone file syntax the following are valid;

/* This is a C-style comment */
// This is a C++-style comment
# This is a shell-style comment

An example of the current output when # commented record is processed is;

resource "aws_route53_record" "#host-domain-com-CNAME" {
   zone_id = "${aws_route53_zone.host-domain-com.zone_id}"
   name = "#host-domain-com."
   type = "CNAME"
   ttl = "300"
   records = ["cnamehost-domain-com."]
}

This results in an Terraform error

Error: aws_route53_record.#host-domain-com-CNAME: #host-domain-com-CNAME: resource name can only contain letters, numbers, dashes, and underscores.

Obviously this is just because of the "#" in the record name and record can/should be skipped/ignored.

[carlpett]

Hi @nalberti!
Glad you found it useful, and sorry for the issues. I've had a look, and it seems that RFC 1035 only allows ; for comments, and this is what the parser I use is following. While the BIND server is a bit more liberal, and allows more comment styles outside that spec.

I couldn't find any grammar in the BIND documentation exactly where those comment styles are allowed, though. They aren't even mentioned in the zone file section. Did you find something about this? There's potential for making parsing a bit harder if you can have something like foo IN /* mid-line comment */ A 127.0.0.1 # More comments

[carlpett]

After some testing, it appears BIND does not accept /* ... */-style comments in zone files (but in other configuration files), so at least that complication is avoided:
/*test.example.com. IN A 127.0.0.1*/ leads to dns_rdata_fromtext: /var/cache/bind/test.zone:5: near '127.0.0.1*/': bad dotted quad

[nalberti]

I see what you mean.. I just read though the BIND Admin guide to see if there was anything specific to zone files however it only appears to detail comments as they generally relate to configuration files.

My interpretation is that includes zone files however your test indicate otherwise.

The only guess I have is the examples show a space post/pre "*", I wonder if that makes the difference.

Here is a relevant excerpt;

http://web.mit.edu/darwin/src/modules/bind/bind/doc/html/comments.html

[carlpett]

I had a short discussion about this, and it turns out BIND might actually be violating DNS spec here by filtering out these, and the parser is doing the "right" thing by not doing so. # is a valid part of a DNS name, so #foo.example.com is a valid record... Surprised me, but so it is, apparently.

So, in the general case it would be correct to do nothing and expect the user to filter the files. However, since BIND does this, I believe this utility could do the filtering as well before passing it off to the (technically correct) parser.
I'll try to implement this tomorrow!

EDIT: BIND is not doing the wrong thing - it is doing exactly it is being asked, and just what I explained above. Resolving #foo.example.com works perfectly.
So, it turns out your "commented" records haven't been commented at all, but served under a different name... This changes things a bit - perhaps the "right" thing to do would be to preserve these records and just fix the Terraform resource name? I'm not sure how widely this is used vs misused.

[nalberti]

Hahah, wow, you are indeed correct!

I double checked and BIND is indeed serving the record #host.ourdomain.com in our public DNS!

So I agree with your suggestion that its just the Terraform resource name not supporting what is a valid host name character that is the issue.

Honestly, I doubt this issue would ever come up again, just based on the rarity of having a "#" as part of a host name and/or the widespread use of hash commented zone files.

[carlpett]

@nalberti Would you mind giving this version a try and see if it works for you? https://6-61497387-gh.circle-artifacts.com/0/bzfttr53rdutil
Would also be fantastic if you could validate that it also does not result in any difference on the old files - I had to do a fair amount of restructuring of the code. I've done quite a bit of validation, but I don't have access to any of the large or "long-time maintained" zones that I initially developed this for.

[nalberti]

Appears to work fine, I tested on 3 different zone files of my own and 2 random/sample ones found online.

The output was identical, verified by file size and diff.

Terraform plan also ran against the output fine.

Anything else you would specifically like me to test or further information ?

[carlpett]

Great, thanks a lot! That should be enough validation, I'll go ahead and merge and create a new release :)