From jakob at kirei.se  Mon Jan  7 09:07:46 2013
From: jakob at kirei.se (Jakob Schlyter)
Date: Mon, 7 Jan 2013 10:07:46 +0100
Subject: [net-dns-users] How to translate the email in SOA
In-Reply-To: <CAKW6Ri4DT9=ehnPWuCkTmLfwtkVBQo+9uR37AVgvH50N1ZE=vg@mail.gmail.com>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <20121220102217.779e40a5@localhost> <1419291356172025@web18h.yandex.ru>
 <168131356173141@web6f.yandex.ru>
 <CAKW6Ri4DT9=ehnPWuCkTmLfwtkVBQo+9uR37AVgvH50N1ZE=vg@mail.gmail.com>
Message-ID: <6FCB85E4-01F5-4D68-B422-7D3F89F76907@kirei.se>

On 22 dec 2012, at 14:39, Dick Franks <rwfranks at acm.org> wrote:

> There is no need to do that!
> 
> If you use Net::DNS 0.69 or later, all the conversions are done for you.

Which, IMHO, is bad and changes the API.

I urge the developers to revert back to the previous semantics where the SOA field is actually what is in the SOA field (i.e. encoded @ sign), and possibly add a new accessor for getting/setting SOA using the full unencoded email address.

	jakob




From calle.dybedahl at init.se  Mon Jan  7 10:10:32 2013
From: calle.dybedahl at init.se (Calle Dybedahl)
Date: Mon, 7 Jan 2013 11:10:32 +0100
Subject: [net-dns-users] Dual-faced Net::DNS? (was: section RR counts
	read only)
In-Reply-To: <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
Message-ID: <4C98CCD3-12F8-401A-A5CB-2954D9D454E8@init.se>


On 20 dec 2012, at 16:58, Dick Franks <rwfranks at acm.org> wrote:

> IMHO the secondary mission would be better served by a separate purpose-built test tool distribution, driven by users who need it, and which would not be routinely redistributed as part of general purpose Linux distributions.


It is increasingly feeling like we're fighting Net::DNS rather than being helped by it. To some extent we've always done that (for example, it's impossible to create Net::DNS::Resolver objects with an empty nameserver list, so we create ours with a known-not-to-exist IP address as the only nameserver). But with the post-0.68 versions, it's starting to look like some behaviors can't be worked around, and we're losing functionality. For example, one of our tests is to check if the email address given in the RNAME field of a SOA record looks reasonably functional, and if not give a useful error message. At the moment, it looks like we can still test for broken addresses (since Net::DNS transforms them into another broken form), but we can no longer give a useful error message, since we cannot get the string that the user actually put in the SOA record. If there is a way to get the plain untranslated ASCII string that came over the wire, I'd very much like to know how.

From my point of view, it's increasingly looking like we'll soon have to fork Net::DNS and maintain our own version of it. We need a "raw" interface to DNS, and every new way in which Net::DNS tries to be helpful is, for us, a hindrance. At some point, it will become hard enough for us to use that maintaining a different version ourselves will become a less painful option. I would rather it not get there, since in the long run that would mean a lot of unnecessary duplicated effort.

I can see the usefulness of a friendly interface to DNS, and I'm sure that for the vast majority of use cases the new things really are improvements. My problem is that in making some things easier, the things I need to do are becoming not just harder but impossible. Harder I could deal with. Impossible, not so much.

Anyway. Here's a suggestion: Instead of splitting off a special test tool distribution, let's give Net::DNS two faces. One nice, friendly, helpful and as far as possible optimized for the common case. One raw, unvarnished and unforgiving and aimed at making possible all the weird things nobody's thought of before. Possibly, the first could be built on top of the second. Or not, depending on what's easiest. 

Since .SE has contracted me for the entire year and we depend heavily on Net::DNS, I am able (and willing) to contribute actual programming effort toward this end.

What do you think? Would this be an acceptable direction to move Net::DNS in?

-- 
Calle Dybedahl
calle at init.se -*- +46 703 - 970 612



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130107/c0b37830/attachment.htm>

From clists at buxtonfamily.us  Mon Jan  7 17:24:45 2013
From: clists at buxtonfamily.us (Chris Buxton)
Date: Mon, 7 Jan 2013 09:24:45 -0800
Subject: [net-dns-users] Dual-faced Net::DNS? (was: section RR counts
	read only)
In-Reply-To: <4C98CCD3-12F8-401A-A5CB-2954D9D454E8@init.se>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <4C98CCD3-12F8-401A-A5CB-2954D9D454E8@init.se>
Message-ID: <DEC5E513-86D0-42FF-A4BA-E747E7F34F8E@buxtonfamily.us>


On Jan 7, 2013, at 2:10 AM, Calle Dybedahl wrote:
> On 20 dec 2012, at 16:58, Dick Franks <rwfranks at acm.org> wrote:
> 
>> IMHO the secondary mission would be better served by a separate purpose-built test tool distribution, driven by users who need it, and which would not be routinely redistributed as part of general purpose Linux distributions.
> 
> 
> Anyway. Here's a suggestion: Instead of splitting off a special test tool distribution, let's give Net::DNS two faces. One nice, friendly, helpful and as far as possible optimized for the common case. One raw, unvarnished and unforgiving and aimed at making possible all the weird things nobody's thought of before. Possibly, the first could be built on top of the second. Or not, depending on what's easiest. 

Personally, I don't see the usefulness of the "friendly" version. Give me the raw data and then (if desired) give me helper routines to convert it to a friendlier version, if that's what I want to do. Don't give me the interpreted version and make me undo what you've done.

For example, I'd really appreciate it if the Net::DNS::RR::SOA::format_rdata() didn't add comments and didn't break the data across multiple lines.

Regards,
Chris Buxton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130107/90c1c613/attachment.htm>

From dougb at dougbarton.us  Mon Jan  7 20:16:59 2013
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 07 Jan 2013 12:16:59 -0800
Subject: [net-dns-users] Dual-faced Net::DNS?
In-Reply-To: <DEC5E513-86D0-42FF-A4BA-E747E7F34F8E@buxtonfamily.us>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <4C98CCD3-12F8-401A-A5CB-2954D9D454E8@init.se>
 <DEC5E513-86D0-42FF-A4BA-E747E7F34F8E@buxtonfamily.us>
Message-ID: <50EB2D3B.203@dougbarton.us>

On 01/07/2013 09:24 AM, Chris Buxton wrote:
>
> On Jan 7, 2013, at 2:10 AM, Calle Dybedahl wrote:
>> On 20 dec 2012, at 16:58, Dick Franks <rwfranks at acm.org
>> <mailto:rwfranks at acm.org>> wrote:
>>
>>> IMHO the secondary mission would be better served by a separate
>>> purpose-built test tool distribution, driven by users who need it,
>>> and which would not be routinely redistributed as part of general
>>> purpose Linux distributions.
>>
>> Anyway. Here's a suggestion: Instead of splitting off a special test
>> tool distribution, let's give Net::DNS two faces. One nice, friendly,
>> helpful and as far as possible optimized for the common case. One raw,
>> unvarnished and unforgiving and aimed at making possible all the weird
>> things nobody's thought of before. Possibly, the first could be built
>> on top of the second. Or not, depending on what's easiest.
>
> Personally, I don't see the usefulness of the "friendly" version. Give
> me the raw data and then (if desired) give me helper routines to convert
> it to a friendlier version, if that's what I want to do. Don't give me
> the interpreted version and make me undo what you've done.
>
> For example, I'd really appreciate it if the
> Net::DNS::RR::SOA::format_rdata() didn't add comments and didn't break
> the data across multiple lines.

Agreed ... I have to track down how these changes have impacted one of 
my scripts that parses SOAs, just haven't gotten to it yet or I would 
have sent in a complaint myself.

Chris' suggestion of keeping the old format plus adding helper functions 
to parse them is a good combination of maximum compatibility + maximum 
helpfulness. Another option would be that the old method returns the 
data in the old raw format, and a new method could be added to return 
data in the post-processed (cooked?) format.

Either way, changing the format of returned data structures that have 
been stable for many years is a POLA violation.

Doug



From patrik at frobbit.se  Mon Jan  7 09:35:05 2013
From: patrik at frobbit.se (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=)
Date: Mon, 7 Jan 2013 10:35:05 +0100
Subject: [net-dns-users] How to translate the email in SOA
In-Reply-To: <6FCB85E4-01F5-4D68-B422-7D3F89F76907@kirei.se>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <20121220102217.779e40a5@localhost> <1419291356172025@web18h.yandex.ru>
 <168131356173141@web6f.yandex.ru>
 <CAKW6Ri4DT9=ehnPWuCkTmLfwtkVBQo+9uR37AVgvH50N1ZE=vg@mail.gmail.com>
 <6FCB85E4-01F5-4D68-B422-7D3F89F76907@kirei.se>
Message-ID: <172F7E4B-0FCF-42B5-97AE-57A355D261E0@frobbit.se>


On 7 jan 2013, at 10:07, Jakob Schlyter <jakob at kirei.se> wrote:

> On 22 dec 2012, at 14:39, Dick Franks <rwfranks at acm.org> wrote:
> 
>> There is no need to do that!
>> 
>> If you use Net::DNS 0.69 or later, all the conversions are done for you.
> 
> Which, IMHO, is bad and changes the API.
> 
> I urge the developers to revert back to the previous semantics where the SOA field is actually what is in the SOA field (i.e. encoded @ sign), and possibly add a new accessor for getting/setting SOA using the full unencoded email address.

+10000000....000

Do not change behavior on existing routines. If you want to, add new ones.

   Patrik




From opensource at hardakers.net  Tue Jan  8 17:05:19 2013
From: opensource at hardakers.net (Wes Hardaker)
Date: Tue, 08 Jan 2013 09:05:19 -0800
Subject: [net-dns-users] How to translate the email in SOA
In-Reply-To: <172F7E4B-0FCF-42B5-97AE-57A355D261E0@frobbit.se> ("Patrik
 =?utf-8?B?RsOkbHRzdHLDtm0iJ3M=?= message of "Mon, 7 Jan 2013 10:35:05
 +0100")
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <20121220102217.779e40a5@localhost>
 <1419291356172025@web18h.yandex.ru> <168131356173141@web6f.yandex.ru>
 <CAKW6Ri4DT9=ehnPWuCkTmLfwtkVBQo+9uR37AVgvH50N1ZE=vg@mail.gmail.com>
 <6FCB85E4-01F5-4D68-B422-7D3F89F76907@kirei.se>
 <172F7E4B-0FCF-42B5-97AE-57A355D261E0@frobbit.se>
Message-ID: <0ltxqrhagg.fsf@wjh.hardakers.net>

Patrik F?ltstr?m <patrik at frobbit.se> writes:

>> I urge the developers to revert back to the previous semantics where
>> the SOA field is actually what is in the SOA field (i.e. encoded @
>> sign), and possibly add a new accessor for getting/setting SOA using
>> the full unencoded email address.
>
> +10000000....000
>
> Do not change behavior on existing routines. If you want to, add new ones.

I also agree.  I've already had to change things in code that uses
Net::DNS because of changed routines (some of which were internal, and
thus it's my own fault (or the previous author's) for using them, and
some of which were public).

OpenSSL does the same thing: they change APIs routinely and it's pain in
the neck when you write a 3rd-party software package that must use
"whatever is available on the system".  The hacks required to code
around an API that may work one way on one system and a different way on
another are not pretty.

-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/



From olaf at NLnetLabs.nl  Wed Jan  9 14:32:10 2013
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Wed, 9 Jan 2013 15:32:10 +0100
Subject: [net-dns-users] Inventory (Was: How to translate the email in SOA)
In-Reply-To: <0ltxqrhagg.fsf@wjh.hardakers.net>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <20121220102217.779e40a5@localhost> <1419291356172025@web18h.yandex.ru>
 <168131356173141@web6f.yandex.ru>
 <CAKW6Ri4DT9=ehnPWuCkTmLfwtkVBQo+9uR37AVgvH50N1ZE=vg@mail.gmail.com>
 <6FCB85E4-01F5-4D68-B422-7D3F89F76907@kirei.se>
 <172F7E4B-0FCF-42B5-97AE-57A355D261E0@frobbit.se>
 <0ltxqrhagg.fsf@wjh.hardakers.net>
Message-ID: <8D47556E-4CCF-48F2-A5FA-965DAC5C3202@NLnetLabs.nl>



Folk,

First, I am very grateful to Dick who introduced a lot of quality improvements in the Net::DNS internals, developments that caused some changes to the API. That said, I am sensitive to problems that are caused by changing APIs. The introduction of the @-sign in the SOA rname field is one of them. 

What I would like to now is whether there are other places where you experienced pain. Please, be so kind to report that as a reply to this thread so that we have an inventory of pain-points. As an aid you can refer to the list attached. (Previously distributed to this lis in a thread with subject "List of API changes in versions after 0.68?"). Please do not use this inventory as a wish list for changes you would like to see in Net::DNS in general. Just focus on things that changes after .68 and that caused serious problems.


In about a week or two we'll go over the list and propose actions.

--Olaf

PS: From an NLnet Labs perspective we try to moderate the development of Net::DNS much more than we try to lead it: I see Net::DNS much more as a community effort and we are very liberal in sucking up contributions. 

PPS: The trend in contributions is that in general the architecture becomes cleaner and more efficient and provides a clean and less error prone access to write and read DNS from the wire, however that may be at the expense of the ability to hack around. 


PPS:  I regret not having set up this mailing list before.






NLnet
Labs
Olaf M. Kolkman

www.NLnetLabs.nl
olaf at NLnetLabs.nl

Science Park 400, 1098 XH Amsterdam, The Netherlands



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130109/b7c7c53d/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: net-dns-0.69-architecture.txt
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130109/b7c7c53d/attachment.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130109/b7c7c53d/attachment-0001.htm>

From jtk at cymru.com  Wed Jan  9 15:25:49 2013
From: jtk at cymru.com (John Kristoff)
Date: Wed, 9 Jan 2013 09:25:49 -0600
Subject: [net-dns-users] Inventory (Was: How to translate the email in
 SOA)
In-Reply-To: <8D47556E-4CCF-48F2-A5FA-965DAC5C3202@NLnetLabs.nl>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <20121220102217.779e40a5@localhost>
 <1419291356172025@web18h.yandex.ru>
 <168131356173141@web6f.yandex.ru>
 <CAKW6Ri4DT9=ehnPWuCkTmLfwtkVBQo+9uR37AVgvH50N1ZE=vg@mail.gmail.com>
 <6FCB85E4-01F5-4D68-B422-7D3F89F76907@kirei.se>
 <172F7E4B-0FCF-42B5-97AE-57A355D261E0@frobbit.se>
 <0ltxqrhagg.fsf@wjh.hardakers.net>
 <8D47556E-4CCF-48F2-A5FA-965DAC5C3202@NLnetLabs.nl>
Message-ID: <20130109092549.2924736b@localhost>

On Wed, 9 Jan 2013 15:32:10 +0100
Olaf Kolkman <olaf at nlnetlabs.nl> wrote:

> What I would like to now is whether there are other places where you
> experienced pain. Please, be so kind to report that as a reply to

Pain is relative, but I had to change some code I usually every day,
when upgrading to the new version.  Changes that didn't seem very
helpful to me and in fact,and technically ended up by me having to incur
additional object creation time.  This was mostly a surprise, not a
show stopper. More specifically, and this may not have been desired
behavior from the beginning, but it was handy, I would create a
Question object without the qname defined, this seems no longer
possible.  This was useful, because in a loop I would set the qname to
a unique value each way through and then push the RR into a Packet
object I had defined.

I also thought being able to override and set the various section count
values to whatever I wanted was useful as I mentioned earlier.

> error prone access to write and read DNS from the wire, however that
> may be at the expense of the ability to hack around. 

That appears to be thrust of the criticisms I've seen mentioned here,
but please consider it in light of the much more significant
appreciation of all that Nlnet Labs does for the community.  Your team
rocks!

John


From einar.lonn at iis.se  Wed Jan  9 10:11:31 2013
From: einar.lonn at iis.se (=?iso-8859-1?Q?Einar_L=F6nn?=)
Date: Wed, 9 Jan 2013 11:11:31 +0100
Subject: [net-dns-users] How to translate the email in SOA
In-Reply-To: <0ltxqrhagg.fsf@wjh.hardakers.net>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <20121220102217.779e40a5@localhost> <1419291356172025@web18h.yandex.ru>
 <168131356173141@web6f.yandex.ru>
 <CAKW6Ri4DT9=ehnPWuCkTmLfwtkVBQo+9uR37AVgvH50N1ZE=vg@mail.gmail.com>
 <6FCB85E4-01F5-4D68-B422-7D3F89F76907@kirei.se>
 <172F7E4B-0FCF-42B5-97AE-57A355D261E0@frobbit.se>
 <0ltxqrhagg.fsf@wjh.hardakers.net>
Message-ID: <8B8A71C4-920D-4F93-A3C9-C7477EEF1547@iis.se>

On Jan 8, 2013, at 6:05 PM, Wes Hardaker wrote:

> Patrik F?ltstr?m <patrik at frobbit.se> writes:
> 
>>> I urge the developers to revert back to the previous semantics where
>>> the SOA field is actually what is in the SOA field (i.e. encoded @
>>> sign), and possibly add a new accessor for getting/setting SOA using
>>> the full unencoded email address.
>> 
>> +10000000....000
>> 
>> Do not change behavior on existing routines. If you want to, add new ones.
> 
> I also agree.  I've already had to change things in code that uses
> Net::DNS because of changed routines (some of which were internal, and
> thus it's my own fault (or the previous author's) for using them, and
> some of which were public).
> 
> OpenSSL does the same thing: they change APIs routinely and it's pain in
> the neck when you write a 3rd-party software package that must use
> "whatever is available on the system".  The hacks required to code
> around an API that may work one way on one system and a different way on
> another are not pretty.
> 
> -- 
> Wes Hardaker                                     
> My Pictures:  http://capturedonearth.com/
> My Thoughts:  http://pontifications.hardakers.net/

As do I. The less automagic the better, we've been having trouble using later version of Net::DNS and it's getting worse lately with every new release. Please do listen to us in this; we're using Net::DNS to *test* DNS so we expect it not to fiddle with the actual packets and perform magic we didnt ask for. :(


	/Regards, Einar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130109/048bbd37/attachment.bin>

From paf at frobbit.se  Thu Jan 10 11:49:38 2013
From: paf at frobbit.se (=?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?=)
Date: Thu, 10 Jan 2013 12:49:38 +0100
Subject: [net-dns-users] How to translate the email in SOA
In-Reply-To: <8B8A71C4-920D-4F93-A3C9-C7477EEF1547@iis.se>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <20121220102217.779e40a5@localhost> <1419291356172025@web18h.yandex.ru>
 <168131356173141@web6f.yandex.ru>
 <CAKW6Ri4DT9=ehnPWuCkTmLfwtkVBQo+9uR37AVgvH50N1ZE=vg@mail.gmail.com>
 <6FCB85E4-01F5-4D68-B422-7D3F89F76907@kirei.se>
 <172F7E4B-0FCF-42B5-97AE-57A355D261E0@frobbit.se>
 <0ltxqrhagg.fsf@wjh.hardakers.net>
 <8B8A71C4-920D-4F93-A3C9-C7477EEF1547@iis.se>
Message-ID: <42B8BEC1-69A9-4FC1-AF1E-12839E87DF70@frobbit.se>

On 9 jan 2013, at 11:11, Einar L?nn <einar.lonn at iis.se> wrote:

> As do I. The less automagic the better, we've been having trouble using later version of Net::DNS and it's getting worse lately with every new release. Please do listen to us in this; we're using Net::DNS to *test* DNS so we expect it not to fiddle with the actual packets and perform magic we didnt ask for. :(

I am not upgrading my Net::DNS for exactly these reasons.

If I ask for the packet, I want to get the packet. That is how the API has been so far.

If you want some magic applied that helps parsing/correcting the data please add more functions. I do understand why this is needed. Specifically if the parsing is of data from for example a text file, in what situation what is parsed might very well not be at all what one want to give as output (which should be in a correct canonical format).

So, I am definitely not against the movement, to get Net::DNS more easy to use!

   Patrik

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130110/963a4eda/attachment.bin>

From fenghe at nsbeta.info  Fri Jan 11 03:07:05 2013
From: fenghe at nsbeta.info (Feng He)
Date: Fri, 11 Jan 2013 11:07:05 +0800
Subject: [net-dns-users] How to translate the email in SOA
In-Reply-To: <42B8BEC1-69A9-4FC1-AF1E-12839E87DF70@frobbit.se>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <20121220102217.779e40a5@localhost> <1419291356172025@web18h.yandex.ru>
 <168131356173141@web6f.yandex.ru>
 <CAKW6Ri4DT9=ehnPWuCkTmLfwtkVBQo+9uR37AVgvH50N1ZE=vg@mail.gmail.com>
 <6FCB85E4-01F5-4D68-B422-7D3F89F76907@kirei.se>
 <172F7E4B-0FCF-42B5-97AE-57A355D261E0@frobbit.se>
 <0ltxqrhagg.fsf@wjh.hardakers.net>
 <8B8A71C4-920D-4F93-A3C9-C7477EEF1547@iis.se>
 <42B8BEC1-69A9-4FC1-AF1E-12839E87DF70@frobbit.se>
Message-ID: <50EF81D9.9010607@nsbeta.info>

Thanks all for your response on this thread.

To  get the email from a SOA, I have done with:

sub get_soa {

     my $zone = shift;
     my $host = '127.0.0.1';

     my $res   = Net::DNS::Resolver->new(nameservers => [$host]);
     my $query = $res->query($zone, "SOA");
     if (defined $query) {
         return ($query->answer)[0];
     } else {
         return;
     }
}

my $re=$ds->get_soa("test.com");
print $re->rname,"\n";

This print the email address with normal format.

I have been using nsupdate (which is called as an external command 
within Perl) to update the SOA record, so how to commit the encoded 
email string?

I have wrote the subroutine like:

sub format_email_for_soa {

     my $email = shift;
     my ($user,$tld) = split/\@/,$email;
     $user =~ s/\./\\./g;
     $user. '.' .$tld . '.';
}

But I am not sure whether it satisfy all  the cases.

Thanks.




From dougb at dougbarton.us  Sun Jan 13 03:30:22 2013
From: dougb at dougbarton.us (Doug Barton)
Date: Sat, 12 Jan 2013 19:30:22 -0800
Subject: [net-dns-users] SSL cert on www.net-dns.org
Message-ID: <50F22A4E.1030705@dougbarton.us>

Do y'all have anything to do with that site? It gives all kinds of 
warnings in Firefox, like the use of an insecure signature algorithm, 
and the fact that the cert is for *.nlnetlabs.nl.

https://www.startssl.com/ will give you a free SSL cert, and no cert 
would be preferable to what's there now.

Doug


From Willem at NLnetLabs.nl  Sun Jan 13 11:56:45 2013
From: Willem at NLnetLabs.nl (Willem Toorop)
Date: Sun, 13 Jan 2013 12:56:45 +0100
Subject: [net-dns-users] SSL cert on www.net-dns.org
In-Reply-To: <50F22A4E.1030705@dougbarton.us>
References: <50F22A4E.1030705@dougbarton.us>
Message-ID: <50F2A0FD.8000909@NLnetLabs.nl>

Hi Doug,

Op 13-01-13 04:30, Doug Barton schreef:
> Do y'all have anything to do with that site? It gives all kinds of
> warnings in Firefox, like the use of an insecure signature algorithm,
> and the fact that the cert is for *.nlnetlabs.nl.

It also has *.net-dns.org in the "X509v3 Subject Alternative Name" part
of the certificate.

When you have CAcert.org's root certificate in your CA repository, it
validates. At least Debian and Ubuntu have it in the ca-certificates
package.

Also TLSA records confirming the certificate are present in the
net-dns.org zone (which is itself dnssec signed):

$ ldns-dane verify www.net-dns.org 443
213.154.224.135 dane-validated successfully
2001:7b8:206:1:b0ef:9:: dane-validated successfully

-- Willem


From dougb at dougbarton.us  Sun Jan 13 19:51:10 2013
From: dougb at dougbarton.us (Doug Barton)
Date: Sun, 13 Jan 2013 11:51:10 -0800
Subject: [net-dns-users] SSL cert on www.net-dns.org
In-Reply-To: <50F2A0FD.8000909@NLnetLabs.nl>
References: <50F22A4E.1030705@dougbarton.us> <50F2A0FD.8000909@NLnetLabs.nl>
Message-ID: <50F3102E.8010306@dougbarton.us>

On 01/13/2013 03:56 AM, Willem Toorop wrote:
> Hi Doug,
>
> Op 13-01-13 04:30, Doug Barton schreef:
>> Do y'all have anything to do with that site? It gives all kinds of
>> warnings in Firefox, like the use of an insecure signature algorithm,
>> and the fact that the cert is for *.nlnetlabs.nl.
>
> It also has *.net-dns.org in the "X509v3 Subject Alternative Name" part
> of the certificate.
>
> When you have CAcert.org's root certificate in your CA repository, it
> validates. At least Debian and Ubuntu have it in the ca-certificates
> package.

I use Ubuntu for my desktop. With Firefox (which doesn't have the cacert 
root) it gives a warning. With Chromium it doesn't give a warning, but 
the page renders differently using https:// than when you don't.

Check out the URL below for more info.

https://sslcheck.globalsign.com/en_GB/sslcheck?host=www.net-dns.org#213.154.224.135

> Also TLSA records confirming the certificate are present in the
> net-dns.org zone (which is itself dnssec signed):

Awesome, and irrelevant for 99.999% of Internet users. :)

Doug



From Willem at NLnetLabs.nl  Sun Jan 13 22:07:29 2013
From: Willem at NLnetLabs.nl (Willem Toorop)
Date: Sun, 13 Jan 2013 23:07:29 +0100
Subject: [net-dns-users] SSL cert on www.net-dns.org
In-Reply-To: <50F3102E.8010306@dougbarton.us>
References: <50F22A4E.1030705@dougbarton.us> <50F2A0FD.8000909@NLnetLabs.nl>
 <50F3102E.8010306@dougbarton.us>
Message-ID: <50F33021.8040103@NLnetLabs.nl>

Op 13-01-13 20:51, Doug Barton schreef:
> I use Ubuntu for my desktop. With Firefox (which doesn't have the cacert
> root) it gives a warning. With Chromium it doesn't give a warning, but
> the page renders differently using https:// than when you don't.

Indeed. The style-sheet links all had http:// urls in them. Chromium
doesn't like non https in a https page. I replaced them by path
references which seems to do the job. You might need to do a
shift-reload to flush the cache

> Check out the URL below for more info.
> 
> https://sslcheck.globalsign.com/en_GB/sslcheck?host=www.net-dns.org#213.154.224.135

Very educational, thanks! I have addressed some issues (not the CA),
though for the majority apache has to be upgraded to 2.3+ which is still
not yet available in FreeBSD ports :(

>> Also TLSA records confirming the certificate are present in the
>> net-dns.org zone (which is itself dnssec signed):
> 
> Awesome, and irrelevant for 99.999% of Internet users. :)

Ha, but maybe only 99.99% for the DNS aware Net::DNS audience :)

-- Willem


From rwfranks at acm.org  Mon Jan 14 17:59:13 2013
From: rwfranks at acm.org (Dick Franks)
Date: Mon, 14 Jan 2013 17:59:13 +0000
Subject: [net-dns-users] How to translate the email in SOA
In-Reply-To: <50EF81D9.9010607@nsbeta.info>
References: <20121218203852.6ff2ffbb@localhost>
 <CAKW6Ri6wJMrd=FvbOAGPHrf9=jV89Aac3xuyNVjfMMG5DhYv_w@mail.gmail.com>
 <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se>
 <CAKW6Ri5nU-b4+v5KHeGMjWBB_T7GGCtkxQ7g=+pGg6_v3dgQVA@mail.gmail.com>
 <CB83E6F7-B55F-47D6-BE95-AD8695E676CB@NLnetLabs.nl>
 <CAKW6Ri6hw7aaqgNfzy0J2XK1jo7SWhY5a=eZ5EbLZqyHnuJbMw@mail.gmail.com>
 <20121220102217.779e40a5@localhost> <1419291356172025@web18h.yandex.ru>
 <168131356173141@web6f.yandex.ru>
 <CAKW6Ri4DT9=ehnPWuCkTmLfwtkVBQo+9uR37AVgvH50N1ZE=vg@mail.gmail.com>
 <6FCB85E4-01F5-4D68-B422-7D3F89F76907@kirei.se>
 <172F7E4B-0FCF-42B5-97AE-57A355D261E0@frobbit.se>
 <0ltxqrhagg.fsf@wjh.hardakers.net>
 <8B8A71C4-920D-4F93-A3C9-C7477EEF1547@iis.se>
 <42B8BEC1-69A9-4FC1-AF1E-12839E87DF70@frobbit.se>
 <50EF81D9.9010607@nsbeta.info>
Message-ID: <CAKW6Ri75vfqDbwW-J+zh53c7p7DpCjUmqt0PxdaKAdE3GFc8rA@mail.gmail.com>

Now I see the full picture!

On 11 January 2013 03:07, Feng He <fenghe at nsbeta.info> wrote:
[snip]
>
> I have been using nsupdate (which is called as an external command within
> Perl) to update the SOA record, so how to commit the encoded email string?

So the real issue is the inflexible RR parsing in nsupdate.

The solution is to produce a single line complete SOA record without
the brackets and other clutter which so upsets nsupdate.
See script example below.

Dick
--

  #!/usr/bin/perl

  use Net::DNS 0.71;

  my $resolver = new Net::DNS::Resolver();

  my $example = 'nsbeta.info';
  my $reply = $resolver->send( $example, 'SOA' ) || die 'no reply';
  my ($soa) = grep { $_->type eq 'SOA' } $reply->answer;

  $soa->rname( 'Feng He <Feng.He at nsbeta.info>' );

  print $soa->rname, "\n";

  print unformat( $soa->string ), "\n";


  sub unformat {
      join ' ', grep defined && length, split
/("[^"]*")|;[^\n]*|[()]|\s+/, shift;
  }


From marco.davids at sidn.nl  Tue Jan 15 11:59:28 2013
From: marco.davids at sidn.nl (Marco Davids (SIDN))
Date: Tue, 15 Jan 2013 12:59:28 +0100
Subject: [net-dns-users] SSL cert on www.net-dns.org
In-Reply-To: <50F33021.8040103@NLnetLabs.nl>
References: <50F22A4E.1030705@dougbarton.us> <50F2A0FD.8000909@NLnetLabs.nl>
 <50F3102E.8010306@dougbarton.us> <50F33021.8040103@NLnetLabs.nl>
Message-ID: <50F544A0.7000504@sidn.nl>

Willem,

On 01/13/13 23:07, Willem Toorop wrote:

>> Check out the URL below for more info.
>>
>> https://sslcheck.globalsign.com/en_GB/sslcheck?host=www.net-dns.org#213.154.224.135
> 
> Very educational, thanks! I have addressed some issues (not the CA),

Ken je deze?

http://www.networking4all.com/nl/helpdesk/tools/site+check/report/?fqdn=www.net-dns.org&protocol=https

--
Marco




From dhyan at nataraj.su  Wed Jan 16 10:24:34 2013
From: dhyan at nataraj.su (Nikolay Shaplov)
Date: Wed, 16 Jan 2013 14:24:34 +0400
Subject: [net-dns-users] DS with Digest::GOST, patch proposal
Message-ID: <201301161424.34158.dhyan@nataraj.su>

Hi!

As you may be know in Russia we use vodka for drinking, bear and balalaika for 
entertainment and GOST for encryption.

There is RFC 5933 which defines using of GOST digest for DS record.

Also in CPAN there is proper Digest::GOST module that provides GOST digest 
with proper CryptoPro presets.

For our purposes I've created a modification of Net::DNS::Sec That implements 
Digest type 3. A patch for Net::DNS::SEC 0.16 is in attachment.

Would you like to apply this patch to future release? 
I can do some modifications if necessary (may be you would like to do Digest 3 
optional and do not use Digest::GOST right at the beginning of the module or 
something)
Also I can provide proper .t modification

Here in attachment there is also a test that I use in our installation, it is 
based on RFC 5933 example and works well for me.

There would be great to have this patch right into cpan package and get rid of 
manual modifications...
-------------- next part --------------
diff -ur orig/Net/DNS/RR/DS.pm mod/Net/DNS/RR/DS.pm
--- orig/Net/DNS/RR/DS.pm       2010-03-12 16:13:42.000000000 +0300
+++ mod/Net/DNS/RR/DS.pm        2013-01-16 14:01:13.000000000 +0400
@@ -10,6 +10,7 @@
 use Carp;

 use Digest::SHA  qw(sha1 sha1_hex sha256 sha256_hex );
+use Digest::GOST::CryptoPro qw(gost gost_hex);

 BEGIN {

@@ -167,6 +168,7 @@

     if ($args{"digtype"}){
        $self->{"digtype"}=2 if Net::DNS::SEC->digtype($args{"digtype"})==2;
+       $self->{"digtype"}=3 if Net::DNS::SEC->digtype($args{"digtype"})==3;
     }

     $self->{"name"}=$keyrr->name;  # Label is per definition the same as
@@ -217,7 +219,10 @@
     }elsif($self->{"digtype"}==2){
        $self->{"digestbin"}=  sha256($data);
        $self->{"digest"}= uc(sha256_hex($data));
-    }else{
+    } elsif ($self->{"digtype"}==3){
+       $self->{"digestbin"}=  gost ($data);
+       $self->{"digest"}= uc(gost_hex($data));
+    } else {
        return undef;
     }

diff -ur orig/Net/DNS/SEC.pm mod/Net/DNS/SEC.pm
--- orig/Net/DNS/SEC.pm 2010-03-12 16:14:33.000000000 +0300
+++ mod/Net/DNS/SEC.pm  2012-09-25 19:13:14.000000000 +0400
@@ -286,6 +286,7 @@
     my %digestbyname= (
                        "SHA1"             => 1,
                        "SHA256"           => 2,
+                       "GOST"             => 3,
                        );


-------------- next part --------------
#!/usr/bin/perl
use strict;
use warnings;

use Test::More tests => 4;

use_ok('Net::DNS::RR::DS');

=pod
??????. RFC 5933
      example.net. 86400   DNSKEY  257 3 12 (
                                   LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO
                                   gEYqYS/rlh2Mf+BRAY3QHPbwoPh2fkDKBroF
                                   SRGR7ZYcx+YIQw==
                                   ) ; key id = 40692

   The DS RR will be

      example.net. 3600 IN DS 40692 12 3 (
                22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B
                2071398F )
=cut


my $record_as_string =
"      example.net. 86400   DNSKEY  257 3 12 (
                                   LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO
                                   gEYqYS/rlh2Mf+BRAY3QHPbwoPh2fkDKBroF
                                   SRGR7ZYcx+YIQw==
                                   ) ; key id = 40692
";


ok my $dnskey_rr = Net::DNS::RR->new_from_string($record_as_string);
ok my $dsrr = create Net::DNS::RR::DS($dnskey_rr, digtype => 3);

is $dsrr->digest, '22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B2071398F';

From miek at miek.nl  Wed Jan 16 10:54:06 2013
From: miek at miek.nl (Miek Gieben)
Date: Wed, 16 Jan 2013 11:54:06 +0100
Subject: [net-dns-users] DS with Digest::GOST, patch proposal
In-Reply-To: <201301161424.34158.dhyan@nataraj.su>
References: <201301161424.34158.dhyan@nataraj.su>
Message-ID: <20130116105406.GF11541@miek.nl>

[ Quoting <dhyan at nataraj.su> in "[net-dns-users] DS with Digest::GOS..." ]
> +++ mod/Net/DNS/SEC.pm  2012-09-25 19:13:14.000000000 +0400
> @@ -286,6 +286,7 @@
>      my %digestbyname= (
>                         "SHA1"             => 1,
>                         "SHA256"           => 2,
> +                       "GOST"             => 3,
>                         );

<bikeshedding>

sadly rfc 5933 does not provide a mnemonic for the value 3, but 'GOST' seems
overly broad.

(What mnemonic has been chosen by BIND9?)

</bikeshedding>

grtz Miek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130116/f9fc2168/attachment.bin>

From beldmit at gmail.com  Wed Jan 16 11:12:20 2013
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Wed, 16 Jan 2013 15:12:20 +0400
Subject: [net-dns-users] DS with Digest::GOST, patch proposal
In-Reply-To: <20130116105406.GF11541@miek.nl>
References: <201301161424.34158.dhyan@nataraj.su>
 <20130116105406.GF11541@miek.nl>
Message-ID: <CADqLbzJ0aK6s1shhtjexVDv1sDf80iTkNGCnPDLq2EScRjQh+A@mail.gmail.com>

Greetings!

The RFC 5933 refers to the RFC 5831, where the diges alg is named GOST R
34.11-94.
In OpenSSL it is named md_gost94.


On Wed, Jan 16, 2013 at 2:54 PM, Miek Gieben <miek at miek.nl> wrote:

> [ Quoting <dhyan at nataraj.su> in "[net-dns-users] DS with Digest::GOS..." ]
> > +++ mod/Net/DNS/SEC.pm  2012-09-25 19:13:14.000000000 +0400
> > @@ -286,6 +286,7 @@
> >      my %digestbyname= (
> >                         "SHA1"             => 1,
> >                         "SHA256"           => 2,
> > +                       "GOST"             => 3,
> >                         );
>
> <bikeshedding>
>
> sadly rfc 5933 does not provide a mnemonic for the value 3, but 'GOST'
> seems
> overly broad.
>
> (What mnemonic has been chosen by BIND9?)
>
> </bikeshedding>
>
> grtz Miek
>
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>



-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130116/260181b7/attachment.htm>

From dwessels at verisign.com  Wed Jan 16 17:46:54 2013
From: dwessels at verisign.com (Wessels, Duane)
Date: Wed, 16 Jan 2013 09:46:54 -0800
Subject: [net-dns-users] GOST signature validation
Message-ID: <3C7C3A1C-0E7E-42DE-AFBC-478ACDFF7A31@verisign.com>

On the subject of GOST, for what it's worth I also have code to validate GOST RRSIGs.
Since there doesn't seem to be a perl module that already does this, I resorted to 
using the Inline module and calling the openssl library functions.  Its not very
pretty but it does work.  I can share it if there is interest, but I don't think it
fits very well into the Net::DNS::SEC package as-is.

DW


From dwessels at verisign.com  Wed Jan 16 17:39:01 2013
From: dwessels at verisign.com (Wessels, Duane)
Date: Wed, 16 Jan 2013 09:39:01 -0800
Subject: [net-dns-users] DS with Digest::GOST, patch proposal
In-Reply-To: <CADqLbzJ0aK6s1shhtjexVDv1sDf80iTkNGCnPDLq2EScRjQh+A@mail.gmail.com>
References: <201301161424.34158.dhyan@nataraj.su>
 <20130116105406.GF11541@miek.nl>
 <CADqLbzJ0aK6s1shhtjexVDv1sDf80iTkNGCnPDLq2EScRjQh+A@mail.gmail.com>
Message-ID: <F12CC336-6329-47A4-A646-6EEBAE711D0B@verisign.com>

I'd like to see support for GOST DS records as well.  I submitted a bug/patch a few
weeks ago (https://rt.cpan.org/Ticket/Display.html?id=81289), but its a little
out of date now.  I'll attach my current patch below, which also:

  - Makes Digest::GOST optional
  - Fixes what I think was a problem with Digest::BubbleBabble being optional
  - Adds SHA384 DS records

DW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: net-dns-sec-gost.patch
Type: application/octet-stream
Size: 2793 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130116/831215d7/attachment.obj>

From dhyan at nataraj.su  Thu Jan 17 05:32:44 2013
From: dhyan at nataraj.su (Nikolay Shaplov)
Date: Thu, 17 Jan 2013 09:32:44 +0400
Subject: [net-dns-users] GOST signature validation
In-Reply-To: <3C7C3A1C-0E7E-42DE-AFBC-478ACDFF7A31@verisign.com>
References: <3C7C3A1C-0E7E-42DE-AFBC-478ACDFF7A31@verisign.com>
Message-ID: <201301170932.44500.dhyan@nataraj.su>


> On the subject of GOST, for what it's worth I also have code to validate
> GOST RRSIGs. Since there doesn't seem to be a perl module that already
> does this, I resorted to using the Inline module and calling the openssl
> library functions.  Its not very pretty but it does work.  I can share it
> if there is interest, but I don't think it fits very well into the
> Net::DNS::SEC package as-is.

I think the best way to do this would be to create Crypt::OpenSSL::GOST module 
the way most Crypt::OpenSSL::* module exists and then use this module in 
Net::DNS::SEC. 

At least this is what I was going to do in distant future. (We do not really 
use GOST RRSIGs and we do not have proper OpenSSL with GOST support in our 
linux distro out of box, so I am not in a hurry)


From hsalgado at nic.cl  Tue Feb 26 14:49:21 2013
From: hsalgado at nic.cl (Hugo Salgado)
Date: Tue, 26 Feb 2013 11:49:21 -0300
Subject: [net-dns-users] CD flag in Net::DNS::Resolver
Message-ID: <512CCB71.9080103@nic.cl>

Hi. I'm trying to setup a resolver object with "checking disabled", to
avoid dnssec checks.

In the docs it seems to be a "cdflag" which must be set in addition
to "dnssec", but it's not working.

Reading the source, it seems to be that "cdflag" is not promoted as a
"public_attr". I added a single line:

--------
@@ -151,7 +151,6 @@
 	persistent_udp
 	dnssec
 	ignqrid
+	cdflag
 );
--------

in Resolver/Base.pm ($Id: Base.pm 1094 2012-12-27 21:35:09Z willem), and
now works.

Regards,

Hugo

ps: I've just filed a ticket in cpan
    https://rt.cpan.org/Ticket/Display.html?id=83642


From blblack at gmail.com  Wed Apr 10 15:41:58 2013
From: blblack at gmail.com (Brandon Black)
Date: Wed, 10 Apr 2013 10:41:58 -0500
Subject: [net-dns-users] Post-0.68 changes, again
Message-ID: <CAHke7bQKDsAwvoxp4a2AttJTwAEueSB6Tzov45QSw-E=_9iR_w@mail.gmail.com>

I've seen there's a couple older threads on this from Dec/Jan, but I'm late
to the party.  My DNS daemon ( https://github.com/blblack/gdnsd ) was
relying heavily on Net::DNS in its testsuite, and was compatible with
releases 0.63 -> 0.68.  As you can imagine, the testsuite intentionally
generates all sorts of invalid requests and wants fine-grained control over
every aspect of the packets constructed.  This was working fine (a few
little hacks here and there aside) up through 0.68.  I wasn't even aware of
the December release activity until very recently, when a few Linux distros
upgraded their perl-Net-DNS packages to 0.72 and users started complaining
about testsuite failures.

As mentioned in the past threads, the changes are pretty nasty from my
perspective.  You've removed a bunch of previous functionality for DNS
packet manipulation, various APIs are now deprecated or broken without any
significant overlap/warning period, etc.  I don't see how Net::DNS 0.69+
can do the job I need it to do (which 0.68 was doing a great job of) at
all.  Even if 0.69+ could do it, I doubt I could cleanly make my testsuite
support any kind of compatibility range (e.g. 0.66 -> 0.72, or really any
range that includes 0.68 + 0.69) since so many things were broken
immediately in a single release.

At this point, given there's been no real movement or apparent desire to
fix the situation upstream, I'll probably just have to include an entire
stale copy of 0.68 within my project for the foreseeable future.  It's the
distros upgrading that creates the problematic fallout here.  They may not
realize that 0.68 and 0.69 releases of the same project name have such
dramatic API breakage between them (and who could blame them?).

For future reference: it would've been better to just start a new module
name (Net::BetterDNS or something, I don't know) rather than introduce so
much breakage in a random version bump of a module with such a long
history.  Net::DNS could've been left as a deprecated 0.68 without future
maintenance or something.

-- Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130410/d268854a/attachment.htm>

From calle at init.se  Wed May 15 09:03:45 2013
From: calle at init.se (Calle Dybedahl)
Date: Wed, 15 May 2013 11:03:45 +0200
Subject: [net-dns-users] Change(s) in post-0.68 specifically problematic for
	DNSCheck
Message-ID: <8BD0E90C-44A7-49A3-95F3-52E65278D5CE@init.se>

I was asked to try and quickly list what changes in post-0.68 Net::DNS that cause problems for the DNSCheck project, and post them here. I haven't had time to look at Net::DNS-related things for some months, so unfortunately a lot ha fallen out of my active memory. But there is one thing that is a concrete problem, in that it actually removes existing functionality from our product:

Since the SOA record class now auto-parses the RNAME field, we can no longer usefully detect and report errors made by the owner of a zone when setting that field (a type of error that is quite common in real life). We need a way to get the raw string that was actually in the record, not a parsed version of it. We would strongly prefer that this way be the same as in 0.68 and earlier, so we can remove the special-case code doing different things depending on the installed version of Net::DNS that we have now. 

-- 
Calle Dybedahl
calle at init.se -*- +46 703 - 970 612






From calle at init.se  Wed May 15 09:07:28 2013
From: calle at init.se (Calle Dybedahl)
Date: Wed, 15 May 2013 11:07:28 +0200
Subject: [net-dns-users] SVN repo missing?
Message-ID: <900685AC-6FDA-4FFA-8358-DC7B47DE4A97@init.se>

The Net::DNS Subversion repository at http://www.net-dns.org/svn/net-dns seems to be inaccessible. Is it broken, did it move or what happened?

-- 
Calle Dybedahl
calle at init.se -*- +46 703 - 970 612






From Willem at NLnetLabs.nl  Wed May 15 14:47:09 2013
From: Willem at NLnetLabs.nl (Willem Toorop)
Date: Wed, 15 May 2013 16:47:09 +0200
Subject: [net-dns-users] SVN repo missing?
In-Reply-To: <900685AC-6FDA-4FFA-8358-DC7B47DE4A97@init.se>
References: <900685AC-6FDA-4FFA-8358-DC7B47DE4A97@init.se>
Message-ID: <51939FED.1040907@NLnetLabs.nl>

Down due to broken NFS mount.
Now fixed.

Op 15-05-13 11:07, Calle Dybedahl schreef:
> The Net::DNS Subversion repository at http://www.net-dns.org/svn/net-dns seems to be inaccessible. Is it broken, did it move or what happened?
> 


From clists at buxtonfamily.us  Wed May 22 19:30:33 2013
From: clists at buxtonfamily.us (Chris Buxton)
Date: Wed, 22 May 2013 12:30:33 -0700
Subject: [net-dns-users] handling unsupported record types
Message-ID: <2FF5CCBC-1306-4A58-A722-19CE33EB7525@buxtonfamily.us>

I have a script that reads zones from files on disk and also via zone transfer. Currently, when reading in data, if the script encounters a record for which Net::DNS does not implement a record type class, the script dies. The immediate case looks like this:

WKS not implemented at /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int/Net/DNS/RR.pm line 630.
new Net:NS::RR( ... ) at ./dnsdiff.pl line 300

Short of hacking Net::DNS::RR, how can I handle this without dying and without losing any records coming after the unknown record type in a zone transfer?

Regards,
Chris Buxton


From Kelly.Setzer at wnco.com  Wed May 22 20:42:48 2013
From: Kelly.Setzer at wnco.com (Kelly Setzer)
Date: Wed, 22 May 2013 15:42:48 -0500
Subject: [net-dns-users] handling unsupported record types
In-Reply-To: <2FF5CCBC-1306-4A58-A722-19CE33EB7525@buxtonfamily.us>
References: <2FF5CCBC-1306-4A58-A722-19CE33EB7525@buxtonfamily.us>
Message-ID: <FC8ABE0E5D384A489CDB16C4A8EB7783AB41EACB33@MSMAIL01.LUV.AD.SWACORP.COM>

Which version of Net::DNS?

With 0.72, I don't get this error.  Of course, it looks like the WKS record is getting parsed somehow.  The output does not match dig.

#!/usr/bin/perl
use strict;
use Net::DNS;

my $res  = Net::DNS::Resolver->new;
$res->nameservers("xaladonis02");

my @zone = $res->axfr("foo.com");

$_->print for @zone;

Script output:

foo.com.        900     IN      SOA     xaladonis02.swacorp.com. domainrequest.wnco.com. (
                                        388246610       ;serial
                                        1200            ;refresh
                                        180             ;retry
                                        1209600         ;expire
                                        3600   )        ;minimum
foo.com.        900     IN      NS      xaladonis02.swacorp.com.
bar.foo.com.    900     IN      A       10.100.10.37
sna.foo.com.    900     IN      WKS     \# 8 0a640a2606000005

Dig output:
$ dig @xaladonis02 foo.com AXFR

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_5.3 <<>> @xaladonis02 foo.com AXFR
; (1 server found)
;; global options:  printcmd
foo.com.                900     IN      SOA     xaladonis02.swacorp.com. domainrequest.wnco.com. 388246610 1200 180 1209600 3600
foo.com.                900     IN      NS      xaladonis02.swacorp.com.
bar.foo.com.            900     IN      A       10.100.10.37
sna.foo.com.            900     IN      WKS     10.100.10.38 6 21 23
foo.com.                900     IN      SOA     xaladonis02.swacorp.com. domainrequest.wnco.com. 388246610 1200 180 1209600 3600
;; Query time: 2 msec
;; SERVER: 10.35.22.203#53(10.35.22.203)
;; WHEN: Wed May 22 15:41:41 2013
;; XFR size: 5 records (messages 1)

thanks,
Kelly

-----Original Message-----
From: net-dns-users-bounces at nlnetlabs.nl [mailto:net-dns-users-bounces at nlnetlabs.nl] On Behalf Of Chris Buxton
Sent: Wednesday, May 22, 2013 2:31 PM
To: net-dns-users at nlnetlabs.nl
Subject: [net-dns-users] handling unsupported record types

I have a script that reads zones from files on disk and also via zone transfer. Currently, when reading in data, if the script encounters a record for which Net::DNS does not implement a record type class, the script dies. The immediate case looks like this:

WKS not implemented at /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int/Net/DNS/RR.pm line 630.
new Net:NS::RR( ... ) at ./dnsdiff.pl line 300

Short of hacking Net::DNS::RR, how can I handle this without dying and without losing any records coming after the unknown record type in a zone transfer?

Regards,
Chris Buxton
_______________________________________________
net-dns-users mailing list
net-dns-users at nlnetlabs.nl
https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
******* CONFIDENTIALITY NOTICE *******
This e-mail message and all attachments transmitted with it may
contain legally privileged and confidential information intended
solely for the use of the addressee. If the reader of this message
is not the intended recipient, you are hereby notified that any
reading, dissemination, distribution, copying, or other use of this
message or its attachments is strictly prohibited. If you have
received this message in error, please notify the sender
immediately and delete this message from your system. Thank you.



From rwfranks at acm.org  Wed May 22 21:30:20 2013
From: rwfranks at acm.org (Dick Franks)
Date: Wed, 22 May 2013 22:30:20 +0100
Subject: [net-dns-users] handling unsupported record types
In-Reply-To: <2FF5CCBC-1306-4A58-A722-19CE33EB7525@buxtonfamily.us>
References: <2FF5CCBC-1306-4A58-A722-19CE33EB7525@buxtonfamily.us>
Message-ID: <CAKW6Ri4K6QKd5Hkvezw_PZqkqn1DR9=_r2BhE74CDf+ouj=79w@mail.gmail.com>

Chris,

Revision of Net::DNS?

I do not understand why a zone transfer would fail in the way you describe.

Are you using Net::DNS::ZoneFile to read your zone data from disk?

There should be no need to hack RR.pm.
Your script needs to handle the exception condition.

    my $zone = new Net::DNS::ZoneFile( $filename );

    loop { # through RRs in zone file

        my $rr = eval { $zone->read; };        # which knows about
multi-line RRs
        if ( $@ ) {
            warn $@;
            next;
        }

        last unless $rr;

        # process RR

    }


Regards

Dick Franks

--


On 22 May 2013 20:30, Chris Buxton <clists at buxtonfamily.us> wrote:

> I have a script that reads zones from files on disk and also via zone
> transfer. Currently, when reading in data, if the script encounters a
> record for which Net::DNS does not implement a record type class, the
> script dies. The immediate case looks like this:
>
> WKS not implemented at
> /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int/Net/DNS/RR.pm line
> 630.
> new Net:NS::RR( ... ) at ./dnsdiff.pl line 300
>
> Short of hacking Net::DNS::RR, how can I handle this without dying and
> without losing any records coming after the unknown record type in a zone
> transfer?
>
> Regards,
> Chris Buxton
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130522/a974bf99/attachment.htm>

From clists at buxtonfamily.us  Fri May 31 21:15:26 2013
From: clists at buxtonfamily.us (Chris Buxton)
Date: Fri, 31 May 2013 14:15:26 -0700
Subject: [net-dns-users] handling unsupported record types
In-Reply-To: <CAKW6Ri4K6QKd5Hkvezw_PZqkqn1DR9=_r2BhE74CDf+ouj=79w@mail.gmail.com>
References: <2FF5CCBC-1306-4A58-A722-19CE33EB7525@buxtonfamily.us>
 <CAKW6Ri4K6QKd5Hkvezw_PZqkqn1DR9=_r2BhE74CDf+ouj=79w@mail.gmail.com>
Message-ID: <121067EE-905E-466E-8150-C3B7C0E6DB9E@buxtonfamily.us>

The problem occurred with Net::DNS 0.72. I was not using Net::DNS::ZoneFile to read the zone from disk.

After reading these comments, I tried the script locally, on my development workstation, and it worked fine. On the client's workstation, it failed, despite having the same version of Net::DNS. I have no explanation.

Thanks for the guidance.
Chris Buxton

On May 22, 2013, at 2:30 PM, Dick Franks <rwfranks at acm.org> wrote:

> Chris,
> 
> Revision of Net::DNS?
> 
> I do not understand why a zone transfer would fail in the way you describe.
> 
> Are you using Net::DNS::ZoneFile to read your zone data from disk?
> 
> There should be no need to hack RR.pm.
> Your script needs to handle the exception condition.
> 
>     my $zone = new Net::DNS::ZoneFile( $filename );
>     
>     loop { # through RRs in zone file
> 
>         my $rr = eval { $zone->read; };        # which knows about multi-line RRs
>         if ( $@ ) {
>             warn $@;
>             next;
>         }
> 
>         last unless $rr;
> 
>         # process RR
> 
>     }
> 
> 
> Regards
> 
> Dick Franks
> 
> --
> 
> 
> On 22 May 2013 20:30, Chris Buxton <clists at buxtonfamily.us> wrote:
> I have a script that reads zones from files on disk and also via zone transfer. Currently, when reading in data, if the script encounters a record for which Net::DNS does not implement a record type class, the script dies. The immediate case looks like this:
> 
> WKS not implemented at /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int/Net/DNS/RR.pm line 630.
> new Net:NS::RR( ... ) at ./dnsdiff.pl line 300
> 
> Short of hacking Net::DNS::RR, how can I handle this without dying and without losing any records coming after the unknown record type in a zone transfer?
> 
> Regards,
> Chris Buxton
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
> 
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130531/cec484de/attachment.htm>

From rwfranks at acm.org  Fri May 31 22:02:42 2013
From: rwfranks at acm.org (Dick Franks)
Date: Fri, 31 May 2013 23:02:42 +0100
Subject: [net-dns-users] handling unsupported record types
In-Reply-To: <121067EE-905E-466E-8150-C3B7C0E6DB9E@buxtonfamily.us>
References: <2FF5CCBC-1306-4A58-A722-19CE33EB7525@buxtonfamily.us>
 <CAKW6Ri4K6QKd5Hkvezw_PZqkqn1DR9=_r2BhE74CDf+ouj=79w@mail.gmail.com>
 <121067EE-905E-466E-8150-C3B7C0E6DB9E@buxtonfamily.us>
Message-ID: <CAKW6Ri7H5O5kCVkKXpqaO5Aqd-Fnumef4Gq-2ahijkB3=ckiGw@mail.gmail.com>

Please can you let us know platform and perl revision info.

Others have reported issues with eval{...} and threads

Dick Franks

--


On 31 May 2013 22:15, Chris Buxton <clists at buxtonfamily.us> wrote:

> The problem occurred with Net::DNS 0.72. I was not using
> Net::DNS::ZoneFile to read the zone from disk.
>
> After reading these comments, I tried the script locally, on my
> development workstation, and it worked fine. On the client's workstation,
> it failed, despite having the same version of Net::DNS. I have no
> explanation.
>
> Thanks for the guidance.
> Chris Buxton
>
> On May 22, 2013, at 2:30 PM, Dick Franks <rwfranks at acm.org> wrote:
>
> Chris,
>
> Revision of Net::DNS?
>
> I do not understand why a zone transfer would fail in the way you describe.
>
> Are you using Net::DNS::ZoneFile to read your zone data from disk?
>
> There should be no need to hack RR.pm.
> Your script needs to handle the exception condition.
>
>     my $zone = new Net::DNS::ZoneFile( $filename );
>
>     loop { # through RRs in zone file
>
>         my $rr = eval { $zone->read; };        # which knows about
> multi-line RRs
>         if ( $@ ) {
>             warn $@;
>             next;
>         }
>
>         last unless $rr;
>
>         # process RR
>
>     }
>
>
> Regards
>
> Dick Franks
>
> --
>
>
> On 22 May 2013 20:30, Chris Buxton <clists at buxtonfamily.us> wrote:
>
>> I have a script that reads zones from files on disk and also via zone
>> transfer. Currently, when reading in data, if the script encounters a
>> record for which Net::DNS does not implement a record type class, the
>> script dies. The immediate case looks like this:
>>
>> WKS not implemented at
>> /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int/Net/DNS/RR.pm line
>> 630.
>> new Net:NS::RR( ... ) at ./dnsdiff.pl line 300
>>
>> Short of hacking Net::DNS::RR, how can I handle this without dying and
>> without losing any records coming after the unknown record type in a zone
>> transfer?
>>
>> Regards,
>> Chris Buxton
>> _______________________________________________
>> net-dns-users mailing list
>> net-dns-users at nlnetlabs.nl
>> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>>
>
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
>
>
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130531/7db24dd3/attachment.htm>

From clists at buxtonfamily.us  Fri May 31 22:08:42 2013
From: clists at buxtonfamily.us (Chris Buxton)
Date: Fri, 31 May 2013 15:08:42 -0700
Subject: [net-dns-users] handling unsupported record types
In-Reply-To: <CAKW6Ri7H5O5kCVkKXpqaO5Aqd-Fnumef4Gq-2ahijkB3=ckiGw@mail.gmail.com>
References: <2FF5CCBC-1306-4A58-A722-19CE33EB7525@buxtonfamily.us>
 <CAKW6Ri4K6QKd5Hkvezw_PZqkqn1DR9=_r2BhE74CDf+ouj=79w@mail.gmail.com>
 <121067EE-905E-466E-8150-C3B7C0E6DB9E@buxtonfamily.us>
 <CAKW6Ri7H5O5kCVkKXpqaO5Aqd-Fnumef4Gq-2ahijkB3=ckiGw@mail.gmail.com>
Message-ID: <BFFBD7A8-0C3E-4E74-AF43-27A4E2E11C9D@buxtonfamily.us>

Dick,

I'm not using eval (or wasn't until I saw your code sample), and this script in particular is not threaded.

My workstation is Mac OS X 10.8. The client was using Windows and ActivePerl (latest).

Regards,
Chris Buxton

On May 31, 2013, at 3:02 PM, Dick Franks <rwfranks at acm.org> wrote:

> Please can you let us know platform and perl revision info.
> 
> Others have reported issues with eval{...} and threads
> 
> Dick Franks
> 
> --
> 
> 
> On 31 May 2013 22:15, Chris Buxton <clists at buxtonfamily.us> wrote:
> The problem occurred with Net::DNS 0.72. I was not using Net::DNS::ZoneFile to read the zone from disk.
> 
> After reading these comments, I tried the script locally, on my development workstation, and it worked fine. On the client's workstation, it failed, despite having the same version of Net::DNS. I have no explanation.
> 
> Thanks for the guidance.
> Chris Buxton
> 
> On May 22, 2013, at 2:30 PM, Dick Franks <rwfranks at acm.org> wrote:
> 
>> Chris,
>> 
>> Revision of Net::DNS?
>> 
>> I do not understand why a zone transfer would fail in the way you describe.
>> 
>> Are you using Net::DNS::ZoneFile to read your zone data from disk?
>> 
>> There should be no need to hack RR.pm.
>> Your script needs to handle the exception condition.
>> 
>>     my $zone = new Net::DNS::ZoneFile( $filename );
>>     
>>     loop { # through RRs in zone file
>> 
>>         my $rr = eval { $zone->read; };        # which knows about multi-line RRs
>>         if ( $@ ) {
>>             warn $@;
>>             next;
>>         }
>> 
>>         last unless $rr;
>> 
>>         # process RR
>> 
>>     }
>> 
>> 
>> Regards
>> 
>> Dick Franks
>> 
>> --
>> 
>> 
>> On 22 May 2013 20:30, Chris Buxton <clists at buxtonfamily.us> wrote:
>> I have a script that reads zones from files on disk and also via zone transfer. Currently, when reading in data, if the script encounters a record for which Net::DNS does not implement a record type class, the script dies. The immediate case looks like this:
>> 
>> WKS not implemented at /usr/lib/perl5/site_perl/5.14/i686-cygwin-threads-64int/Net/DNS/RR.pm line 630.
>> new Net:NS::RR( ... ) at ./dnsdiff.pl line 300
>> 
>> Short of hacking Net::DNS::RR, how can I handle this without dying and without losing any records coming after the unknown record type in a zone transfer?
>> 
>> Regards,
>> Chris Buxton
>> _______________________________________________
>> net-dns-users mailing list
>> net-dns-users at nlnetlabs.nl
>> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>> 
>> _______________________________________________
>> net-dns-users mailing list
>> net-dns-users at nlnetlabs.nl
>> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
> 
> 
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
> 
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130531/ec29b65c/attachment.htm>

From rwfranks at acm.org  Fri May 31 22:24:10 2013
From: rwfranks at acm.org (Dick Franks)
Date: Fri, 31 May 2013 23:24:10 +0100
Subject: [net-dns-users] handling unsupported record types
In-Reply-To: <BFFBD7A8-0C3E-4E74-AF43-27A4E2E11C9D@buxtonfamily.us>
References: <2FF5CCBC-1306-4A58-A722-19CE33EB7525@buxtonfamily.us>
 <CAKW6Ri4K6QKd5Hkvezw_PZqkqn1DR9=_r2BhE74CDf+ouj=79w@mail.gmail.com>
 <121067EE-905E-466E-8150-C3B7C0E6DB9E@buxtonfamily.us>
 <CAKW6Ri7H5O5kCVkKXpqaO5Aqd-Fnumef4Gq-2ahijkB3=ckiGw@mail.gmail.com>
 <BFFBD7A8-0C3E-4E74-AF43-27A4E2E11C9D@buxtonfamily.us>
Message-ID: <CAKW6Ri5X1LJwzvOm9Zjc8D4+4aYhkj0FOPC=dVnZdNri9Tbm+A@mail.gmail.com>

On 31 May 2013 23:08, Chris Buxton <clists at buxtonfamily.us> wrote
[snip]

> I'm not using eval (or wasn't until I saw your code sample), and this
> script in particular is not threaded.
>
but there are eval blocks which trap and reraise exceptions inside Net::DNS


> My workstation is Mac OS X 10.8. The client was using Windows and
> ActivePerl (latest).
>
thanks

Regards
Dick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130531/743ac65b/attachment.htm>

From clists at buxtonfamily.us  Thu Jun 13 18:08:56 2013
From: clists at buxtonfamily.us (Chris Buxton)
Date: Thu, 13 Jun 2013 11:08:56 -0700
Subject: [net-dns-users] Bug report: Net::DNS::Zonefile fails to read
	escaped parenthesis
Message-ID: <3C89B9F1-711B-4F48-9435-681EF376619F@buxtonfamily.us>

Net::DNS::Zonefile hangs when reading this record (anonymized from original record):

144.2.0.192.in-addr.arpa.		      900 IN PTR	ilouse03146p0\(.example.com.

I have several more examples of this in a dataset from a current customer.

Chris Buxton




From rharolde at umich.edu  Tue Jun 18 12:41:12 2013
From: rharolde at umich.edu (Bob Harold)
Date: Tue, 18 Jun 2013 08:41:12 -0400
Subject: [net-dns-users] Fwd: Bug report: Net::DNS::Zonefile fails to read
	escaped parenthesis
In-Reply-To: <CA+nkc8Apsb=cqT_OKigA71w7dc3m4-uAxDLWpCMs4fE1TYZL+w@mail.gmail.com>
References: <CA+nkc8Apsb=cqT_OKigA71w7dc3m4-uAxDLWpCMs4fE1TYZL+w@mail.gmail.com>
Message-ID: <CA+nkc8COnSv++pv6wSOrLJLgBRnwOZXvDNDK8m_d9hMCiu_vWw@mail.gmail.com>

"\" and "(" are invalid characters in DNS names.
See RFC 952 and 1123.

While it might be nice for Net::DNS::Zonefile to handle them, it is really
not necessary.
So I would consider this an odd feature request, not a bug.

-- 
Bob

On Fri, Jun 14, 2013 at 6:00 AM, <net-dns-users-request at nlnetlabs.nl> wrote:

>
> Date: Thu, 13 Jun 2013 11:08:56 -0700
> From: Chris Buxton <clists at buxtonfamily.us>
> To: "net-dns-users at nlnetlabs.nl" <net-dns-users at nlnetlabs.nl>
> Subject: [net-dns-users] Bug report: Net::DNS::Zonefile fails to read
>         escaped parenthesis
> Message-ID: <3C89B9F1-711B-4F48-9435-681EF376619F at buxtonfamily.us>
> Content-Type: text/plain; charset=us-ascii
>
> Net::DNS::Zonefile hangs when reading this record (anonymized from
> original record):
>
> 144.2.0.192.in-addr.arpa.                     900 IN PTR
>  ilouse03146p0\(.example.com.
>
> I have several more examples of this in a dataset from a current customer.
>
> Chris Buxton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130618/20ff3f2d/attachment.htm>

From miek at miek.nl  Tue Jun 18 12:51:41 2013
From: miek at miek.nl (Miek Gieben)
Date: Tue, 18 Jun 2013 13:51:41 +0100
Subject: [net-dns-users] Fwd: Bug report: Net::DNS::Zonefile fails to
 read escaped parenthesis
In-Reply-To: <CA+nkc8COnSv++pv6wSOrLJLgBRnwOZXvDNDK8m_d9hMCiu_vWw@mail.gmail.com>
References: <CA+nkc8Apsb=cqT_OKigA71w7dc3m4-uAxDLWpCMs4fE1TYZL+w@mail.gmail.com>
 <CA+nkc8COnSv++pv6wSOrLJLgBRnwOZXvDNDK8m_d9hMCiu_vWw@mail.gmail.com>
Message-ID: <CAJrXxANThuvPxV_yHYuC1rLZg19K4nJv9ecqWBTiEcOr7v18Pg@mail.gmail.com>

I think RFC 1035 states that you can pretty much include any character as
long as it is escaped with a backslash. To me this looks like a bug in
Net::DNS

Grtz Miek
On 18 Jun 2013 13:44, "Bob Harold" <rharolde at umich.edu> wrote:

>
> "\" and "(" are invalid characters in DNS names.
> See RFC 952 and 1123.
>
> While it might be nice for Net::DNS::Zonefile to handle them, it is really
> not necessary.
> So I would consider this an odd feature request, not a bug.
>
> --
> Bob
>
> On Fri, Jun 14, 2013 at 6:00 AM, <net-dns-users-request at nlnetlabs.nl>wrote:
>
>>
>> Date: Thu, 13 Jun 2013 11:08:56 -0700
>> From: Chris Buxton <clists at buxtonfamily.us>
>> To: "net-dns-users at nlnetlabs.nl" <net-dns-users at nlnetlabs.nl>
>> Subject: [net-dns-users] Bug report: Net::DNS::Zonefile fails to read
>>         escaped parenthesis
>> Message-ID: <3C89B9F1-711B-4F48-9435-681EF376619F at buxtonfamily.us>
>> Content-Type: text/plain; charset=us-ascii
>>
>> Net::DNS::Zonefile hangs when reading this record (anonymized from
>> original record):
>>
>> 144.2.0.192.in-addr.arpa.                     900 IN PTR
>>  ilouse03146p0\(.example.com.
>>
>> I have several more examples of this in a dataset from a current customer.
>>
>> Chris Buxton
>>
>
>
>
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130618/ad785874/attachment.htm>

From rharolde at umich.edu  Tue Jun 18 13:34:16 2013
From: rharolde at umich.edu (Bob Harold)
Date: Tue, 18 Jun 2013 09:34:16 -0400
Subject: [net-dns-users] Fwd: Bug report: Net::DNS::Zonefile fails to
 read escaped parenthesis
In-Reply-To: <CAJrXxANThuvPxV_yHYuC1rLZg19K4nJv9ecqWBTiEcOr7v18Pg@mail.gmail.com>
References: <CA+nkc8Apsb=cqT_OKigA71w7dc3m4-uAxDLWpCMs4fE1TYZL+w@mail.gmail.com>
 <CA+nkc8COnSv++pv6wSOrLJLgBRnwOZXvDNDK8m_d9hMCiu_vWw@mail.gmail.com>
 <CAJrXxANThuvPxV_yHYuC1rLZg19K4nJv9ecqWBTiEcOr7v18Pg@mail.gmail.com>
Message-ID: <CA+nkc8CYXKCULDhzLckAJkW2MSnGM31nKJq8=pB1NObw_5CjeQ@mail.gmail.com>

Section 2.3.1 restricts domain names to letters, digits, and hyphen, but
the wording is pretty wishy-washy "Preferred Name Syntax".
Section 5.1 allows files to use \X and \DDD but it is not clear if that
includes domain names, or is for other fields, like text records, soa email
fields (the example given), SPF records, etc.
The caveat is still that non-standard domain names won't work with all
applications, and are best avoided.  Use at your own risk.



-- 
Bob Harold
hostmaster, UMnet, ITcom
Information and Technology Services (ITS)
rharolde at umich.edu
734-647-6524 desk


On Tue, Jun 18, 2013 at 8:51 AM, Miek Gieben <miek at miek.nl> wrote:

> I think RFC 1035 states that you can pretty much include any character as
> long as it is escaped with a backslash. To me this looks like a bug in
> Net::DNS
>
> Grtz Miek
> On 18 Jun 2013 13:44, "Bob Harold" <rharolde at umich.edu> wrote:
>
>>
>> "\" and "(" are invalid characters in DNS names.
>> See RFC 952 and 1123.
>>
>> While it might be nice for Net::DNS::Zonefile to handle them, it is
>> really not necessary.
>> So I would consider this an odd feature request, not a bug.
>>
>> --
>> Bob
>>
>> On Fri, Jun 14, 2013 at 6:00 AM, <net-dns-users-request at nlnetlabs.nl>wrote:
>>
>>>
>>> Date: Thu, 13 Jun 2013 11:08:56 -0700
>>> From: Chris Buxton <clists at buxtonfamily.us>
>>> To: "net-dns-users at nlnetlabs.nl" <net-dns-users at nlnetlabs.nl>
>>> Subject: [net-dns-users] Bug report: Net::DNS::Zonefile fails to read
>>>         escaped parenthesis
>>> Message-ID: <3C89B9F1-711B-4F48-9435-681EF376619F at buxtonfamily.us>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Net::DNS::Zonefile hangs when reading this record (anonymized from
>>> original record):
>>>
>>> 144.2.0.192.in-addr.arpa.                     900 IN PTR
>>>  ilouse03146p0\(.example.com.
>>>
>>> I have several more examples of this in a dataset from a current
>>> customer.
>>>
>>> Chris Buxton
>>>
>>
>>
>>
>> _______________________________________________
>> net-dns-users mailing list
>> net-dns-users at nlnetlabs.nl
>> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>>
>
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130618/689d5ae5/attachment.htm>

From bconry at isc.org  Tue Jun 18 14:11:03 2013
From: bconry at isc.org (Brian Conry)
Date: Tue, 18 Jun 2013 09:11:03 -0500
Subject: [net-dns-users] Fwd: Bug report: Net::DNS::Zonefile fails to
 read escaped parenthesis
In-Reply-To: <CA+nkc8CYXKCULDhzLckAJkW2MSnGM31nKJq8=pB1NObw_5CjeQ@mail.gmail.com>
References: <CA+nkc8Apsb=cqT_OKigA71w7dc3m4-uAxDLWpCMs4fE1TYZL+w@mail.gmail.com>
 <CA+nkc8COnSv++pv6wSOrLJLgBRnwOZXvDNDK8m_d9hMCiu_vWw@mail.gmail.com>
 <CAJrXxANThuvPxV_yHYuC1rLZg19K4nJv9ecqWBTiEcOr7v18Pg@mail.gmail.com>
 <CA+nkc8CYXKCULDhzLckAJkW2MSnGM31nKJq8=pB1NObw_5CjeQ@mail.gmail.com>
Message-ID: <51C06A77.7040404@isc.org>

On 06/18/2013 08:34 AM, Bob Harold wrote:
> Section 2.3.1 restricts domain names to letters, digits, and hyphen, but
> the wording is pretty wishy-washy "Preferred Name Syntax".
> Section 5.1 allows files to use \X and \DDD but it is not clear if that
> includes domain names, or is for other fields, like text records, soa
> email fields (the example given), SPF records, etc.
> The caveat is still that non-standard domain names won't work with all
> applications, and are best avoided.  Use at your own risk.

In my experience, anything that processes real-world packets and DNS
data will see lots of non-standard characters.  I haven't kept track,
but I feel comfortable saying that I've seen all 256 characters at one
time or another.

In my book it's pretty much a requirement for tools to deal gracefully
(i.e. either succeed or return a well-defined error) with any garbage
sent their way.

It's also nice when tools can, if asked nicely, produce "illegal" data
so I can use them to produce test data for other systems.  :)

Just my personal $0.02
Brian


From clists at buxtonfamily.us  Tue Jun 18 17:08:32 2013
From: clists at buxtonfamily.us (Chris Buxton)
Date: Tue, 18 Jun 2013 10:08:32 -0700
Subject: [net-dns-users] Bug report: Net::DNS::Zonefile fails to read
	escaped parenthesis
In-Reply-To: <CA+nkc8CYXKCULDhzLckAJkW2MSnGM31nKJq8=pB1NObw_5CjeQ@mail.gmail.com>
References: <CA+nkc8Apsb=cqT_OKigA71w7dc3m4-uAxDLWpCMs4fE1TYZL+w@mail.gmail.com>
 <CA+nkc8COnSv++pv6wSOrLJLgBRnwOZXvDNDK8m_d9hMCiu_vWw@mail.gmail.com>
 <CAJrXxANThuvPxV_yHYuC1rLZg19K4nJv9ecqWBTiEcOr7v18Pg@mail.gmail.com>
 <CA+nkc8CYXKCULDhzLckAJkW2MSnGM31nKJq8=pB1NObw_5CjeQ@mail.gmail.com>
Message-ID: <87592DA9-5764-4AEE-84E6-6847431F1BB1@buxtonfamily.us>

On Jun 18, 2013, at 6:34 AM, Bob Harold <rharolde at umich.edu> wrote:

> Section 2.3.1 restricts domain names to letters, digits, and hyphen, but the wording is pretty wishy-washy "Preferred Name Syntax".
> Section 5.1 allows files to use \X and \DDD but it is not clear if that includes domain names, or is for other fields, like text records, soa email fields (the example given), SPF records, etc.
> The caveat is still that non-standard domain names won't work with all applications, and are best avoided.  Use at your own risk.

Working from memory...

Hostnames are (supposed to be) restricted to letters, numbers, and hyphens. Domain names in general are fully 8 bit, other than the special character * and the terminal \000, except with regard to letter case. Representation in zone files of special characters follows a variety of escaping rules -- "\(" simply represents a "(" character.

A domain is a hostname if any of the following are true:

- the name owns an address record
- the name appears on the right hand side of an MX or SRV record
- the name owns an MX record

Chris




From olaf at NLnetLabs.nl  Wed Jun 19 14:01:00 2013
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Wed, 19 Jun 2013 16:01:00 +0200
Subject: [net-dns-users] Bug report: Net::DNS::Zonefile fails to read
	escaped parenthesis
In-Reply-To: <87592DA9-5764-4AEE-84E6-6847431F1BB1@buxtonfamily.us>
References: <CA+nkc8Apsb=cqT_OKigA71w7dc3m4-uAxDLWpCMs4fE1TYZL+w@mail.gmail.com>
 <CA+nkc8COnSv++pv6wSOrLJLgBRnwOZXvDNDK8m_d9hMCiu_vWw@mail.gmail.com>
 <CAJrXxANThuvPxV_yHYuC1rLZg19K4nJv9ecqWBTiEcOr7v18Pg@mail.gmail.com>
 <CA+nkc8CYXKCULDhzLckAJkW2MSnGM31nKJq8=pB1NObw_5CjeQ@mail.gmail.com>
 <87592DA9-5764-4AEE-84E6-6847431F1BB1@buxtonfamily.us>
Message-ID: <87A731C4-845A-488A-ACE4-06B44590FFC6@NLnetLabs.nl>


On Jun 18, 2013, at 7:08 PM, Chris Buxton <clists at buxtonfamily.us> wrote:

> Hostnames are (supposed to be) restricted to letters, numbers, and hyphens. Domain names in general are fully 8 bit, other than the special character * and the terminal \000

First... yes this is a bug. 8Bit clean is what the DNS is.

Second.. nit: there is no terminal \000 in the DNS wireformat. A domain name consists out of length octets followed by octets. With the final (root) octet being 0 length.

0x 02 00 00 05 00 00 00 00 00 00 (2 octets of zeros, followed by 5 octets of zeros, followed by zero length) is a perfectly valid domain name as far as the specs are concerned.



--Olaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130619/6dfde869/attachment.htm>

From clists at buxtonfamily.us  Wed Jun 19 15:55:49 2013
From: clists at buxtonfamily.us (Chris Buxton)
Date: Wed, 19 Jun 2013 08:55:49 -0700
Subject: [net-dns-users] Bug report: Net::DNS::Zonefile fails to read
	escaped parenthesis
In-Reply-To: <87A731C4-845A-488A-ACE4-06B44590FFC6@NLnetLabs.nl>
References: <CA+nkc8Apsb=cqT_OKigA71w7dc3m4-uAxDLWpCMs4fE1TYZL+w@mail.gmail.com>
 <CA+nkc8COnSv++pv6wSOrLJLgBRnwOZXvDNDK8m_d9hMCiu_vWw@mail.gmail.com>
 <CAJrXxANThuvPxV_yHYuC1rLZg19K4nJv9ecqWBTiEcOr7v18Pg@mail.gmail.com>
 <CA+nkc8CYXKCULDhzLckAJkW2MSnGM31nKJq8=pB1NObw_5CjeQ@mail.gmail.com>
 <87592DA9-5764-4AEE-84E6-6847431F1BB1@buxtonfamily.us>
 <87A731C4-845A-488A-ACE4-06B44590FFC6@NLnetLabs.nl>
Message-ID: <09C87D9E-8CD1-4F58-8674-26F7C5C663E5@buxtonfamily.us>


On Jun 19, 2013, at 7:01 AM, Olaf Kolkman wrote:

> 
> On Jun 18, 2013, at 7:08 PM, Chris Buxton <clists at buxtonfamily.us> wrote:
> 
>> Hostnames are (supposed to be) restricted to letters, numbers, and hyphens. Domain names in general are fully 8 bit, other than the special character * and the terminal \000
> 
> First... yes this is a bug. 8Bit clean is what the DNS is.
> 
> Second.. nit: there is no terminal \000 in the DNS wireformat.

Olaf,

Thanks for the correction.

Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130619/043990da/attachment.htm>

From rwfranks at acm.org  Thu Jun 20 20:45:26 2013
From: rwfranks at acm.org (Dick Franks)
Date: Thu, 20 Jun 2013 21:45:26 +0100
Subject: [net-dns-users] Fwd: Bug report: Net::DNS::Zonefile fails to
 read escaped parenthesis
In-Reply-To: <CAJrXxANThuvPxV_yHYuC1rLZg19K4nJv9ecqWBTiEcOr7v18Pg@mail.gmail.com>
References: <CA+nkc8Apsb=cqT_OKigA71w7dc3m4-uAxDLWpCMs4fE1TYZL+w@mail.gmail.com>
 <CA+nkc8COnSv++pv6wSOrLJLgBRnwOZXvDNDK8m_d9hMCiu_vWw@mail.gmail.com>
 <CAJrXxANThuvPxV_yHYuC1rLZg19K4nJv9ecqWBTiEcOr7v18Pg@mail.gmail.com>
Message-ID: <CAKW6Ri4NpQHjZOhh+nrnPXmBdt-F+VEPjUu7diT_V3K0mCk-1g@mail.gmail.com>

On 18 June 2013 13:51, Miek Gieben <miek at miek.nl> wrote:

> I think RFC 1035 states that you can pretty much include any character as
> long as it is escaped with a backslash. To me this looks like a bug in
> Net::DNS
>
> I agree.


On 18 Jun 2013 13:44, "Bob Harold" <rharolde at umich.edu> wrote:
>
>>
>> "\" and "(" are invalid characters in DNS names.
>> See RFC 952 and 1123.
>>
>> While it might be nice for Net::DNS::Zonefile to handle them, it is
>> really not necessary.
>>
>
Necessary because mandated by RFC1035.





>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130620/b09749cc/attachment.htm>

From david at schweikert.ch  Thu Jul  4 08:12:37 2013
From: david at schweikert.ch (David Schweikert)
Date: Thu, 4 Jul 2013 10:12:37 +0200
Subject: [net-dns-users] Severe Net::DNS bug waiting to be fixed
Message-ID: <20130704081237.GB13274@schweikert.ch>

Hi,

Today I just spent hours trying to debug why one of my programs was
leaking memory. I finally found these bug reports:

https://rt.cpan.org/Public/Bug/Display.html?id=84601
https://rt.cpan.org/Public/Bug/Display.html?id=85802
https://rt.cpan.org/Public/Bug/Display.html?id=86414

Dear maintainers of Net::DNS: I know you are probably busy with your
lives, but please, could you fix this? It seems to me like an important
bug that makes the module almost unusable for long-running processes.
A patch exists already.

Cheers
David


From willem at nlnetlabs.nl  Thu Jul  4 09:21:27 2013
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 04 Jul 2013 11:21:27 +0200
Subject: [net-dns-users] Severe Net::DNS bug waiting to be fixed
In-Reply-To: <20130704081237.GB13274@schweikert.ch>
References: <20130704081237.GB13274@schweikert.ch>
Message-ID: <51D53E97.3010404@nlnetlabs.nl>

David,

I will address those shortly (early next week).

-- 
Willem

Op 04-07-13 10:12, David Schweikert schreef:
> Hi,
> 
> Today I just spent hours trying to debug why one of my programs was
> leaking memory. I finally found these bug reports:
> 
> https://rt.cpan.org/Public/Bug/Display.html?id=84601
> https://rt.cpan.org/Public/Bug/Display.html?id=85802
> https://rt.cpan.org/Public/Bug/Display.html?id=86414
> 
> Dear maintainers of Net::DNS: I know you are probably busy with your
> lives, but please, could you fix this? It seems to me like an important
> bug that makes the module almost unusable for long-running processes.
> A patch exists already.
> 
> Cheers
> David
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
> 



From rwfranks at acm.org  Wed Jul 17 17:07:39 2013
From: rwfranks at acm.org (Dick Franks)
Date: Wed, 17 Jul 2013 18:07:39 +0100
Subject: [net-dns-users] Severe Net::DNS bug waiting to be fixed
In-Reply-To: <51D53E97.3010404@nlnetlabs.nl>
References: <20130704081237.GB13274@schweikert.ch>
 <51D53E97.3010404@nlnetlabs.nl>
Message-ID: <CAKW6Ri5MVdhN=q3iJ+vmx1wCrmpOo-jA0zPHf7ikfujX+xQdog@mail.gmail.com>

Willem,

I have had a good hard look at this. Unfortunately, there is no prospect of
relief without some architectural change.

My plan now is to attempt to re-engineer Packet and Header in ways which
(a) eliminate the leakage problem and (b) preserves enough compatibility to
avoid breaking Net::DNS::SEC.

If that proves impossible, we may need to negotiate with Olaf to refurbish
Net::DNS::SEC to avoid the breaks of encapsulation in some of its RR
subtypes.

Regards

Dick Franks

--


On 4 July 2013 10:21, Willem Toorop <willem at nlnetlabs.nl> wrote:

> David,
>
> I will address those shortly (early next week).
>
> --
> Willem
>
> Op 04-07-13 10:12, David Schweikert schreef:
> > Hi,
> >
> > Today I just spent hours trying to debug why one of my programs was
> > leaking memory. I finally found these bug reports:
> >
> > https://rt.cpan.org/Public/Bug/Display.html?id=84601
> > https://rt.cpan.org/Public/Bug/Display.html?id=85802
> > https://rt.cpan.org/Public/Bug/Display.html?id=86414
> >
> > Dear maintainers of Net::DNS: I know you are probably busy with your
> > lives, but please, could you fix this? It seems to me like an important
> > bug that makes the module almost unusable for long-running processes.
> > A patch exists already.
> >
> > Cheers
> > David
> > _______________________________________________
> > net-dns-users mailing list
> > net-dns-users at nlnetlabs.nl
> > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
> >
>
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130717/d7b06718/attachment.htm>

From olaf at NLnetLabs.nl  Wed Jul 17 18:07:06 2013
From: olaf at NLnetLabs.nl (Olaf Kolkman)
Date: Wed, 17 Jul 2013 20:07:06 +0200
Subject: [net-dns-users] Severe Net::DNS bug waiting to be fixed
In-Reply-To: <CAKW6Ri5MVdhN=q3iJ+vmx1wCrmpOo-jA0zPHf7ikfujX+xQdog@mail.gmail.com>
References: <20130704081237.GB13274@schweikert.ch>
 <51D53E97.3010404@nlnetlabs.nl>
 <CAKW6Ri5MVdhN=q3iJ+vmx1wCrmpOo-jA0zPHf7ikfujX+xQdog@mail.gmail.com>
Message-ID: <B53E11C0-4B05-46FA-884C-ACFF316EA5B7@NLnetLabs.nl>


On Jul 17, 2013, at 7:07 PM, Dick Franks <rwfranks at acm.org> wrote:

> 
> I have had a good hard look at this. Unfortunately, there is no prospect of relief without some architectural change.
> 
> My plan now is to attempt to re-engineer Packet and Header in ways which (a) eliminate the leakage problem and (b) preserves enough compatibility to avoid breaking Net::DNS::SEC.
> 
> If that proves impossible, we may need to negotiate with Olaf to refurbish Net::DNS::SEC to avoid the breaks of encapsulation in some of its RR subtypes.


In short can you describe what is the problem and what your attempt at fixing will look like (and the impact on Net::DNS::SEC)

--Olaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130717/d4506563/attachment.htm>

From rwfranks at acm.org  Wed Jul 17 19:15:29 2013
From: rwfranks at acm.org (Dick Franks)
Date: Wed, 17 Jul 2013 20:15:29 +0100
Subject: [net-dns-users] Severe Net::DNS bug waiting to be fixed
In-Reply-To: <B53E11C0-4B05-46FA-884C-ACFF316EA5B7@NLnetLabs.nl>
References: <20130704081237.GB13274@schweikert.ch>
 <51D53E97.3010404@nlnetlabs.nl>
 <CAKW6Ri5MVdhN=q3iJ+vmx1wCrmpOo-jA0zPHf7ikfujX+xQdog@mail.gmail.com>
 <B53E11C0-4B05-46FA-884C-ACFF316EA5B7@NLnetLabs.nl>
Message-ID: <CAKW6Ri64Lu8SCduE2zjBZbAr=TBcGX7adRvr-MqjdBnwzyxBzA@mail.gmail.com>

The problem is the mutual reference between Packet and Header.
The present scheme was hatched to overcome the explicit references to
Header and Packet internals inside some of the Net::DNS::SEC RRs.  I was
choosing to live with these shortcomings, and still intend to do so if
possible in order to avoid having to make changes in there until we return
to a seaworthy Net::DNS.


Dick Franks

--


On 17 July 2013 19:07, Olaf Kolkman <olaf at nlnetlabs.nl> wrote:

>
> On Jul 17, 2013, at 7:07 PM, Dick Franks <rwfranks at acm.org> wrote:
>
>
> I have had a good hard look at this. Unfortunately, there is no prospect
> of relief without some architectural change.
>
> My plan now is to attempt to re-engineer Packet and Header in ways which
> (a) eliminate the leakage problem and (b) preserves enough compatibility to
> avoid breaking Net::DNS::SEC.
>
> If that proves impossible, we may need to negotiate with Olaf to refurbish
> Net::DNS::SEC to avoid the breaks of encapsulation in some of its RR
> subtypes.
>
>
>
> In short can you describe what is the problem and what your attempt at
> fixing will look like (and the impact on Net::DNS::SEC)
>
> --Olaf
>
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130717/2b467f27/attachment.htm>

From rwfranks at acm.org  Thu Jul 18 10:59:36 2013
From: rwfranks at acm.org (Dick Franks)
Date: Thu, 18 Jul 2013 11:59:36 +0100
Subject: [net-dns-users] Severe Net::DNS bug waiting to be fixed
In-Reply-To: <51D53E97.3010404@nlnetlabs.nl>
References: <20130704081237.GB13274@schweikert.ch>
 <51D53E97.3010404@nlnetlabs.nl>
Message-ID: <CAKW6Ri7=61bv-+o4L3tPNcKG9Tjd-byd4QDifj9jTpWr5SGw7w@mail.gmail.com>

Willem,

Attached tarball patches Header and Packet to solve memory leak.
I am still looking at the implications for Net::DNS::SEC

Dick Franks

--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130718/3b86fcf7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch18jul13.tar.gz
Type: application/x-gzip
Size: 3741 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130718/3b86fcf7/attachment.bin>

From willem at nlnetlabs.nl  Thu Jul 18 12:14:01 2013
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 18 Jul 2013 14:14:01 +0200
Subject: [net-dns-users] Severe Net::DNS bug waiting to be fixed
In-Reply-To: <CAKW6Ri7=61bv-+o4L3tPNcKG9Tjd-byd4QDifj9jTpWr5SGw7w@mail.gmail.com>
References: <20130704081237.GB13274@schweikert.ch>
 <51D53E97.3010404@nlnetlabs.nl>
 <CAKW6Ri7=61bv-+o4L3tPNcKG9Tjd-byd4QDifj9jTpWr5SGw7w@mail.gmail.com>
Message-ID: <51E7DC09.2040809@nlnetlabs.nl>

Thanks. To make tests succeed with Net::DNS::SEC 0.16, I also had to put
in a dummy header into Packet:

--- Packet.pm	2013-07-18 13:39:10.870079091 +0200
+++ Packet.pm	2013-07-18 13:41:42.598078205 +0200
@@ -67,6 +67,7 @@
 		additional => []}, $class;

 	$self->{question} = [Net::DNS::Question->new(@_)] if scalar @_;
+	$self->{header} = {}; # Backw. compatibility with Net::DNS::SEC

 	$self->header->rd(1);
 	return $self;
@@ -126,7 +127,8 @@
 			answer	   => [],
 			authority  => [],
 			additional => [],
-			answersize => length $$data
+			answersize => length $$data,
+			header     => {} # BW compat. with Net::DNS::SEC
 			}, $class;

 		# question/zone section

I also added some more default initializations for status:

--- Header.pm.orig	2013-07-18 14:07:07.778069322 +0200
+++ Header.pm	2013-07-18 13:54:13.878073831 +0200
@@ -139,7 +139,7 @@
 sub opcode {
 	my $self = shift;
 	my $xpkt = $self->{xbody};
-	for ( $xpkt->{status} ) {
+	for ( $xpkt->{status} ||= 0 ) {
 		return opcodebyval(( $_ >> 11) & 0x0f) unless scalar @_;
 		my $opcode = opcodebyname(shift);
 		$_ = ( $_ & 0x87ff ) | ( $opcode << 11 );
@@ -160,7 +160,7 @@
 sub rcode {
 	my $self = shift;
 	my $xpkt = $self->{xbody};
-	for ( $xpkt->{status} ) {
+	for ( $xpkt->{status} ||= 0 ) {
 		my $arg = shift;
 		my $opt = $self->edns;
 		unless ( defined $arg ) {

Do you agree?

-- Willem

Op 18-07-13 12:59, Dick Franks schreef:
> Willem,
> 
> Attached tarball patches Header and Packet to solve memory leak.
> I am still looking at the implications for Net::DNS::SEC
> 
> Dick Franks



From rwfranks at acm.org  Thu Jul 18 14:29:12 2013
From: rwfranks at acm.org (Dick Franks)
Date: Thu, 18 Jul 2013 15:29:12 +0100
Subject: [net-dns-users] Severe Net::DNS bug waiting to be fixed
In-Reply-To: <51E7DC09.2040809@nlnetlabs.nl>
References: <20130704081237.GB13274@schweikert.ch>
 <51D53E97.3010404@nlnetlabs.nl>
 <CAKW6Ri7=61bv-+o4L3tPNcKG9Tjd-byd4QDifj9jTpWr5SGw7w@mail.gmail.com>
 <51E7DC09.2040809@nlnetlabs.nl>
Message-ID: <CAKW6Ri41PKqp6oxWT0uLaQmBtDim1cy307EAnwYS+8+VhRix=Q@mail.gmail.com>

That is good.
I do like the idea of the dummy header.

Please can you put that on trunk so we can persuade it to test clean using
Net::DNS::SEC 0.16


Dick Franks

--


On 18 July 2013 13:14, Willem Toorop <willem at nlnetlabs.nl> wrote:

> Thanks. To make tests succeed with Net::DNS::SEC 0.16, I also had to put
> in a dummy header into Packet:
>
> --- Packet.pm   2013-07-18 13:39:10.870079091 +0200
> +++ Packet.pm   2013-07-18 13:41:42.598078205 +0200
> @@ -67,6 +67,7 @@
>                 additional => []}, $class;
>
>         $self->{question} = [Net::DNS::Question->new(@_)] if scalar @_;
> +       $self->{header} = {}; # Backw. compatibility with Net::DNS::SEC
>
>         $self->header->rd(1);
>         return $self;
> @@ -126,7 +127,8 @@
>                         answer     => [],
>                         authority  => [],
>                         additional => [],
> -                       answersize => length $$data
> +                       answersize => length $$data,
> +                       header     => {} # BW compat. with Net::DNS::SEC
>                         }, $class;
>
>                 # question/zone section
>
> I also added some more default initializations for status:
>
> --- Header.pm.orig      2013-07-18 14:07:07.778069322 +0200
> +++ Header.pm   2013-07-18 13:54:13.878073831 +0200
> @@ -139,7 +139,7 @@
>  sub opcode {
>         my $self = shift;
>         my $xpkt = $self->{xbody};
> -       for ( $xpkt->{status} ) {
> +       for ( $xpkt->{status} ||= 0 ) {
>                 return opcodebyval(( $_ >> 11) & 0x0f) unless scalar @_;
>                 my $opcode = opcodebyname(shift);
>                 $_ = ( $_ & 0x87ff ) | ( $opcode << 11 );
> @@ -160,7 +160,7 @@
>  sub rcode {
>         my $self = shift;
>         my $xpkt = $self->{xbody};
> -       for ( $xpkt->{status} ) {
> +       for ( $xpkt->{status} ||= 0 ) {
>                 my $arg = shift;
>                 my $opt = $self->edns;
>                 unless ( defined $arg ) {
>
> Do you agree?
>
> -- Willem
>
> Op 18-07-13 12:59, Dick Franks schreef:
> > Willem,
> >
> > Attached tarball patches Header and Packet to solve memory leak.
> > I am still looking at the implications for Net::DNS::SEC
> >
> > Dick Franks
>
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130718/477e2c8a/attachment.htm>

From wolfsage at gmail.com  Wed Aug 21 14:51:26 2013
From: wolfsage at gmail.com (Matthew Horsfall (alh))
Date: Wed, 21 Aug 2013 10:51:26 -0400
Subject: [net-dns-users] 0.72 memory leak and next release
Message-ID: <CAJ0K8bjfwnNwe+y37+MudLXzamTVz7ZNa=YfEq2F7_Uks2TEDQ@mail.gmail.com>

Howdy,

I found a memory leak in Net::DNS::Packet/Net::DNS::Header in 0.72 that
basically amounts to:

  $packet->{header} = $header;
  $header->{xbody} = $packet;

(See Net::DNS::Header::new())

Looking at trunk, I see that the leak is no longer there since most of the
code was rewritten.

I was curious when a new release of Net::DNS was planned since this leak is
fairly significant and happens any time a Net::DNS::Packet object is
created. This leaks very quickly for example:

  while (1) {
    my $packet = Net::DNS::Packet->new('test.com', 'A');
  }

Thanks,

-- Matthew Horsfall (alh)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20130821/b1b8c385/attachment.htm>

From willem at nlnetlabs.nl  Thu Aug 22 07:41:50 2013
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 22 Aug 2013 09:41:50 +0200
Subject: [net-dns-users] 0.72 memory leak and next release
In-Reply-To: <CAJ0K8bjfwnNwe+y37+MudLXzamTVz7ZNa=YfEq2F7_Uks2TEDQ@mail.gmail.com>
References: <CAJ0K8bjfwnNwe+y37+MudLXzamTVz7ZNa=YfEq2F7_Uks2TEDQ@mail.gmail.com>
Message-ID: <5215C0BE.5010706@nlnetlabs.nl>

Op 21-08-13 16:51, Matthew Horsfall (alh) schreef:
> I was curious when a new release of Net::DNS was planned

Hi Matthew,

Soon. Probably somewhere in September. October otherwise.

-- Willem


From clists at buxtonfamily.us  Fri Sep 27 16:27:35 2013
From: clists at buxtonfamily.us (Chris Buxton)
Date: Fri, 27 Sep 2013 09:27:35 -0700
Subject: [net-dns-users] Net::DNS::Zonefile and reverse zones
Message-ID: <250CE8C5-5955-4D14-A401-F75E63EE0D91@buxtonfamily.us>

There's a problem parsing zone files when reverse records are not named with FQDNs.

Here's my input file:


$ORIGIN 191.168.192.in-addr.arpa.
$TTL 1h
@	SOA	ns1.bcn.lab.	root.bcn.lab.	1	1d 15m 6w 5m
	NS	ns1.bcn.lab.
	NS	ns2.bcn.lab.
1	PTR	bcn.lab.
6	PTR	ns1.bcn.lab.
7	PTR	ns2.bcn.lab.
8	PTR	mx1.bcn.lab.
254	PTR	u.bcn.lab.


And after reading this using Net::DNS::Zonefile and simply printing out the records again:


191.168.192.in-addr.arpa.	3600	IN	SOA	ns1.bcn.lab. root.bcn.lab. 1 86400 900 3628800 300
191.168.192.in-addr.arpa.	3600	IN	NS	ns1.bcn.lab.
191.168.192.in-addr.arpa.	3600	IN	NS	ns2.bcn.lab.
1.in-addr.arpa.	3600	IN	PTR	bcn.lab.
6.in-addr.arpa.	3600	IN	PTR	ns1.bcn.lab.
7.in-addr.arpa.	3600	IN	PTR	ns2.bcn.lab.
8.in-addr.arpa.	3600	IN	PTR	mx1.bcn.lab.
254.in-addr.arpa.	3600	IN	PTR	u.bcn.lab.


Notice the origin has been changed to 'in-addr.arpa' for all nodes after the zone apex. I haven't noticed this problem with zones whose names don't end in 'in-addr.arpa'; it appears to be specific to reverse zones, or perhaps to PTR records.

Thanks,
Chris Buxton


From rwfranks at acm.org  Sat Oct  5 19:44:55 2013
From: rwfranks at acm.org (Dick Franks)
Date: Sat, 5 Oct 2013 20:44:55 +0100
Subject: [net-dns-users] Net::DNS::Zonefile and reverse zones
In-Reply-To: <250CE8C5-5955-4D14-A401-F75E63EE0D91@buxtonfamily.us>
References: <250CE8C5-5955-4D14-A401-F75E63EE0D91@buxtonfamily.us>
Message-ID: <CAKW6Ri79oc+dDE3zGpnJZ-7eKxYL8WocS4z_DNNjX6sh3J4=2A@mail.gmail.com>

Same issue as RT#84110

https://rt.cpan.org/Ticket/Display.html?id=88744

Dick Franks
________________________



On 27 September 2013 17:27, Chris Buxton <clists at buxtonfamily.us> wrote:

> There's a problem parsing zone files when reverse records are not named
> with FQDNs.
>
> Here's my input file:
>
>
> $ORIGIN 191.168.192.in-addr.arpa.
> $TTL 1h
> @       SOA     ns1.bcn.lab.    root.bcn.lab.   1       1d 15m 6w 5m
>         NS      ns1.bcn.lab.
>         NS      ns2.bcn.lab.
> 1       PTR     bcn.lab.
> 6       PTR     ns1.bcn.lab.
> 7       PTR     ns2.bcn.lab.
> 8       PTR     mx1.bcn.lab.
> 254     PTR     u.bcn.lab.
>
>
> And after reading this using Net::DNS::Zonefile and simply printing out
> the records again:
>
>
> 191.168.192.in-addr.arpa.       3600    IN      SOA     ns1.bcn.lab.
> root.bcn.lab. 1 86400 900 3628800 300
> 191.168.192.in-addr.arpa.       3600    IN      NS      ns1.bcn.lab.
> 191.168.192.in-addr.arpa.       3600    IN      NS      ns2.bcn.lab.
> 1.in-addr.arpa. 3600    IN      PTR     bcn.lab.
> 6.in-addr.arpa. 3600    IN      PTR     ns1.bcn.lab.
> 7.in-addr.arpa. 3600    IN      PTR     ns2.bcn.lab.
> 8.in-addr.arpa. 3600    IN      PTR     mx1.bcn.lab.
> 254.in-addr.arpa.       3600    IN      PTR     u.bcn.lab.
>
>
> Notice the origin has been changed to 'in-addr.arpa' for all nodes after
> the zone apex. I haven't noticed this problem with zones whose names don't
> end in 'in-addr.arpa'; it appears to be specific to reverse zones, or
> perhaps to PTR records.
>
> Thanks,
> Chris Buxton
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20131005/c5bba5d9/attachment.htm>

From rwfranks at acm.org  Mon Oct 28 21:07:45 2013
From: rwfranks at acm.org (Dick Franks)
Date: Mon, 28 Oct 2013 21:07:45 +0000
Subject: [net-dns-users] GOST signature validation
In-Reply-To: <3C7C3A1C-0E7E-42DE-AFBC-478ACDFF7A31@verisign.com>
References: <3C7C3A1C-0E7E-42DE-AFBC-478ACDFF7A31@verisign.com>
Message-ID: <CAKW6Ri4cmMPgw=M4hBLWyTB4NLKZru0=4NAd3ERAey_DP6Wjug@mail.gmail.com>

Duane,

I would be interested to see your solution to this, even if it is not
pretty.

Dick Franks
________________________



On 16 January 2013 17:46, Wessels, Duane <dwessels at verisign.com> wrote:

> On the subject of GOST, for what it's worth I also have code to validate
> GOST RRSIGs.
> Since there doesn't seem to be a perl module that already does this, I
> resorted to
> using the Inline module and calling the openssl library functions.  Its
> not very
> pretty but it does work.  I can share it if there is interest, but I don't
> think it
> fits very well into the Net::DNS::SEC package as-is.
>
> DW
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20131028/2c1482a9/attachment.htm>

From dwessels at verisign.com  Mon Nov  4 21:25:56 2013
From: dwessels at verisign.com (Wessels, Duane)
Date: Mon, 4 Nov 2013 21:25:56 +0000
Subject: [net-dns-users] GOST signature validation
In-Reply-To: <CAKW6Ri4cmMPgw=M4hBLWyTB4NLKZru0=4NAd3ERAey_DP6Wjug@mail.gmail.com>
References: <3C7C3A1C-0E7E-42DE-AFBC-478ACDFF7A31@verisign.com>
 <CAKW6Ri4cmMPgw=M4hBLWyTB4NLKZru0=4NAd3ERAey_DP6Wjug@mail.gmail.com>
Message-ID: <9E355E7B-87B8-4935-8928-9ADF835A97E6@verisign.com>

Sure thing.  Two files are attached.  First, a patch to Net::DNS::SEC.  Note that there are two other
changes mixed in with this patch.  (1) I think there was a bug with Digest::BubbleBabble being optional,
and (2) I added support for SHA384 DS records.

The second file is SEC/GOST.pm.  It uses the Perl Inline module and some openssl calls to implement
the GOST verification.  One of the things I struggled with was the setting the DIRECTORY option when
calling the Inline module.  I think the default is to create something in the current directory and
my particular application doesn't have a writable current directory.  I don't know if the /var/tmp
inline directory is very safe.

Note that Digest::GOST::CryptoPro is used when generating DS records.  If someone only wants to
generate DS records, they can do that just in Perl.  The Inline/openssl code is needed to validate
signatures.  I did not write any code to generate GOST signatures.









On Oct 28, 2013, at 2:07 PM, Dick Franks <rwfranks at acm.org> wrote:

> Duane,
>
> I would be interested to see your solution to this, even if it is not pretty.
>
> Dick Franks
> ________________________
>
>
>
> On 16 January 2013 17:46, Wessels, Duane <dwessels at verisign.com> wrote:
> On the subject of GOST, for what it's worth I also have code to validate GOST RRSIGs.
> Since there doesn't seem to be a perl module that already does this, I resorted to
> using the Inline module and calling the openssl library functions.  Its not very
> pretty but it does work.  I can share it if there is interest, but I don't think it
> fits very well into the Net::DNS::SEC package as-is.
>
> DW
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
>
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20131104/6a7c68ff/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: net-dns-sec-gost.patch
Type: application/octet-stream
Size: 6656 bytes
Desc: net-dns-sec-gost.patch
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20131104/6a7c68ff/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GOST.pm
Type: text/x-perl-script
Size: 2469 bytes
Desc: GOST.pm
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20131104/6a7c68ff/attachment.bin>

From willem at nlnetlabs.nl  Fri Nov 22 14:54:39 2013
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Fri, 22 Nov 2013 15:54:39 +0100
Subject: [net-dns-users] Release candidates for Net::DNS 0.73 and
	Net::DNS::SEC 0.17
Message-ID: <528F702F.8000300@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear maintainers and users of Net::DNS and Net::DNS::SEC,

We have a release candidate for Net::DNS and a release candidate for
Net::DNS::SEC.  Both are primarily concerned with bug fixes.
The most prominent enhancements are, for Net::DNS:

- - TSIG validation support
- - TSIG support for HMAC-SHA1 .. HMAC-SHA512

and for Net::DNS::SEC:

- - Validation of wildcard RR sets

For a complete list of changes see the Changes sections below.

We have done our utmost best to remain completely backwards
compatible. Please review this version carefully and regression-test
it with your software.  If no issues arise, the actual release will
follow in one week.

link     http://www.net-dns.org/download/Net-DNS-0.72_04.tar.gz
sha1     417d1725e305c2186fc22d6a2f4f1915ac40dc9d

link     http://www.net-dns.org/download/Net-DNS-SEC-0.16_04.tar.gz
sha1     b281a3540cdb67309ec6ce90422a75fa59b07511


Changes for Net::DNS 0.72_04
============================
Fix rt.cpan.org #88778

        $update->unique_push() does not work as advertised.

Fix rt.cpan.org #88744

        Nameserver crashes on malformed TCP query.

Fix rt.cpan.org #84601/#81942

        Fix memory leak on packet cleanup. Indirect self-reference via
        header prevented garbage collector from deallocating packet.

Feature rt.cpan.org #84468

        TSIG: add support for HMAC-SHA1 .. HMAC-SHA512

Fix rt.cpan.org #84110

        Incorrect parsing of PTR records in zonefile.

Fix rt.cpan.org #83755

        Erroneous attempt to invoke Net::LibIDN package in Domain.pm.

Fix rt.cpan.org #83078

        Can't locate Net/DNS/Resolver/linux.pm in @INC
        Conjecture:  eval{ ... };  if ($@) { ... };  broken by threads.

Fix rt.cpan.org #83075

        ZoneFile.pm wrongly rejects $TTL 0 directive.

Fix rt.cpan.org #82621

        Error string empty after failed TCP query.

Fix rt.cpan.org #82296

        IPv6 with embedded IPv4 address not mapped to ip6.arpa.

Fix rt.cpan.org #82294

        Perl taint inadvertently removed in Domain and Text objects.

Feature rt.cpan.org #53610

        add TSIG validation support


Changes for Net::DNS::SEC 0.16_04
=================================
   Fix: rt.cpan.org #81289
   Failure to handle GOST DS records

   Fix: rt.cpan.org #90270
   NSEC3->covered() should use case-insensitive comparisons

   Fix: rt.cpan.org #79606
   Lower case zone-name part with DNSKEY::privatename

   Allow to specify algorithms with ::Private->new_rsa_private and
   ::Private->generate_rsa in stead of assuming RSASHA1.

   Fix: rt.cpan.org #55621
   Specify license type (mit) in META.yml

   Fix: rt.cpan.org #60269
   Remove Digest::SHA1 prerequirement

   Fix: rt.cpan.org #62387 & #63273
   Typo fixes

   Fix: rt.cpan.org #62386
   Make Net::DNS::RR::DS::digtype method work

   Fix: rt.cpan.org #62385
   Do not compress Next Domain Name in NSEC rdata.

   Fix: rt.cpan.org #61104
   Spelling correction in DS.pm and fix of key2ds demo program

   Fix: rt.cpan.org #60185
   Make sure %main::SIG hash keeps its values when compiling
   Net::DNS::RR::SIG in perl versions before 5.14.
   See also: rt.perl.org #76138

   Fix: rt.cpan.org #64552 and rt.cpan.org #79606
   Support for private-key-format v1.3

   Fix: rt.cpan.org #75892
   Do not canonicalize the "Next Domain Name" rdata field of a NSEC RR
   for draft-ietf-dnsext-dnssec-bis-updates-17 compliency.

   BUG FIX/FEATURE: validation of wildcard RRs now available. Duane
   Wessels is acknowledged for submitting the initial code on which
   this fix is based.

   FIX: case sensitivity of ownername during DS generation
        (Acknowledgements Jens Wagner)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSj3AuAAoJEOX4+CEvd6SY9+oP/icYZIXdFeeskjtKjPBmL0s9
UDxm92pphFwTf9ooWB17Qed3oIKcFT7e2MkIPi/AnTt0x1lN1na1apb3oQE0xBiw
qda7gZa7+wgXcIHqIoVW4ar2RZVH6JXJwkyAygi90akLODqqS7RedBh9ODnTKbTw
VWg2w4T0ElAF3n+lQvFoCrYZF6HtflszvTeZKCP9uKG/0rcCjgVBHzeX0NCIARt8
efBUXnCeyLnu6kBlOvA2zLPFb4rku4SCaRou0cVNnhuH4TyWkSgFWVlDt1JEkrkv
haIKJRPQpbw5fFzbqcvNbxMiiXsYfEjRkHuSE9wCR6IESU8UZ51el96Spq2+6UAb
TMlE6X19U3IvPmpAJniU8+J1YZxsl3u5Ud/cR+gkRNxcbGQCACK4QB2djHEmLevd
4i3WkpIdnMxlUTxDRMCFxfqL/vOu78vgeKkgnOFJoq135HzYWmtSI+3gD/c3hRqJ
1dXUbcK8oTWewuQpKdVsroxBwarCawVL57xF45s24VHAt89xe3FGd1kxTdDWgrd8
wDv8D2+/F65BmDUWNZxkBk2vWlnv22VOq3SFAx0dJug8FfZ5HUf8mxB+l660hHbA
hF902SJC2U4tsY/MnoGazuGHxhP5WdYaY3aL44vY6QnMLCKW8zFR8LTzint/vy30
aRs8JKwbkXzCkSvtzdU+
=1VES
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Fri Nov 29 13:38:53 2013
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Fri, 29 Nov 2013 14:38:53 +0100
Subject: [net-dns-users] Net::DNS 0.73 and Net::DNS::SEC 0.17 released
Message-ID: <529898ED.7090006@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dear maintainers and users of Net::DNS and Net::DNS::SEC,

I am pleased to announce the release of Net::DNS 0.73 and
Net::DNS::SEC 0.17.  Both are primarily concerned with bug fixes.
The most prominent enhancements are, for Net::DNS:

- - TSIG validation support
- - TSIG support for HMAC-SHA1 .. HMAC-SHA512

and for Net::DNS::SEC:

- - Validation of wildcard RR sets

For a complete list of changes see the Changes sections below.

link     http://www.net-dns.org/download/Net-DNS-0.73.tar.gz
sha1     03c02d04c4346e4a3f52e28885d870b6be96feda

link     http://www.net-dns.org/download/Net-DNS-SEC-0.17.tar.gz
sha1     b9803cef204fc8372c59b6223b80ed7e603d66ad


Changes for Net::DNS 0.73
=========================
Fix rt.cpan.org #88778

        $update->unique_push() does not work as advertised.

Fix rt.cpan.org #88744

        Nameserver crashes on malformed TCP query.

Fix rt.cpan.org #84601/#81942

        Fix memory leak on packet cleanup. Indirect self-reference via
        header prevented garbage collector from deallocating packet.

Feature rt.cpan.org #84468

        TSIG: add support for HMAC-SHA1 .. HMAC-SHA512

Fix rt.cpan.org #84110

        Incorrect parsing of PTR records in zonefile.

Fix rt.cpan.org #83755

        Erroneous attempt to invoke Net::LibIDN package in Domain.pm.

Fix rt.cpan.org #83078

        Can't locate Net/DNS/Resolver/linux.pm in @INC
        Conjecture:  eval{ ... };  if ($@) { ... };  broken by threads.

Fix rt.cpan.org #83075

        ZoneFile.pm wrongly rejects $TTL 0 directive.

Fix rt.cpan.org #82621

        Error string empty after failed TCP query.

Fix rt.cpan.org #82296

        IPv6 with embedded IPv4 address not mapped to ip6.arpa.

Fix rt.cpan.org #82294

        Perl taint inadvertently removed in Domain and Text objects.

Feature rt.cpan.org #53610

        add TSIG validation support


Changes for Net::DNS::SEC 0.17
==============================
   Fix: rt.cpan.org #81289
   Failure to handle GOST DS records

   Fix: rt.cpan.org #90270
   NSEC3->covered() should use case-insensitive comparisons

   Fix: rt.cpan.org #79606
   Lower case zone-name part with DNSKEY::privatename

   Allow to specify algorithms with ::Private->new_rsa_private and
   ::Private->generate_rsa in stead of assuming RSASHA1.

   Fix: rt.cpan.org #55621
   Specify license type (mit) in META.yml

   Fix: rt.cpan.org #60269
   Remove Digest::SHA1 prerequirement

   Fix: rt.cpan.org #62387 & #63273
   Typo fixes

   Fix: rt.cpan.org #62386
   Make Net::DNS::RR::DS::digtype method work

   Fix: rt.cpan.org #62385
   Do not compress Next Domain Name in NSEC rdata.

   Fix: rt.cpan.org #61104
   Spelling correction in DS.pm and fix of key2ds demo program

   Fix: rt.cpan.org #60185
   Make sure %main::SIG hash keeps its values when compiling
   Net::DNS::RR::SIG in perl versions before 5.14.
   See also: rt.perl.org #76138

   Fix: rt.cpan.org #64552 and rt.cpan.org #79606
   Support for private-key-format v1.3

   Fix: rt.cpan.org #75892
   Do not canonicalize the "Next Domain Name" rdata field of a NSEC RR
   for draft-ietf-dnsext-dnssec-bis-updates-17 compliency.

   BUG FIX/FEATURE: validation of wildcard RRs now available. Duane
   Wessels is acknowledged for submitting the initial code on which
   this fix is based.

   FIX: case sensitivity of ownername during DS generation
        (Acknowledgements Jens Wagner)
_______________________________________________
maintainers mailing list
maintainers at nlnetlabs.nl
http://nlnetlabs.nl/mailman/listinfo/maintainers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSmJjoAAoJEOX4+CEvd6SYqqMP/2TgdV9MG5j0bo7lE5gwhFjU
iHV84o0QH0FNPawFAAhvkws3mOLeffMfeLQ7vxMu5Nvcz1zt3Gg6Rr8d209DM6hB
Fj1vkv35OdzNf2Rvzva9s0+V33Fpee1k54ZL7/MDhq/Je8ANXRbQrssfQhVDKqF2
6KJG3l0F0m3HOl+9Qg9ZJKgH0dwkjUBx3xUU4BG+8Oy3bsLSKqc26BViNAGO7qZr
AN4c/Wbgkpbkex5Xt08rcPK/Hg/VPulF2Yj8Qa8VwYq9eBgm54kJazCHotONlNpL
TZeG4/vwdMMvD2/kzE+mN1GZBjLqkx7pu8fIQWEP4Tws+zv+L6k+nGLDwI1wczyI
Q92XmqTHwxKKD1bRJP4u1EG/QWiNlkqNNS6say73Dv8vM9UWeVvjWtyXFHLXW4VY
QCzY8z03X3+gLh6mG0rO5gdMM7ealUp0HwDHGF+PgDuzUp5SzjVHOaRl99rhMRuQ
owemdzi9Rv/aMBQ6DIEbuZ9+u2aDi8797nbBk7+r0VcHg/GTLCglRi7iitIFJ58+
wcKI3IEdb6iNxSbaEVfwmzbP7DnayhdpGkKf1fRMcF+UD2bpB51HNAGsKWFRxS6L
Jf7rTbj82RIG63IaCpOOlRBuyYmQX4G2p0lle1awhi89FbXv+4KO3uFdmuKqDRWJ
BYv0RxbfE4vN+OzGp/4r
=F4iI
-----END PGP SIGNATURE-----


From Dan.Weintraub at dealer.com  Mon Dec 16 22:27:31 2013
From: Dan.Weintraub at dealer.com (Dan Weintraub)
Date: Mon, 16 Dec 2013 22:27:31 +0000
Subject: [net-dns-users] Secure updates for Microsoft DNS
Message-ID: <5DF1B155-4588-466F-A0A8-C1796A1BEAF7@dealer.com>

Hello,

I?m using Net::DNS::Update to dynamically update Microsoft DNS and it?s working very well. However, I need to change a zone I?m updating to ?only secure updates? and I?m having a hard time understanding how it?s supposed to work. I see there are some examples in your documentation with TSIG, but it looks like they might be for bind only. I hear that Microsoft has their own version of the standard that differs in several ways.

Will Net::DNS::Update do secure updates with Microsoft DNS? Does anyone know of any documentation on this setup?

Thanks in advance,
Dan



Dan Weintraub | Senior Systems Engineer
V: 877.327.8422
mailto:Dan.Weintraub at dealer.com | www.dealer.com