Regexp to match RR's

[Kevin Darcy]

Chris Buxton wrote:
> On Apr 8, 2009, at 3:09 PM, Kevin Darcy wrote:
>> Jonathan Petersson wrote:
>>> Hi all,
>>>
>>> I got some time over so I decide to hack a bit on a DNS management
>>> tool for my home-server.
>>>
>>> I'm curious as to wether someone knows of a list of regexps that can
>>> be used to match RR's.
>>>
>> I'm not sure why a DNS management tool would be in the business of 
>> "matching" RRs textually. The most popular methods these days for 
>> generating and updating zone data appear to be a) Dynamic Update, b) 
>> h2n (which converts a "hosts" file into zone files, under fairly 
>> sophisticated configuration control), or c) backend database. None of 
>> these methods entails parsing the contents of a zone file as input, 
>> except perhaps initially as a way to import legacy zone files into 
>> the new management tool (and in my opinion, the same thing could be 
>> accomplished more cleanly by AXFR'ing the contents of the zones 
>> instead of parsing the zone files).
>>
>> Managing DNS by manipulating zone files textually is, in my opinion, 
>> a dead end. I tried that over a decade ago and it was just too much 
>> of a headache and I had to switch methodologies.
>
>
> Kevin,
>
> I have to disagree with you, based on real-world experience and 
> customer feedback.
>
> Men & Mice Suite works fine with static zone files on disk. We don't 
> require use of any of the three options you mentioned. Our customers 
> see this as one of our compelling strengths - the database is not the 
> authoritative source of the zone data, the zone file on disk is.
>
> We permit users essentially direct access to the zone file, in a 
> table-type window. That window is populated based on the contents of 
> the zone on disk. User input is obviously validated, but in many ways, 
> working with the table view is much like working with a zone in a text 
> editor (in a good way). It's often not desirable to give inexperienced 
> users access to this view, but for power users, it's invaluable.
>
> We even let users "check out" the actual zone file directly to open it 
> in any kind of text editor or scripting tool (sed, perl, whatever) 
> they want and make whatever changes they want. This is most useful for 
> external scripted solutions that can't be modified to use our CLI or 
> other API's, but it's there for use by anyone who has filesystem 
> access to the zone.
>
> Of course, Men & Mice Suite also works just fine with dynamic zones 
> and AD-integrated zones.
>
> On Apr 8, 2009, at 3:21 PM, Kevin Darcy wrote:
>> I'm not a big fan of allowing users to enter Resource Records 
>> verbatim. Most users aren't that sophisticated, or, if they are, they 
>> can do their nsupdates directly, if they have been given access to 
>> the relevant TSIG key (how's that for a False Dilemma argument :-)
>
> Again, I have to disagree with that statement. Aside from automated 
> updates, even for dynamic zones (zones that allow dynamic updates), 
> our customers wouldn't want day-to-day updates being submitted by 
> dynamic update from user to DNS server. The reason is that dynamic 
> updates are anonymous - there's no audit trail. For compliance 
> reasons, it's valuable to have such updates submitted through a tool 
> that logs them (user, timestamp, actions, user comment), even if the 
> tool then sends them on to the DNS server via dynamic updates.
That last part was written mostly in jest, hence the emoticon. As it 
happens, though, we perform manual nsupdates quite rarely, and the only 
people authorized to do so are also trusted to follow our Change 
Management policies for each and every such change (which involves 
getting management approvals, generating audit trails, documenting the 
verification of the change, the whole 9 yards). It just so happens that 
the same small set of people are the only ones, who come to mind, whom I 
would trust to understand the structure, limitations, interactions, etc. 
of Resource Records, if they were "editing" them in a glorified version 
of vi or emacs. Maybe other organizations are different, but that's my 
experience.

- Kevin