search

mirage / ocaml-dns

OCaml implementation of the DNS protocol
BSD 2-Clause "Simplified" License
106 stars 43 forks source link

zonefile `$ORIGIN` could be used to infer the zone name instead of having to explicitly pass it #335

Closed RyanGibb closed 1 year ago

RyanGibb commented 1 year ago

Dns_zone.decode_zones and Dns_zone.decode_zones_keys take a list of pairs of domain names and zonefiles. I think passing the domain names alongside zonefiles that already contain an $ORIGIN directive is redundant, and could instead be inferred from Dns_zone.parse.

hannesm commented 1 year ago

I'm not sure about your goal, would you mind to elaborate?

The definition of $ORIGIN is in RFC 1035, and pretty clear, or am I misguided? Esp. it does not need to be the zone; also it may appear several times in the same file. And additionally it is not required.

So, what is your concrete suggestion for decode_zones and decode_zones_keys API?

RyanGibb commented 1 year ago

My goal was to simplify configuration of serving a zonefile but I didn't consider the case where $ORIGIN is omitted. My apologies, and thanks for your time.

RyanGibb commented 1 year ago

Having thought more about this, I think passing zone names is still unnecessary. They are used for discarding all resource records that aren't in the zone, and getting the SOA record from the trie. However, rfc1035 states that "Exactly one SOA RR should be present at the top of the zone.". So if we just got name of the SOA record we could infer the domain that the server is authoritative for. However, I see that there are no functions in Dns_trie that don't take a name. If I were to add a function that returned all the RRs of a zonefile without considering their name, and using it to get the one SOA RR, then passing the zone names to the Dns_zone decode functions would be unnecessary.

hannesm commented 1 year ago

Ok, so Dns_zone.parse does only take a string (the zone file data). You can use that for retrieving a Dns.Name_rr_map.t and use that to construct a Dns_trie.t. Does this meet your "If I were to add a function that returned all the RRs of a zonefile without considering their name" requirement?

Now, I still don't understand your usecase, but of course you can copy and use parts of e.g. Dns_zone.decode_zone to construct your Dns_trie.t, and there's no requirement to use any of the helper functions in Dns_zone.

My usecase is having a git repository where access is granted based on files, and I'd like to avoid anyone to define different zones (or resource records of other zones that may be part of the same git repository) than the filename in the respective files.

RyanGibb commented 1 year ago

I see! Thanks for you suggestion @hannesm. I think https://github.com/RyanGibb/aeon/commit/eee2bf02751b5a397e803e9b69c1a60d861935a8#diff-4a08340cd2edfe5fbc8478bee69a6d63cec15e3c56571e88d1ba24dec6aea03cR2-R52 is now doing what I wanted.

My usecase is having a git repository where access is granted based on files, and I'd like to avoid anyone to define different zones (or resource records of other zones that may be part of the same git repository) than the filename in the respective files.

I see! The Dns_zone functions make a lot more sense understanding this. My use case is for https://github.com/RyanGibb/aeon/ which is a nameserver mainly targeting unix, so I'm not so concerned about trusting zonefiles provided by the user.