From willem at nlnetlabs.nl  Tue Jan 13 13:34:49 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 13 Jan 2015 14:34:49 +0100
Subject: [net-dns-users] Release candidate for Net::DNS 0.82
Message-ID: <54B51EF9.7070402@nlnetlabs.nl>

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

Dear users of Net::DNS,

We have a candidate for the upcoming single bugfix/feature release 0.82
of Net::DNS.

This release adds support for upstream nameservers to be specified as
IPv6 link-local addresses with scope_id; either directly on Resolver
construction or with the nameservers method, or via a nameserver keyword
in a resolver configuration file ( /etc/resolv.conf ).

Please review carefully. If no issues arise, the actual release will
follow Tuesday the 20th of January 2015.

link 	http://www.net-dns.org/download/Net-DNS-0.81_01.tar.gz
sha1 	e69a928219eb72ecd89855c8b239d823a24424f5

Changes
=======
Fix rt.cpan.org #100385

	Support for IPv6 link-local addresses with scope_id

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUtR75AAoJEOX4+CEvd6SYyBIP/3gy65xbTS3xdeqbvUNYtxgi
NN3iIVcL2KDOjfaeav5pPK7oZjvwOhZzZTbhLynrVWKZz3xe2qWDcFZ2E7IudEsa
EtrfIXpNJ5AFz/BBiR4/k/WEXEQEuhyKes8lKfgbUQXtKKXYRbP2wqnjF/s/uxUy
uZKRzy4U2UjgMGtxPN8lPF6TzKykEOlR3uiSa1k2j8uvNFxZa4SkPq9PYLa1oClA
ezegAQsPRWhFeUiqPbhnRXHNOGYOyyiBVwwAHyjoDmEPE7nDD3lnpnnB+TOlfqfD
407xo340a4K6vKEqw8pTgRjZRwzok+/e22ibIU7aEevYT3bJQpssMcSVSEiKH5Sb
aGotr7CO+/THi3u/Hk3VnGuiqBnckgQFKaeOJJOy+9tAqhT7dXSQ4kXM6igYtay4
X4I8daVYw0XlTGMHIVTEMhdCz437d7+NXB7KrhzodM2UZrAf6et5TuTLrqFkERYK
BhPWkR3g0nNrK7phd+zKNDlnE8rYHFTfEby8XPQS9IY+7PomQE/5r3CPJ8edcDVH
zk7Ep5MS4K1uuGC4egYk75+2O3S1RTeJSxhMc6qz1LmAIrWjpOcsVUryhojGgtqg
3pHtjPDcvnddTUqxjywVwyG+Ek+ZUEFbSKzbJyNEMm6KSB1e9gmUjyOJidGuq6Z+
wCo5q4l+alw2W1OWTRD4
=NMkT
-----END PGP SIGNATURE-----


From ogud at ogud.com  Wed Jan 14 15:49:28 2015
From: ogud at ogud.com (Olafur Gudmundsson)
Date: Wed, 14 Jan 2015 10:49:28 -0500
Subject: [net-dns-users] Release candidate for Net::DNS 0.82
In-Reply-To: <54B51EF9.7070402@nlnetlabs.nl>
References: <54B51EF9.7070402@nlnetlabs.nl>
Message-ID: <4E429B96-7FDB-42DE-A36F-30F83E088D1B@ogud.com>

While slightly off topic. 
Are there plans to roll Net::DNS::SEC into this distribution,
in modern times it is strange to have DNSSEC records in one distribution but newly defined records in this one. 
DNSSEC is now stable protocol and should be considered integral part of DNS. 

    Olafur


> On Jan 13, 2015, at 8:34 AM, Willem Toorop <willem at NLnetLabs.nl> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear users of Net::DNS,
> 
> We have a candidate for the upcoming single bugfix/feature release 0.82
> of Net::DNS.
> 
> This release adds support for upstream nameservers to be specified as
> IPv6 link-local addresses with scope_id; either directly on Resolver
> construction or with the nameservers method, or via a nameserver keyword
> in a resolver configuration file ( /etc/resolv.conf ).
> 
> Please review carefully. If no issues arise, the actual release will
> follow Tuesday the 20th of January 2015.
> 
> link 	http://www.net-dns.org/download/Net-DNS-0.81_01.tar.gz
> sha1 	e69a928219eb72ecd89855c8b239d823a24424f5
> 
> Changes
> =======
> Fix rt.cpan.org #100385
> 
> 	Support for IPv6 link-local addresses with scope_id
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQIcBAEBAgAGBQJUtR75AAoJEOX4+CEvd6SYyBIP/3gy65xbTS3xdeqbvUNYtxgi
> NN3iIVcL2KDOjfaeav5pPK7oZjvwOhZzZTbhLynrVWKZz3xe2qWDcFZ2E7IudEsa
> EtrfIXpNJ5AFz/BBiR4/k/WEXEQEuhyKes8lKfgbUQXtKKXYRbP2wqnjF/s/uxUy
> uZKRzy4U2UjgMGtxPN8lPF6TzKykEOlR3uiSa1k2j8uvNFxZa4SkPq9PYLa1oClA
> ezegAQsPRWhFeUiqPbhnRXHNOGYOyyiBVwwAHyjoDmEPE7nDD3lnpnnB+TOlfqfD
> 407xo340a4K6vKEqw8pTgRjZRwzok+/e22ibIU7aEevYT3bJQpssMcSVSEiKH5Sb
> aGotr7CO+/THi3u/Hk3VnGuiqBnckgQFKaeOJJOy+9tAqhT7dXSQ4kXM6igYtay4
> X4I8daVYw0XlTGMHIVTEMhdCz437d7+NXB7KrhzodM2UZrAf6et5TuTLrqFkERYK
> BhPWkR3g0nNrK7phd+zKNDlnE8rYHFTfEby8XPQS9IY+7PomQE/5r3CPJ8edcDVH
> zk7Ep5MS4K1uuGC4egYk75+2O3S1RTeJSxhMc6qz1LmAIrWjpOcsVUryhojGgtqg
> 3pHtjPDcvnddTUqxjywVwyG+Ek+ZUEFbSKzbJyNEMm6KSB1e9gmUjyOJidGuq6Z+
> wCo5q4l+alw2W1OWTRD4
> =NMkT
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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 Jan 14 17:31:30 2015
From: rwfranks at acm.org (Dick Franks)
Date: Wed, 14 Jan 2015 17:31:30 +0000
Subject: [net-dns-users] Release candidate for Net::DNS 0.82
In-Reply-To: <4E429B96-7FDB-42DE-A36F-30F83E088D1B@ogud.com>
References: <54B51EF9.7070402@nlnetlabs.nl>
 <4E429B96-7FDB-42DE-A36F-30F83E088D1B@ogud.com>
Message-ID: <CAKW6Ri68koKBEMMPPpbx3e0C__x01gObZJrOyookiPCSV7uD9g@mail.gmail.com>

Olafur,

Olaf Kolkman and I discussed this prickly topic a few years ago.  The
decision reached then was to leave the distributions as they now are.
Nothing has changed to invalidate the arguments on which that decision was
based.

In many ways it would be far more convenient if the two distributions could
be integrated.  It certainly would make maintenance and regression testing
significantly easier.

However, there are at least 30 countries where the import and/or use of
strong encryption is illegal, can only be done under license, or where the
legal position is uncertain.

Combining the two distributions would either completely preclude the use of
Net::DNS in some territories or expose users to the risk of prosecution
because the distribution contains illegal content even if not required for
whatever it is they are attempting to do.

Packaging Net::DNS::SEC as an optional extension maximises the availability
of Net::DNS and ensures that enabling the cryptographic components requires
a deliberate installation step for which the individual user then becomes
legally responsible.


Dick
________________________


On 14 January 2015 at 15:49, Olafur Gudmundsson <ogud at ogud.com> wrote:

> While slightly off topic.
> Are there plans to roll Net::DNS::SEC into this distribution,
> in modern times it is strange to have DNSSEC records in one distribution
> but newly defined records in this one.
> DNSSEC is now stable protocol and should be considered integral part of
> DNS.
>
>     Olafur
>
>
> > On Jan 13, 2015, at 8:34 AM, Willem Toorop <willem at NLnetLabs.nl> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Dear users of Net::DNS,
> >
> > We have a candidate for the upcoming single bugfix/feature release 0.82
> > of Net::DNS.
> >
> > This release adds support for upstream nameservers to be specified as
> > IPv6 link-local addresses with scope_id; either directly on Resolver
> > construction or with the nameservers method, or via a nameserver keyword
> > in a resolver configuration file ( /etc/resolv.conf ).
> >
> > Please review carefully. If no issues arise, the actual release will
> > follow Tuesday the 20th of January 2015.
> >
> > link  http://www.net-dns.org/download/Net-DNS-0.81_01.tar.gz
> > sha1  e69a928219eb72ecd89855c8b239d823a24424f5
> >
> > Changes
> > =======
> > Fix rt.cpan.org #100385
> >
> >       Support for IPv6 link-local addresses with scope_id
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQIcBAEBAgAGBQJUtR75AAoJEOX4+CEvd6SYyBIP/3gy65xbTS3xdeqbvUNYtxgi
> > NN3iIVcL2KDOjfaeav5pPK7oZjvwOhZzZTbhLynrVWKZz3xe2qWDcFZ2E7IudEsa
> > EtrfIXpNJ5AFz/BBiR4/k/WEXEQEuhyKes8lKfgbUQXtKKXYRbP2wqnjF/s/uxUy
> > uZKRzy4U2UjgMGtxPN8lPF6TzKykEOlR3uiSa1k2j8uvNFxZa4SkPq9PYLa1oClA
> > ezegAQsPRWhFeUiqPbhnRXHNOGYOyyiBVwwAHyjoDmEPE7nDD3lnpnnB+TOlfqfD
> > 407xo340a4K6vKEqw8pTgRjZRwzok+/e22ibIU7aEevYT3bJQpssMcSVSEiKH5Sb
> > aGotr7CO+/THi3u/Hk3VnGuiqBnckgQFKaeOJJOy+9tAqhT7dXSQ4kXM6igYtay4
> > X4I8daVYw0XlTGMHIVTEMhdCz437d7+NXB7KrhzodM2UZrAf6et5TuTLrqFkERYK
> > BhPWkR3g0nNrK7phd+zKNDlnE8rYHFTfEby8XPQS9IY+7PomQE/5r3CPJ8edcDVH
> > zk7Ep5MS4K1uuGC4egYk75+2O3S1RTeJSxhMc6qz1LmAIrWjpOcsVUryhojGgtqg
> > 3pHtjPDcvnddTUqxjywVwyG+Ek+ZUEFbSKzbJyNEMm6KSB1e9gmUjyOJidGuq6Z+
> > wCo5q4l+alw2W1OWTRD4
> > =NMkT
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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/20150114/21893a8d/attachment.htm>

From ogud at ogud.com  Wed Jan 14 21:16:20 2015
From: ogud at ogud.com (Olafur Gudmundsson)
Date: Wed, 14 Jan 2015 16:16:20 -0500 (EST)
Subject: [net-dns-users] merger NET::DNS::SEC into Net::DNS Re: Release
	candidate for Net::DNS 0.82
In-Reply-To: <CAKW6Ri68koKBEMMPPpbx3e0C__x01gObZJrOyookiPCSV7uD9g@mail.gmail.com>
References: <54B51EF9.7070402@nlnetlabs.nl> 
 <4E429B96-7FDB-42DE-A36F-30F83E088D1B@ogud.com> 
 <CAKW6Ri68koKBEMMPPpbx3e0C__x01gObZJrOyookiPCSV7uD9g@mail.gmail.com>
Message-ID: <1421270180.28668969@apps.rackspace.com>

Dick thank you for your quick reply. 
Even if a full merge is not possible/desirable, I would strongly
argue for a partial merge where all the RRtypes that are currently defined only in 
::Sec be merged into Net::DNS. I.e. everything in directory RR as none of that uses
any crypto. 
Right now anyone that wants to even be able to display DNSKEY record needs to install Net::DNS::SEC 

Olafur 


-----Original Message-----
From: "Dick Franks" <rwfranks at acm.org>
Sent: Wednesday, 14 January, 2015 12:31
To: net-dns-users at nlnetlabs.nl
Subject: Re: [net-dns-users] Release candidate for Net::DNS 0.82

_______________________________________________
net-dns-users mailing list
net-dns-users at nlnetlabs.nl
https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
Olafur,

Olaf Kolkman and I discussed this prickly topic a few years ago.  The
decision reached then was to leave the distributions as they now are.
Nothing has changed to invalidate the arguments on which that decision was
based.

In many ways it would be far more convenient if the two distributions could
be integrated.  It certainly would make maintenance and regression testing
significantly easier.

However, there are at least 30 countries where the import and/or use of
strong encryption is illegal, can only be done under license, or where the
legal position is uncertain.

Combining the two distributions would either completely preclude the use of
Net::DNS in some territories or expose users to the risk of prosecution
because the distribution contains illegal content even if not required for
whatever it is they are attempting to do.

Packaging Net::DNS::SEC as an optional extension maximises the availability
of Net::DNS and ensures that enabling the cryptographic components requires
a deliberate installation step for which the individual user then becomes
legally responsible.


Dick
________________________


On 14 January 2015 at 15:49, Olafur Gudmundsson <ogud at ogud.com> wrote:

> While slightly off topic.
> Are there plans to roll Net::DNS::SEC into this distribution,
> in modern times it is strange to have DNSSEC records in one distribution
> but newly defined records in this one.
> DNSSEC is now stable protocol and should be considered integral part of
> DNS.
>
>     Olafur
>
>
> > On Jan 13, 2015, at 8:34 AM, Willem Toorop <willem at NLnetLabs.nl> wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Dear users of Net::DNS,
> >
> > We have a candidate for the upcoming single bugfix/feature release 0.82
> > of Net::DNS.
> >
> > This release adds support for upstream nameservers to be specified as
> > IPv6 link-local addresses with scope_id; either directly on Resolver
> > construction or with the nameservers method, or via a nameserver keyword
> > in a resolver configuration file ( /etc/resolv.conf ).
> >
> > Please review carefully. If no issues arise, the actual release will
> > follow Tuesday the 20th of January 2015.
> >
> > link  http://www.net-dns.org/download/Net-DNS-0.81_01.tar.gz
> > sha1  e69a928219eb72ecd89855c8b239d823a24424f5
> >
> > Changes
> > =======
> > Fix rt.cpan.org #100385
> >
> >       Support for IPv6 link-local addresses with scope_id
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQIcBAEBAgAGBQJUtR75AAoJEOX4+CEvd6SYyBIP/3gy65xbTS3xdeqbvUNYtxgi
> > NN3iIVcL2KDOjfaeav5pPK7oZjvwOhZzZTbhLynrVWKZz3xe2qWDcFZ2E7IudEsa
> > EtrfIXpNJ5AFz/BBiR4/k/WEXEQEuhyKes8lKfgbUQXtKKXYRbP2wqnjF/s/uxUy
> > uZKRzy4U2UjgMGtxPN8lPF6TzKykEOlR3uiSa1k2j8uvNFxZa4SkPq9PYLa1oClA
> > ezegAQsPRWhFeUiqPbhnRXHNOGYOyyiBVwwAHyjoDmEPE7nDD3lnpnnB+TOlfqfD
> > 407xo340a4K6vKEqw8pTgRjZRwzok+/e22ibIU7aEevYT3bJQpssMcSVSEiKH5Sb
> > aGotr7CO+/THi3u/Hk3VnGuiqBnckgQFKaeOJJOy+9tAqhT7dXSQ4kXM6igYtay4
> > X4I8daVYw0XlTGMHIVTEMhdCz437d7+NXB7KrhzodM2UZrAf6et5TuTLrqFkERYK
> > BhPWkR3g0nNrK7phd+zKNDlnE8rYHFTfEby8XPQS9IY+7PomQE/5r3CPJ8edcDVH
> > zk7Ep5MS4K1uuGC4egYk75+2O3S1RTeJSxhMc6qz1LmAIrWjpOcsVUryhojGgtqg
> > 3pHtjPDcvnddTUqxjywVwyG+Ek+ZUEFbSKzbJyNEMm6KSB1e9gmUjyOJidGuq6Z+
> > wCo5q4l+alw2W1OWTRD4
> > =NMkT
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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
>



From rwfranks at acm.org  Thu Jan 15 13:36:04 2015
From: rwfranks at acm.org (Dick Franks)
Date: Thu, 15 Jan 2015 13:36:04 +0000
Subject: [net-dns-users] merger NET::DNS::SEC into Net::DNS Re: Release
 candidate for Net::DNS 0.82
In-Reply-To: <1421270180.28668969@apps.rackspace.com>
References: <54B51EF9.7070402@nlnetlabs.nl>
 <4E429B96-7FDB-42DE-A36F-30F83E088D1B@ogud.com>
 <CAKW6Ri68koKBEMMPPpbx3e0C__x01gObZJrOyookiPCSV7uD9g@mail.gmail.com>
 <1421270180.28668969@apps.rackspace.com>
Message-ID: <CAKW6Ri7TW=Z3NPQJo943W3nmKVgTvtT96XOpKQs8TvB=M+DD9g@mail.gmail.com>

On 14 January 2015 at 21:16, Olafur Gudmundsson <ogud at ogud.com> wrote:

> Dick thank you for your quick reply.
> Even if a full merge is not possible/desirable, I would strongly
> argue for a partial merge where all the RRtypes that are currently defined
> only in
> ::Sec be merged into Net::DNS. I.e. everything in directory RR as none of
> that uses
> any crypto.
>

RRSIG.pm and SIG.pm uses crypto


> Right now anyone that wants to even be able to display DNSKEY record needs
> to install Net::DNS::SEC
>

I see your argument and will explore the feasibility of repackaging to
achieve a less entangled relationship between the two packages.


Dick
<net-dns-users at nlnetlabs.nl>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150115/7c9c2e79/attachment.htm>

From dougb at dougbarton.us  Sun Jan 18 00:59:26 2015
From: dougb at dougbarton.us (Doug Barton)
Date: Sat, 17 Jan 2015 16:59:26 -0800
Subject: [net-dns-users] merger NET::DNS::SEC into Net::DNS Re: Release
 candidate for Net::DNS 0.82
In-Reply-To: <CAKW6Ri7TW=Z3NPQJo943W3nmKVgTvtT96XOpKQs8TvB=M+DD9g@mail.gmail.com>
References: <54B51EF9.7070402@nlnetlabs.nl>
 <4E429B96-7FDB-42DE-A36F-30F83E088D1B@ogud.com>
 <CAKW6Ri68koKBEMMPPpbx3e0C__x01gObZJrOyookiPCSV7uD9g@mail.gmail.com>
 <1421270180.28668969@apps.rackspace.com>
 <CAKW6Ri7TW=Z3NPQJo943W3nmKVgTvtT96XOpKQs8TvB=M+DD9g@mail.gmail.com>
Message-ID: <54BB056E.7080206@dougbarton.us>

On 1/15/15 5:36 AM, Dick Franks wrote:
>
> On 14 January 2015 at 21:16, Olafur Gudmundsson <ogud at ogud.com
> <mailto:ogud at ogud.com>> wrote:
>
>     Dick thank you for your quick reply.
>     Even if a full merge is not possible/desirable, I would strongly
>     argue for a partial merge where all the RRtypes that are currently
>     defined only in
>     ::Sec be merged into Net::DNS. I.e. everything in directory RR as
>     none of that uses
>     any crypto.
>
>
> RRSIG.pm and SIG.pm uses crypto
>
>     Right now anyone that wants to even be able to display DNSKEY record
>     needs to install Net::DNS::SEC
>
>
> I see your argument and will explore the feasibility of repackaging to
> achieve a less entangled relationship between the two packages.

Yes please. :)





From willem at nlnetlabs.nl  Tue Jan 20 14:16:54 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 20 Jan 2015 15:16:54 +0100
Subject: [net-dns-users] Net::DNS 0.82 released
Message-ID: <54BE6356.1090103@nlnetlabs.nl>

Dear users of Net::DNS,

We have just released the single bugfix/feature release version 0.82 of
Net::DNS.

This release adds support for upstream nameservers to be specified as
IPv6 link-local addresses with scope_id; either directly on Resolver
construction or with the nameservers method, or via a nameserver keyword
in a resolver configuration file ( /etc/resolv.conf ).


link 	http://www.net-dns.org/download/Net-DNS-0.82.tar.gz
sha1 	c7c34155313b716cc2644af59630c103a5741380

Changes
=======
Fix rt.cpan.org #100385

        Support for IPv6 link-local addresses with scope_id



From willem at nlnetlabs.nl  Tue Jan 20 14:20:11 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 20 Jan 2015 15:20:11 +0100
Subject: [net-dns-users] Net::DNS 0.82 released
Message-ID: <54BE641B.3080201@nlnetlabs.nl>

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

Now with PGP signature

Dear users of Net::DNS,

We have just released the single bugfix/feature release version 0.82 of
Net::DNS.

This release adds support for upstream nameservers to be specified as
IPv6 link-local addresses with scope_id; either directly on Resolver
construction or with the nameservers method, or via a nameserver keyword
in a resolver configuration file ( /etc/resolv.conf ).


link 	http://www.net-dns.org/download/Net-DNS-0.82.tar.gz
sha1 	c7c34155313b716cc2644af59630c103a5741380

Changes
=======
Fix rt.cpan.org #100385

        Support for IPv6 link-local addresses with scope_id

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJUvmQbAAoJEOX4+CEvd6SYxnkP/3NDSBlRPOAL9pOV+GRIqbhh
eICpjdldJSX+yurqtp1YRRD7EraZm927GEmV3JXMwpLt57xY2eM5NhKpPufV0OwX
HkpDBVEXrNqTX53l703tuAL4c0POwP0BXnvtXtyTDus5h3MFYWksRX/m7YGIGIUc
tiBMEp9n2FZQ/KM5Bhmh8MUiRiLyijOSvKxsVXK/xiJ/y6TK26AQGpZBto/54W8f
xb7wWmyqVK4TujYAH1yNvvH9+Jbx0S5tfDvnG8YTmvQ4iMne+s52t1ALZqtiVwO3
AmoDz3xJwPtPub787vIrf5R2RU7IgqERGXVUsstBduYPciFuZ5zwty00A8ZOruWG
4ByhqniNUrUNIpHsePRIrO5+5L/Z9qfY4igeWZvD/nYASV/twm7JkGU14IYUUqGD
fbB3UyezYTsadvx9OzT+OM8lO/P3pCTagoo6IxT1NsHEjfrc2Gztgvdk0eZD6b2R
zZsz3MQkZfaM8/LW5QgaL3S+ihVxmQ7m+mNRA5NgOFZjVBPURZAd+ey6BXepoM/z
zb4uz4JeRlonBlGHvzMnfI9s7hT7tU6CBCZ2B7tO5RWvy4a/iKn6HthJunzkPUWc
+36dv4ffk8R2ehFq50onPpqPTcblrYX6dooy5t1maAHTIn6p2wdsR6+scla2hqcv
QcyDSu8BJgJ1G3RoOB4C
=ci6E
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Wed Feb  4 13:40:17 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 04 Feb 2015 14:40:17 +0100
Subject: [net-dns-users] Release candidate for Net::DNS::SEC 0.22
Message-ID: <54D22141.1050901@nlnetlabs.nl>

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

Dear users of Net::DNS::SEC,

We have a candidate for the upcoming 0.22 release of Net::DNS::SEC.
This release introduces the following new features and improvements:

* RRSIG::siginception and RRSIG::siginception in time values

	RRSIG::siginception and RRSIG::siginception now returns,
	besides the format date in string context like before, the date
	as seconds since epoch in numeric context.

* ECDSA and GOST signature creation and verification

	The optional Crypt::OpenSSL::EC, Crypt::OpenSSL::ECDSA and
	Digest::GOST need to be available to enable this feature.

* Version requirements detection for optional modules

	Besides the optional modules just mentioned,
	Crypt::OpenSSL::Random is an optional module which enables
	private key generation and Digest::BubbleBabble enables
	Net::DNS::RR::DS::babble

Besides these features, architectural modifications have been made to
loosen the Net::DNS::RR::* classes from the Net::DNS::SEC package, so
that they can be added to the regular Net::DNS in the future, although
without cryptographic operations.

To this end, all cryptographic operations are now concentrated in
their own modules Net::DNS::SEC::RSA, Net::DNS::SEC::DSA,
Net::DNS::SEC::ECDSA and Net::DNS::SEC::ECCGOST.

An affected module of this rework is Net::DNS::SEC::Private.   This
module previously performed cryptographic operations with the
generate_rsa, new_rsa_priv and dump_rsa_* methods.

The generate_rsa and new_rsa_priv methods are still available as
before, but the dump_rsa_* methods are now available only if the
generate_rsa or new_rsa_priv function were used to create the
Net::DNS::SEC::Private object.  This is different from previous behaviour.

Note that the Private.pm module had and has the following text at the
top of its documentation: "The class is written to be used only in the
context of the Net::DNS::RR::RRSIG create method. This class is not
designed to interact with any other system."

If you  depend upon this module nonetheless, please let us know,
preferably with a use case.

Please review this version carefully and regression-test it with your
software. If no issues arise, the actual release will follow Wedensday
the 11th of February 2015.

link 	https://www.net-dns.org/download/Net-DNS-SEC-0.21_10.tar.gz
sha1 	8f6951a0e4e6fa4d2dc7fbc4147a36945ed5631d

Changes
=======
   Fix: rt.cpan.org #101184
   make siginception and sigexpiration available as time() values

   Fix: rt.cpan.org #101183
   wrong URL for blog in README

   Fix: rt.cpan.org #83031
   [RRSIG] lack of ECDSA support

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU0iFAAAoJEOX4+CEvd6SYjroP/j704GRfZcnrvvpBxKzb/tX5
9syKawcM0ualyQ8nhojPj7+qybXvMMF7Zh4h0oiGe2riVi7gLZBoZvFqAXO9kPzD
zJZSn2bDgZz4FVyWzFcooZ49y9MxhHo8AZEFgejqZLPmIH0zQCvrrlb+OYYBav8C
1iTlOegWvm5tYMmh4qveMT5CpEvPtmEFs5HeVyQ0mL7KBJbpKrnHgP3BAzzIHl4H
me1EqBl7smGPis0l9N2UA2TBDFABzezA5XtOafzLGkmdnU+FWfIiiJEHpGKYEEPz
35ONVEwiikEc/sHOHczVHmK7mNtP91NFMs9c2ZTkDLb4jds+DPRM0Lv8/GyVxKGW
4QTMkyyf8sw8iPW78uvW6K5IPlT0V8ZbbryiUVLWbyEQZtqX4PzFYz8JK2yw6dKj
X1Ui4OxPMixqPkj5rlyK9LqJvSvvhwqS+34Vc9x07H76hAdbiq02905xV/kdDmCa
FqIyz+/dSeCsAGcwsh2gm/ayRih3HruIl3C2BtkqJsZBPPk+M9vc47OmNtVF+vjG
NDTwEDgz4KxBKoRWd5qJfbGXI0OQ2rFiOdWfUmcDXkBApLraBuD3+rL8cL6dSuhZ
pBiwqOze+6GIv5jIvcaryUzQKU32gIuQfj/Y5/37U+C9S5fXlZ3MgvchXfZQj5jO
nwSRdEeYrfa+JEFdjgRo
=6Wpt
-----END PGP SIGNATURE-----


From beldmit at gmail.com  Wed Feb  4 13:54:23 2015
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Wed, 4 Feb 2015 16:54:23 +0300
Subject: [net-dns-users] Release candidate for Net::DNS::SEC 0.22
In-Reply-To: <54D22141.1050901@nlnetlabs.nl>
References: <54D22141.1050901@nlnetlabs.nl>
Message-ID: <CADqLbzKPxGPVq-NBcp1kQVpqmcUi3SGS1=N_NLycWkvf0FAyyg@mail.gmail.com>

Hello Willem,

Do you use Digest::GOST::Cryptopro for GOST DS verification?

Thank you!



On Wed, Feb 4, 2015 at 4:40 PM, Willem Toorop <willem at nlnetlabs.nl> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear users of Net::DNS::SEC,
>
> We have a candidate for the upcoming 0.22 release of Net::DNS::SEC.
> This release introduces the following new features and improvements:
>
> * RRSIG::siginception and RRSIG::siginception in time values
>
>         RRSIG::siginception and RRSIG::siginception now returns,
>         besides the format date in string context like before, the date
>         as seconds since epoch in numeric context.
>
> * ECDSA and GOST signature creation and verification
>
>         The optional Crypt::OpenSSL::EC, Crypt::OpenSSL::ECDSA and
>         Digest::GOST need to be available to enable this feature.
>
> * Version requirements detection for optional modules
>
>         Besides the optional modules just mentioned,
>         Crypt::OpenSSL::Random is an optional module which enables
>         private key generation and Digest::BubbleBabble enables
>         Net::DNS::RR::DS::babble
>
> Besides these features, architectural modifications have been made to
> loosen the Net::DNS::RR::* classes from the Net::DNS::SEC package, so
> that they can be added to the regular Net::DNS in the future, although
> without cryptographic operations.
>
> To this end, all cryptographic operations are now concentrated in
> their own modules Net::DNS::SEC::RSA, Net::DNS::SEC::DSA,
> Net::DNS::SEC::ECDSA and Net::DNS::SEC::ECCGOST.
>
> An affected module of this rework is Net::DNS::SEC::Private.   This
> module previously performed cryptographic operations with the
> generate_rsa, new_rsa_priv and dump_rsa_* methods.
>
> The generate_rsa and new_rsa_priv methods are still available as
> before, but the dump_rsa_* methods are now available only if the
> generate_rsa or new_rsa_priv function were used to create the
> Net::DNS::SEC::Private object.  This is different from previous behaviour.
>
> Note that the Private.pm module had and has the following text at the
> top of its documentation: "The class is written to be used only in the
> context of the Net::DNS::RR::RRSIG create method. This class is not
> designed to interact with any other system."
>
> If you  depend upon this module nonetheless, please let us know,
> preferably with a use case.
>
> Please review this version carefully and regression-test it with your
> software. If no issues arise, the actual release will follow Wedensday
> the 11th of February 2015.
>
> link    https://www.net-dns.org/download/Net-DNS-SEC-0.21_10.tar.gz
> sha1    8f6951a0e4e6fa4d2dc7fbc4147a36945ed5631d
>
> Changes
> =======
>    Fix: rt.cpan.org #101184
>    make siginception and sigexpiration available as time() values
>
>    Fix: rt.cpan.org #101183
>    wrong URL for blog in README
>
>    Fix: rt.cpan.org #83031
>    [RRSIG] lack of ECDSA support
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJU0iFAAAoJEOX4+CEvd6SYjroP/j704GRfZcnrvvpBxKzb/tX5
> 9syKawcM0ualyQ8nhojPj7+qybXvMMF7Zh4h0oiGe2riVi7gLZBoZvFqAXO9kPzD
> zJZSn2bDgZz4FVyWzFcooZ49y9MxhHo8AZEFgejqZLPmIH0zQCvrrlb+OYYBav8C
> 1iTlOegWvm5tYMmh4qveMT5CpEvPtmEFs5HeVyQ0mL7KBJbpKrnHgP3BAzzIHl4H
> me1EqBl7smGPis0l9N2UA2TBDFABzezA5XtOafzLGkmdnU+FWfIiiJEHpGKYEEPz
> 35ONVEwiikEc/sHOHczVHmK7mNtP91NFMs9c2ZTkDLb4jds+DPRM0Lv8/GyVxKGW
> 4QTMkyyf8sw8iPW78uvW6K5IPlT0V8ZbbryiUVLWbyEQZtqX4PzFYz8JK2yw6dKj
> X1Ui4OxPMixqPkj5rlyK9LqJvSvvhwqS+34Vc9x07H76hAdbiq02905xV/kdDmCa
> FqIyz+/dSeCsAGcwsh2gm/ayRih3HruIl3C2BtkqJsZBPPk+M9vc47OmNtVF+vjG
> NDTwEDgz4KxBKoRWd5qJfbGXI0OQ2rFiOdWfUmcDXkBApLraBuD3+rL8cL6dSuhZ
> pBiwqOze+6GIv5jIvcaryUzQKU32gIuQfj/Y5/37U+C9S5fXlZ3MgvchXfZQj5jO
> nwSRdEeYrfa+JEFdjgRo
> =6Wpt
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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/20150204/ed10df57/attachment.htm>

From willem at nlnetlabs.nl  Wed Feb  4 14:27:27 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 04 Feb 2015 15:27:27 +0100
Subject: [net-dns-users] Release candidate for Net::DNS::SEC 0.22
In-Reply-To: <CADqLbzKPxGPVq-NBcp1kQVpqmcUi3SGS1=N_NLycWkvf0FAyyg@mail.gmail.com>
References: <54D22141.1050901@nlnetlabs.nl>
 <CADqLbzKPxGPVq-NBcp1kQVpqmcUi3SGS1=N_NLycWkvf0FAyyg@mail.gmail.com>
Message-ID: <54D22C4F.8080109@nlnetlabs.nl>

Hi Dmitry,

That's right.
Cheers,

-- Willem

Op 04-02-15 om 14:54 schreef Dmitry Belyavsky:
> Hello Willem,
> 
> Do you use Digest::GOST::Cryptopro for GOST DS verification?
> 
> Thank you!
> 
> 
> 
> On Wed, Feb 4, 2015 at 4:40 PM, Willem Toorop <willem at nlnetlabs.nl
> <mailto:willem at nlnetlabs.nl>> wrote:
> 
> Dear users of Net::DNS::SEC,
> 
> We have a candidate for the upcoming 0.22 release of Net::DNS::SEC.
> This release introduces the following new features and improvements:
> 
> * RRSIG::siginception and RRSIG::siginception in time values
> 
>         RRSIG::siginception and RRSIG::siginception now returns,
>         besides the format date in string context like before, the date
>         as seconds since epoch in numeric context.
> 
> * ECDSA and GOST signature creation and verification
> 
>         The optional Crypt::OpenSSL::EC, Crypt::OpenSSL::ECDSA and
>         Digest::GOST need to be available to enable this feature.
> 
> * Version requirements detection for optional modules
> 
>         Besides the optional modules just mentioned,
>         Crypt::OpenSSL::Random is an optional module which enables
>         private key generation and Digest::BubbleBabble enables
>         Net::DNS::RR::DS::babble
> 
> Besides these features, architectural modifications have been made to
> loosen the Net::DNS::RR::* classes from the Net::DNS::SEC package, so
> that they can be added to the regular Net::DNS in the future, although
> without cryptographic operations.
> 
> To this end, all cryptographic operations are now concentrated in
> their own modules Net::DNS::SEC::RSA, Net::DNS::SEC::DSA,
> Net::DNS::SEC::ECDSA and Net::DNS::SEC::ECCGOST.
> 
> An affected module of this rework is Net::DNS::SEC::Private.   This
> module previously performed cryptographic operations with the
> generate_rsa, new_rsa_priv and dump_rsa_* methods.
> 
> The generate_rsa and new_rsa_priv methods are still available as
> before, but the dump_rsa_* methods are now available only if the
> generate_rsa or new_rsa_priv function were used to create the
> Net::DNS::SEC::Private object.  This is different from previous
> behaviour.
> 
> Note that the Private.pm module had and has the following text at the
> top of its documentation: "The class is written to be used only in the
> context of the Net::DNS::RR::RRSIG create method. This class is not
> designed to interact with any other system."
> 
> If you  depend upon this module nonetheless, please let us know,
> preferably with a use case.
> 
> Please review this version carefully and regression-test it with your
> software. If no issues arise, the actual release will follow Wedensday
> the 11th of February 2015.
> 
> link    https://www.net-dns.org/download/Net-DNS-SEC-0.21_10.tar.gz
> sha1 <https://www.net-dns.org/download/Net-DNS-SEC-0.21_10.tar.gz
> sha1>    8f6951a0e4e6fa4d2dc7fbc4147a36945ed5631d
> 
> Changes
> =======
>    Fix: rt.cpan.org <http://rt.cpan.org> #101184
>    make siginception and sigexpiration available as time() values
> 
>    Fix: rt.cpan.org <http://rt.cpan.org> #101183
>    wrong URL for blog in README
> 
>    Fix: rt.cpan.org <http://rt.cpan.org> #83031
>    [RRSIG] lack of ECDSA support
> 
>     _______________________________________________
>     net-dns-users mailing list
>     net-dns-users at nlnetlabs.nl <mailto:net-dns-users at nlnetlabs.nl>
>     https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
> 
> 
> 
> 
> -- 
> SY, Dmitry Belyavsky
> 
> 
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
> 



From willem at nlnetlabs.nl  Wed Feb 11 14:31:11 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 11 Feb 2015 15:31:11 +0100
Subject: [net-dns-users] Net::DNS::SEC 0.22 released
Message-ID: <54DB67AF.1000500@nlnetlabs.nl>

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

Dear users of Net::DNS::SEC,

We have a new Net::DNS::SEC release: 0.22.

This release introduces the following new features and improvements:

* RRSIG::siginception and RRSIG::siginception in time values

	RRSIG::siginception and RRSIG::siginception now return, besides
	the format date in string context like before, the date as
	seconds since epoch in numeric context.

* ECDSA and GOST signature creation and verification

	The optional Crypt::OpenSSL::EC, Crypt::OpenSSL::ECDSA and
	Digest::GOST need to be available to enable this feature.

* Version requirements detection for optional modules

	Besides the optional modules just mentioned,
	Crypt::OpenSSL::Random is an optional module which enables
	private key generation and Digest::BubbleBabble enables
	Net::DNS::RR::DS::babble

Besides these features, architectural modifications have been made to
loosen the Net::DNS::RR::* classes from the Net::DNS::SEC package, so
that they can be added to the regular Net::DNS in the future, although
without cryptographic operations.

To this end, all cryptographic operations are now concentrated in their
own modules Net::DNS::SEC::RSA, Net::DNS::SEC::DSA, Net::DNS::SEC::ECDSA
and Net::DNS::SEC::ECCGOST.

An affected module of this rework is Net::DNS::SEC::Private. This module
previously performed cryptographic operations with the generate_rsa,
new_rsa_priv and dump_rsa_* methods.

The generate_rsa and new_rsa_priv methods are still available as before,
but the dump_rsa_* methods are now available only if the generate_rsa or
new_rsa_priv function were used to create the Net::DNS::SEC::Private
object. This is different from previous behaviour (i.e. not backwards
compatible).


link 	https://www.net-dns.org/download/Net-DNS-SEC-0.22.tar.gz
sha1 	29bdb3191f7115f08feae54938e24a9a9ff2b71d
asc 	https://www.net-dns.org/download/Net-DNS-SEC-0.22.tar.gz.asc

Changes
=======
   Fix: rt.cpan.org #101184
   make siginception and sigexpiration available as time() values

   Fix: rt.cpan.org #101183
   wrong URL for blog in README

   Fix: rt.cpan.org #83031
   [RRSIG] lack of ECDSA support

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU22euAAoJEOX4+CEvd6SY/eMP/RAU7k/ChHbTg8Iqccy9q70j
Gk7XZPiZdsbD40lbi8rzWx7OLjcocS+5a37TBcM6MAToaeppICU+IxaJrvd0vrmF
D0OiemcAygngZt7uNEGToN62rWaTZ2Om8wSBTSBlGWIFSl2c7wfIgQDXX+HTr42G
udOy5R4RwrTPdW9vIPf4TbGeZjOmvKqdv5Rcp66xCToLa7gpa89WwFei+fGh781p
F1SdXhCFfOO7/8mjy+SYSue+mrUP70YojmYzRjSmFY3ZKxWc8X3bSF11iwbaUqwW
YHwZ+mAp5wMnk+8KJ88yh0vjCXvo3PfSBGSVoWe8YcCf2DUmfCilc4oPu4R1bpo/
gw2rPoRMTfsMrm6Sx0u2dro7EE4zLHUH3r8VIrGlDBoKa+wqGX8mL0ErInJU+HLZ
H5svevx2ejfz9LRD2awVJ3z+uboKQkZvL0dbYr6cEL+csJ5toSICTo5fh3yVRwL6
ZxXNbwJfsO0azyqwnBwPz0Weccky7+qzupYPyQzSXGFG8h75iTUZe5n5sczDLdsU
9yrfD2DkXFRPRNM54A2gvZFBLn8s9L8ZIOSww9P348vJysJi1GEVqDtFwQDpQym0
xjakcTfFHaHMi/LkJqgYNxOVATfwCNwKcy54cYMHT1tJsMyqQqE8VP4WyyQBMbnr
aKYHZDyaqAT0ljUYaB3N
=SJCx
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Thu Feb 19 20:58:52 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 19 Feb 2015 21:58:52 +0100
Subject: [net-dns-users] Release candidate for Net::DNS 0.83
Message-ID: <54E64E8C.1060707@nlnetlabs.nl>

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

Dear users of Net::DNS,

We have a candidate for the upcoming bugfix release 0.83 of Net::DNS.

As discussed on the net-dns-users mailing list and also announced with
the previous Net::DNS::SEC release, we are planning to merge the DNSSEC
RR?s that are currently in the Net::DNS::SEC module (DS, DNSKEY, RRSIG
etc.) into Net::DNS, though without the cryptographic operations. For
the cryptographic operations (signing, verifying etc.), Net::DNS::SEC
will still be required.

This release is intended to establish a clean Net::DNS baseline, before
we start moving the RR?s over.

In anticipating of this move, this release already has the new CSYNC RR
from the draft-ietf-dnsop-child-syncronization on board for
experimentation purposes.

For a complete list of changes and bugfixes see Changes below.

If no issues arise, the actual release will follow Thursday the 26th of
February 2015.

link 	https://www.net-dns.org/download/Net-DNS-0.82_03.tar.gz
sha1 	8421aaf188a19d7bb489320c029485ef3969150e
asc 	https://www.net-dns.org/download/Net-DNS-0.82_03.tar.gz.asc

Changes
=======
Fix rt.cpan.org #101798

        AUTOLOAD error confusing w/o reference to object class

Fix rt.cpan.org #101709

        Provide separate control of IPv6 tests

Fix rt.cpan.org #101675

        MX record with 0 preference fails to parse

Fix rt.cpan.org #101405

        Install tests fail for v0.81 on Perl 5.21.7

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU5k6MAAoJEOX4+CEvd6SY6VUP+wXPHMJdiv4+jz265TpjzJsJ
SoT/yPy02WsjC2nUdyUBJJZicS+TvW2SMxSe1c/Mo561VWtaJbRWxWqv4ByQCcrE
1+UN9IpW0qFtzaImUQEbJ8kx9NRMgeabjFZ+cxwtZ8IrjLapEk+KFOiDbluAPgNg
IMdue9OcmR4QkqNNu034d77r68Uj/+oc+zSYMW/rY0qV52tBf3urS280fP2nV9xk
iBcBAWdJH6avqw9YPjUjg5Hy9zON4FmxRDad8FE1FCixh+MElEfUjVEIXyGj8mbQ
cPXVmoQl4Hv5whPnT1eEv7H3rihzolCWuXr6AAj1IXWAMl03eSrgwMq02I0toDfx
Y+Qnyvg1DW+PDJs9ChnQJt99v7rgxGDyV9kpF7jZxK96MhPIIWMcEw8wYWIbtLY3
Oe/PGcJrYOiY3PBAQ/pNLV29XsB5Pf4CNJhPgXEn/7QyFjHexnSZVC/AJlOL+0VA
wOhDJ0f2I6m7gWubvON99Ltv1J1TgmF8uzuICbn9eptYI5bav08u68z4nLtSMdZ0
dOFEZL+KMUH9CbS/8Xx2DeXxf3ZhHt9dt608Tan8hP/5+0XMthCuuhgLWK7sjq7N
K1NMV7l9XbViuVWYzYP9ZKcNfZ2/1nODk/JcfVpxJmHSJXDYcyEmr1126CSrMemP
bnWO3j75OCriI2gncwuh
=Hcip
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Thu Feb 26 15:52:14 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 26 Feb 2015 16:52:14 +0100
Subject: [net-dns-users] Net::DNS 0.83 released
Message-ID: <54EF412E.9080900@nlnetlabs.nl>

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

Dear users of Net::DNS,

We have just released version 0.83 of Net::DNS.

This release has almost only bug fixes and is intended to establish a
clean baseline in preparation for the merge of the RRs are currently
only in Net::DNS::SEC.  Note that for actual cryptographic operations
Net::DNS::SEC will still be required.

Besides the bug fixes, in anticipating of the Net::DNS::SEC RRs
rehousing, this release already has the new CSYNC RR from the
draft-ietf-dnsop-child-syncronization on board for experimentation
purposes.


link 	https://www.net-dns.org/download/Net-DNS-0.83.tar.gz
sha1 	1e0f7a3640125c5d7511324e516620ae25cac99f
asc 	https://www.net-dns.org/download/Net-DNS-0.83.tar.gz.asc

Changes
=======
Fix rt.cpan.org #101798

	AUTOLOAD error confusing w/o reference to object class

Fix rt.cpan.org #101709

	Provide separate control of IPv6 tests

Fix rt.cpan.org #101675

	MX record with 0 preference fails to parse

Fix rt.cpan.org #101405

	Install tests fail for v0.81 on Perl 5.21.7

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU70EuAAoJEOX4+CEvd6SYTRcQAIsba3kPxw+QziCdb6KDihlA
Wpl97dLrZR+UEVjjRrdVSVL5hd1+6zP+xXOmsKVU3lkgEaMdWlKDothucfRd5Bx0
pl6FeYp1h3ggLla+VDADVCdS1940lOOEoj5wMEpiLY2lPQ2IMtUxq+0Vg2gmWJOM
6mLAEqlcSRyrzslK5O8K/I30SNijrkNkGuS+Ginsi2FNC0sJ8Md1A1dbLahjYSCW
+aR1j5oraSaMgPbhmBORbucNCM0rST7VwF2p0qo6IAtDh5q/tYN7LogXSIIKt/F1
S/4a8UnDLoroZSrulibKmoF896IvU4CCu5bwBnEO3DzP8v06isgIiXzS9FSnfdZc
dIPPMILe59CKmLQJ1YjnKFZp7WNSKkiaHdmfYFxeFfqxLOwcbxc8ANJQBPDF6STn
w4qaHnqnHBIMgxKb19Pzf7duodAarqnxaxqf6fpHcblSSljdDskaj7rwz9gVNcMF
k6mGwksjMndsJudkF22O3ZAH+s4Fcbnv0yiwJIoZJK3Ai8Q2uSif8gM6SKeRC5HV
b+If7nBDSfvB7Duz3cdkAT7T+0X0yQHxfJQ0ArKophN2HHRDXZ25jvoYJF7Qa6Qg
E/9+Hrv7pcPSQbxq4i8fgyVywBmZQM6Asa5LCLccLFLStYD7TRwlN/vvzU1mP4RB
WEYVgEETotcvLOWTDlQE
=NmyP
-----END PGP SIGNATURE-----


From jtk at cymru.com  Mon May  4 16:14:48 2015
From: jtk at cymru.com (John Kristoff)
Date: Mon, 4 May 2015 11:14:48 -0500
Subject: [net-dns-users] header->do setting
Message-ID: <20150504111448.58aa979b@localhost>

Hi friends,

I was trying to create a query packet with the do flag set, but I was
having some trouble.  I crafted a header object, set the do flag and
issued the query, but it seems when I issue the query with send(), the
do flag setting is reverted to being unset.

Perhaps I'm doing something obviously wrong, but if anyone has any
sample code that issues a simple DNSSEC-enabled query I'd be interested
in seeing an example to help determine what I may be doing wrong.

Thank you,

John


From dwessels at verisign.com  Mon May  4 16:58:16 2015
From: dwessels at verisign.com (Wessels, Duane)
Date: Mon, 4 May 2015 16:58:16 +0000
Subject: [net-dns-users] header->do setting
In-Reply-To: <20150504111448.58aa979b@localhost>
References: <20150504111448.58aa979b@localhost>
Message-ID: <C2BAA189-FA0C-4CF0-92DD-DCC09D83494C@verisign.com>

I don't know if I've done it with Net::DNS::Header::do()

I usually do it with Net::DNS::Resolver::dnssec() and that works for me.

DW


> On May 4, 2015, at 9:14 AM, John Kristoff <jtk at cymru.com> wrote:
> 
> Hi friends,
> 
> I was trying to create a query packet with the do flag set, but I was
> having some trouble.  I crafted a header object, set the do flag and
> issued the query, but it seems when I issue the query with send(), the
> do flag setting is reverted to being unset.
> 
> Perhaps I'm doing something obviously wrong, but if anyone has any
> sample code that issues a simple DNSSEC-enabled query I'd be interested
> in seeing an example to help determine what I may be doing wrong.
> 
> Thank you,
> 
> John
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users



From jtk at cymru.com  Mon May  4 17:07:07 2015
From: jtk at cymru.com (John Kristoff)
Date: Mon, 4 May 2015 12:07:07 -0500
Subject: [net-dns-users] header->do setting
In-Reply-To: <C2BAA189-FA0C-4CF0-92DD-DCC09D83494C@verisign.com>
References: <20150504111448.58aa979b@localhost>
 <C2BAA189-FA0C-4CF0-92DD-DCC09D83494C@verisign.com>
Message-ID: <20150504120707.2daffc87@localhost>

On Mon, 4 May 2015 16:58:16 +0000
"Wessels, Duane" <dwessels at verisign.com> wrote:

> I don't know if I've done it with Net::DNS::Header::do()
> I usually do it with Net::DNS::Resolver::dnssec() and that works for
> me.

Aha, thanks Duane, that seems like a more correct approach for this
module.  I'll give that a go.

John


From rwfranks at acm.org  Tue May  5 12:17:17 2015
From: rwfranks at acm.org (Dick Franks)
Date: Tue, 5 May 2015 13:17:17 +0100
Subject: [net-dns-users] header->do setting
In-Reply-To: <20150504120707.2daffc87@localhost>
References: <20150504111448.58aa979b@localhost>
 <C2BAA189-FA0C-4CF0-92DD-DCC09D83494C@verisign.com>
 <20150504120707.2daffc87@localhost>
Message-ID: <CAKW6Ri4X+f-tKYmCQOPVjhRr2RS2bL1OKSz4PBV7voeF7ep2Rg@mail.gmail.com>

Thanks both.

I agree that if a user desires do-it-yourself DNSSEC, then it should be
possible to control all the relevant flags without undue interference
inside the resolver.


Dick
________________________


On 4 May 2015 at 18:07, John Kristoff <jtk at cymru.com> wrote:

> On Mon, 4 May 2015 16:58:16 +0000
> "Wessels, Duane" <dwessels at verisign.com> wrote:
>
> > I don't know if I've done it with Net::DNS::Header::do()
> > I usually do it with Net::DNS::Resolver::dnssec() and that works for
> > me.
>
> Aha, thanks Duane, that seems like a more correct approach for this
> module.  I'll give that a go.
>
> John
> _______________________________________________
> 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/20150505/71f6f0f1/attachment.htm>

From rwf at loonybin.net  Mon May 18 16:28:24 2015
From: rwf at loonybin.net (Rob Foehl)
Date: Mon, 18 May 2015 12:28:24 -0400 (EDT)
Subject: [net-dns-users] SOA rname as mailbox
Message-ID: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>

It appears that Net::DNS::RR::SOA->rname now returns a formatted address 
via Net::DNS::Mailbox1035 instead of the raw value.  It's not clear when 
this changed -- somewhere between 0.66 and 0.82, but I can't find any 
documentation or notes in the change history to that effect.

What's the recommended method to get at the domain form now without 
digging around in the object?  Just feed the rname back through
Net::DNS::Mailbox for the string value?

-Rob


From rwfranks at acm.org  Tue May 19 00:30:05 2015
From: rwfranks at acm.org (Dick Franks)
Date: Tue, 19 May 2015 01:30:05 +0100
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
Message-ID: <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>

On 18 May 2015 at 17:28, Rob Foehl <rwf at loonybin.net> wrote:

> It appears that Net::DNS::RR::SOA->rname now returns a formatted address
> via Net::DNS::Mailbox1035 instead of the raw value.


Section 3.3.13 of RFC1035 says that RNAME represents a mailbox.

Section 8 defines the syntax to be RFC822 and specifies the encoding of a
mail address _inside_ the domain name system.

As the transformation is defined in RFC1035 and Net::DNS attempts to
implement RFC1035, the mailbox encoding process should occur somewhere
inside Net::DNS and not be left for the user to do.

Your program is _outside_ the domain name system, so the mailbox
representation provided by soa->rname() is defined by RFC822.


  It's not clear when this changed -- somewhere between 0.66 and 0.82, but
> I can't find any documentation or notes in the change history to that
> effect.
>

This change occurred in 0.69 as part of the changes needed to support
non-ASCII domain names.  The logical inconsistency of the pre-0.69
behaviour was exposed during that development.

The introduction of Net::DNS::Mailbox was noted in the change log for 0.68.
You are correct that the subsequent change in behaviour of soa->rname() was
not mentioned.  This was an oversight for which I apologise.



> What's the recommended method to get at the domain form now without
> digging around in the object?  Just feed the rname back through
> Net::DNS::Mailbox for the string value?
>

The only thing you can do with a RFC822 mail address is to address mail.

There is absolutely nothing useful you can do with the wire-format domain
name representation.

The question therefore does not arise in the real world, or if it does, it
is out of scope for Net::DNS.

All of this was discussed at length on this list in 2012/2013


Dick Franks
___________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150519/15dc1b09/attachment.htm>

From calle.dybedahl at init.se  Tue May 19 07:20:49 2015
From: calle.dybedahl at init.se (Calle Dybedahl)
Date: Tue, 19 May 2015 09:20:49 +0200
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
Message-ID: <58A4002F-3E15-44FD-9A1E-887969233180@init.se>


> On 18 maj 2015, at 18:28, Rob Foehl <rwf at loonybin.net> wrote:
> 
> What's the recommended method to get at the domain form now without digging around in the object?  Just feed the rname back through
> Net::DNS::Mailbox for the string value?


As you have probably seen already from Mr Franks? response, you?re not meant to do that. If you?re doing something where you want to see the details of what came over the wire, Net::LDNS may be a better choice (it?s on CPAN). We wrote it for the Zonemaster project (a DNS diagnostic tool, jointly developed by the Swedish and French ccTLD registries), since it had become clear that the direction Net::DNS was moving in was not well aligned with our needs.

? 
Calle Dybedahl
calle.dybedahl at init.se




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

From willem at nlnetlabs.nl  Tue May 19 08:38:49 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 19 May 2015 10:38:49 +0200
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <58A4002F-3E15-44FD-9A1E-887969233180@init.se>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <58A4002F-3E15-44FD-9A1E-887969233180@init.se>
Message-ID: <555AF699.4050409@nlnetlabs.nl>

It is a little bit more nuanced than that.

Net::DNS never gave access to the raw wire format data.  It has always
returned parsed representations of the actual values.  Though, before,
with the SOA rname it returned dname presentation format.

That we have changed this to RFC822 format is unfortunate because it
broke behaviour of existing API.  At the time I deemed it a minor issue
and safe because the returned value was an parsed and formatted one
anyway.  It is very clear to me now that this has been a mistake and we
have taken utmost care to not break existing API this way since.  And we
will make sure to never break this way again or at least communicate
very clear and loudly about it on this list beforehand.

Having that said, ldns also gives a parsed representation of the wire
format packet, though it's internal storage format is much closer to the
original wire format data than with Net::DNS.  Our new stub resolver
library getdns *does* provide access to the raw wire format data
alongside the parsed values.  Perl bindings for it are on their way.

If you really need the dname presentation format of the email address,
you could convert to it with the Net::DNS::Mailbox class:

$mb = new Net::DNS::Mailbox('John.Doe at example.com')
print $mb->name

# John\.Doe.example.com

-- Willem


Op 19-05-15 om 09:20 schreef Calle Dybedahl:
> 
>> On 18 maj 2015, at 18:28, Rob Foehl <rwf at loonybin.net
>> <mailto:rwf at loonybin.net>> wrote:
>>
>> What's the recommended method to get at the domain form now without
>> digging around in the object?  Just feed the rname back through
>> Net::DNS::Mailbox for the string value?
> 
> As you have probably seen already from Mr Franks? response, you?re not
> meant to do that. If you?re doing something where you want to see the
> details of what came over the wire, Net::LDNS may be a better choice
> (it?s on CPAN). We wrote it for the Zonemaster project (a DNS diagnostic
> tool, jointly developed by the Swedish and French ccTLD registries),
> since it had become clear that the direction Net::DNS was moving in was
> not well aligned with our needs.
> 
> ? 
> Calle Dybedahl
> calle.dybedahl at init.se <mailto:calle.dybedahl at init.se>
> 
> 
> 
> 
> 
> 
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users
> 



From dougb at dougbarton.us  Tue May 19 08:38:22 2015
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 19 May 2015 01:38:22 -0700
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
Message-ID: <555AF67E.3010908@dougbarton.us>

On 5/18/15 5:30 PM, Dick Franks wrote:
> All of this was discussed at length on this list in 2012/2013

Yes, and some of us told you at the time that while your reasoning was 
air tight, and self-consistent; the resulting change did not meet our 
needs.

For example, the obvious, glaring exception to your statement that 
"There is absolutely nothing useful you can do with the wire-format 
domain name representation" is that you can, and often need to, stuff it 
into a data store that will be used by something other than Net::DNS to 
generate zone files down the road.

So while it makes perfect sense to have a way to generate 822 format 
from Net::DNS, and it might even make sense to have that be the default, 
it ALSO makes sense to have a way to get the wire format without having 
to jump through insane hoops to do so.

... and just to save you time, no, it does not make sense for Net::DNS 
to decode the wire format, then have the other system re-encode it.

Doug

-- 
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150519/4b33e11e/attachment.bin>

From dougb at dougbarton.us  Tue May 19 08:41:11 2015
From: dougb at dougbarton.us (Doug Barton)
Date: Tue, 19 May 2015 01:41:11 -0700
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <555AF67E.3010908@dougbarton.us>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
Message-ID: <555AF727.3070707@dougbarton.us>

Sorry, as Willem pointed out when I said "wire format" I meant "DNAME 
format." Tired, must sleep now.

Doug

-- 
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150519/4d8c7eb9/attachment.bin>

From willem at nlnetlabs.nl  Tue May 19 08:51:14 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 19 May 2015 10:51:14 +0200
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <555AF699.4050409@nlnetlabs.nl>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <58A4002F-3E15-44FD-9A1E-887969233180@init.se>
 <555AF699.4050409@nlnetlabs.nl>
Message-ID: <555AF982.3040502@nlnetlabs.nl>

Op 19-05-15 om 10:38 schreef Willem Toorop:
> And we
> will make sure to never break this way again or at least communicate
> very clear and loudly about it on this list beforehand.

I forgot to add that we will listen and act on objections from the list
too!  The list was created for this kind of feedback.

-- Willem



From paf at frobbit.se  Wed May 20 06:09:24 2015
From: paf at frobbit.se (Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=)
Date: Wed, 20 May 2015 08:09:24 +0200
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <555AF67E.3010908@dougbarton.us>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
Message-ID: <A66321A8-1803-4BBA-95D8-F45C0AE52E65@frobbit.se>

On 19 May 2015, at 10:38, Doug Barton wrote:

> So while it makes perfect sense to have a way to generate 822 format from Net::DNS, and it might even make sense to have that be the default, it ALSO makes sense to have a way to get the wire format without having to jump through insane hoops to do so.
>
> ... and just to save you time, no, it does not make sense for Net::DNS to decode the wire format, then have the other system re-encode it.

I thought the conclusion was that the mapping between wire format and 822 format should be a separate function one can call if one want that. The recommendation was that the API itself would always be backward compatible.

One just do not change an API that way.

   paf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150520/03396670/attachment.bin>

From rwfranks at acm.org  Thu May 21 18:48:11 2015
From: rwfranks at acm.org (Dick Franks)
Date: Thu, 21 May 2015 19:48:11 +0100
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <555AF67E.3010908@dougbarton.us>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
Message-ID: <CAKW6Ri4hmkuHSmCE58aDXAVsDaU8-qeAODHCdUHgiCTAgVtcRg@mail.gmail.com>

On 19 May 2015 at 09:38, Doug Barton <dougb at dougbarton.us> wrote:

> On 5/18/15 5:30 PM, Dick Franks wrote:
>
>> All of this was discussed at length on this list in 2012/2013
>>
>
> Yes, and some of us told you at the time that while your reasoning was air
> tight, and self-consistent; the resulting change did not meet our needs.
>

The air tight and self-consistent reasoning was founded on a careful
analysis of RFC1035. The present implementation of Net::DNS got where it
got by following that reasoning.  Analysis and air tight reasoning are
investments with a long-term yield in the form of design stability.

The pre-0.69 implementation was not based on a sound analysis of RFC1035,
which is regrettable but these things happen.  This is the only flaw in
Michael Fuhr's original vision.


For example, the obvious, glaring exception to your statement that "There
> is absolutely nothing useful you can do with the wire-format domain name
> representation" is that you can, and often need to, stuff it into a data
> store that will be used by something other than Net::DNS to generate zone
> files down the road.
>

It is certainly arguable that RFC1035 was wrong in not using RFC822 for the
SOA RNAME field in zone file format. This is a mistake we all have to live
with.  The need to jump through hoops to convert mail addresses into domain
names is a direct consequence of that mistake. The need to do so arises
from *your* design decision about what to stuff in *your* data store.


So while it makes perfect sense to have a way to generate 822 format from
> Net::DNS, and it might even make sense to have that be the default,


RFC822 format is the primary representation of entities that claim to be a
mail address.  The wire-format and domain name representations are
encodings of that primary representation.


it ALSO makes sense to have a way to get the wire format without having to
> jump through insane hoops to do so.
> ... and just to save you time, no, it does not make sense for Net::DNS to
> decode the wire format, then have the other system re-encode it.


We will have to agree to differ about what does, or does not, make sense.

The conversion can be done in a single line.  The computational cost is
insignificant compared with the cost of resolving the SOA record.

use Net::DNS::Mailbox;

my $email = 'John.Doe at example.com';

my $name = new Net::DNS::Mailbox($email)->string;  # zone file format


The attractions of doing things this way are:
1) The conversion will forever remain in sync with current understanding of
RFC1035 and RFC822 et seq.
2) If you discover any example which violates the RFCs, I agree to let you
kick me until it is fixed.
3) The conversion accepts both RFC822 and the domain name encoded format,
so there is no need to check which you have.


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

From clists at buxtonfamily.us  Mon May 25 18:33:17 2015
From: clists at buxtonfamily.us (Chris Buxton)
Date: Mon, 25 May 2015 11:33:17 -0700
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <CAKW6Ri4hmkuHSmCE58aDXAVsDaU8-qeAODHCdUHgiCTAgVtcRg@mail.gmail.com>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
 <CAKW6Ri4hmkuHSmCE58aDXAVsDaU8-qeAODHCdUHgiCTAgVtcRg@mail.gmail.com>
Message-ID: <0AF03A2C-4ADF-4AD1-A801-8BC92D89C23A@buxtonfamily.us>

Dick,

Let me pose this question: This field of the SOA record is informational, and often (in the real world) doesn't lead to an actual functioning email address. When dealing with DNS records, how often does a script actually need this value in email address format? Compare that with the frequency of needing this in DNS domain name format, the way it is represented in DNS messages. I believe you will find that the latter need is far more prevalent than the former.

Now consider that you are doing extra work to decode this value, which is basically never needed, and then asking the script writer to do extra work to convert it back again. As you said, it's an inconsequential amount of work in terms of execution time (though not inconsequential in terms of coding time), but given how infrequently anyone actually cares about the semantic meaning of this field, vs. simply wanting to accurately record the fields of an SOA record, it seems counterintuitive that the module would behave this way.

And of course, there is the matter that it used to behave differently. My scripts broke in the 0.69 update. That bothered me. I rewrote them to stop using the (IMO broken) new behavior, and now use the SOA object's string method followed by 'split' to obtain the fields in DNS format.

I don't understand why this matters to you so much. There's an easy conversion routine, so rather than break the API, it would have been better to simply advertise that you have a handy conversion routine available for those who want to work with the data in email address format. At this point, obviously, you risk breaking scripts either way, because you've allowed the situation to remain for so long, but I think it's pretty clear the change in 0.69 was a mistake.

That's my opinion. I'll get off my soapbox now.

Regards,
Chris Buxton

> On May 21, 2015, at 11:48 AM, Dick Franks <rwfranks at acm.org> wrote:
> 
> 
> On 19 May 2015 at 09:38, Doug Barton <dougb at dougbarton.us <mailto:dougb at dougbarton.us>> wrote:
> On 5/18/15 5:30 PM, Dick Franks wrote:
> All of this was discussed at length on this list in 2012/2013
> 
> Yes, and some of us told you at the time that while your reasoning was air tight, and self-consistent; the resulting change did not meet our needs.
> 
> The air tight and self-consistent reasoning was founded on a careful analysis of RFC1035. The present implementation of Net::DNS got where it got by following that reasoning.  Analysis and air tight reasoning are investments with a long-term yield in the form of design stability.
> 
> The pre-0.69 implementation was not based on a sound analysis of RFC1035, which is regrettable but these things happen.  This is the only flaw in Michael Fuhr's original vision.
> 
> 
> For example, the obvious, glaring exception to your statement that "There is absolutely nothing useful you can do with the wire-format domain name representation" is that you can, and often need to, stuff it into a data store that will be used by something other than Net::DNS to generate zone files down the road.
> 
> It is certainly arguable that RFC1035 was wrong in not using RFC822 for the SOA RNAME field in zone file format. This is a mistake we all have to live with.  The need to jump through hoops to convert mail addresses into domain names is a direct consequence of that mistake. The need to do so arises from *your* design decision about what to stuff in *your* data store.
> 
> 
> So while it makes perfect sense to have a way to generate 822 format from Net::DNS, and it might even make sense to have that be the default,
> 
> RFC822 format is the primary representation of entities that claim to be a mail address.  The wire-format and domain name representations are encodings of that primary representation.
> 
> 
> it ALSO makes sense to have a way to get the wire format without having to jump through insane hoops to do so.
> ... and just to save you time, no, it does not make sense for Net::DNS to decode the wire format, then have the other system re-encode it.
> 
> We will have to agree to differ about what does, or does not, make sense.
> 
> The conversion can be done in a single line.  The computational cost is insignificant compared with the cost of resolving the SOA record.
> 
> use Net::DNS::Mailbox;
> 
> my $email = 'John.Doe at example.com <mailto:John.Doe at example.com>';
> 
> my $name = new Net::DNS::Mailbox($email)->string;  # zone file format
> 
> 
> The attractions of doing things this way are:
> 1) The conversion will forever remain in sync with current understanding of RFC1035 and RFC822 et seq.
> 2) If you discover any example which violates the RFCs, I agree to let you kick me until it is fixed.
> 3) The conversion accepts both RFC822 and the domain name encoded format, so there is no need to check which you have.
> 
> 
> -- Dick
> 
> _______________________________________________
> 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/20150525/4a674bc4/attachment.htm>

From dougb at dougbarton.us  Mon May 25 19:25:41 2015
From: dougb at dougbarton.us (Doug Barton)
Date: Mon, 25 May 2015 12:25:41 -0700
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <0AF03A2C-4ADF-4AD1-A801-8BC92D89C23A@buxtonfamily.us>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
 <CAKW6Ri4hmkuHSmCE58aDXAVsDaU8-qeAODHCdUHgiCTAgVtcRg@mail.gmail.com>
 <0AF03A2C-4ADF-4AD1-A801-8BC92D89C23A@buxtonfamily.us>
Message-ID: <55637735.9000803@dougbarton.us>

On 5/25/15 11:33 AM, Chris Buxton wrote:
> I don't understand why this matters to you so much. There's an easy
> conversion routine, so rather than break the API, it would have been
> better to simply advertise that you have a handy conversion routine
> available for those who want to work with the data in email address
> format. At this point, obviously, you risk breaking scripts either way,
> because you've allowed the situation to remain for so long, but I think
> it's pretty clear the change in 0.69 was a mistake.

This sums it up for me as well.

-- 
I am conducting an experiment in the efficacy of PGP/MIME signatures. 
This message should be signed. If it is not, or the signature does not 
validate, please let me know how you received this message (direct, or 
to a list) and the mail software you use. Thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150525/399d5250/attachment.bin>

From paf at frobbit.se  Mon May 25 21:38:44 2015
From: paf at frobbit.se (Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=)
Date: Mon, 25 May 2015 17:38:44 -0400
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <55637735.9000803@dougbarton.us>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
 <CAKW6Ri4hmkuHSmCE58aDXAVsDaU8-qeAODHCdUHgiCTAgVtcRg@mail.gmail.com>
 <0AF03A2C-4ADF-4AD1-A801-8BC92D89C23A@buxtonfamily.us>
 <55637735.9000803@dougbarton.us>
Message-ID: <27A1D50C-56E9-497D-88DD-44229BA44C79@frobbit.se>

On 25 May 2015, at 15:25, Doug Barton wrote:

> On 5/25/15 11:33 AM, Chris Buxton wrote:
>
>> I don't understand why this matters to you so much. There's an easy
>> conversion routine, so rather than break the API, it would have been
>> better to simply advertise that you have a handy conversion routine
>> available for those who want to work with the data in email address
>> format. At this point, obviously, you risk breaking scripts either way,
>> because you've allowed the situation to remain for so long, but I think
>> it's pretty clear the change in 0.69 was a mistake.
>
> This sums it up for me as well.

+1

   paf
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150525/bebc4ab7/attachment.bin>

From einar.lonn at iis.se  Tue May 26 09:15:31 2015
From: einar.lonn at iis.se (=?Windows-1252?Q?Einar_L=F6nn?=)
Date: Tue, 26 May 2015 11:15:31 +0200
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <0AF03A2C-4ADF-4AD1-A801-8BC92D89C23A@buxtonfamily.us>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
 <CAKW6Ri4hmkuHSmCE58aDXAVsDaU8-qeAODHCdUHgiCTAgVtcRg@mail.gmail.com>
 <0AF03A2C-4ADF-4AD1-A801-8BC92D89C23A@buxtonfamily.us>
Message-ID: <59C4199E-3919-42F0-963B-3E58596B0208@iis.se>

Also considering that basically every single user on this list wants a tool that can be used to debug DNS and not a fancy tool that does all the work for you I?m a bit sad that you let pride guide the project instead of actual user needs and requests. I dont think anyone, not one single user, has requested or wanted this change and when we (the users) try and tell you so you basically tell us how wrong we are. 

It?s tiresome to have Net::DNS version ranges in our code and it?s even more tiresome when the maintainer(s) try and justify these changes. We created Net::LDNS for our new projects as we didnt like this user-unfriendly approach.

	/Regards, Einar

On 25 May 2015, at 20:33, Chris Buxton <clists at buxtonfamily.us> wrote:

> Dick,
> 
> Let me pose this question: This field of the SOA record is informational, and often (in the real world) doesn't lead to an actual functioning email address. When dealing with DNS records, how often does a script actually need this value in email address format? Compare that with the frequency of needing this in DNS domain name format, the way it is represented in DNS messages. I believe you will find that the latter need is far more prevalent than the former.
> 
> Now consider that you are doing extra work to decode this value, which is basically never needed, and then asking the script writer to do extra work to convert it back again. As you said, it's an inconsequential amount of work in terms of execution time (though not inconsequential in terms of coding time), but given how infrequently anyone actually cares about the semantic meaning of this field, vs. simply wanting to accurately record the fields of an SOA record, it seems counterintuitive that the module would behave this way.
> 
> And of course, there is the matter that it used to behave differently. My scripts broke in the 0.69 update. That bothered me. I rewrote them to stop using the (IMO broken) new behavior, and now use the SOA object's string method followed by 'split' to obtain the fields in DNS format.
> 
> I don't understand why this matters to you so much. There's an easy conversion routine, so rather than break the API, it would have been better to simply advertise that you have a handy conversion routine available for those who want to work with the data in email address format. At this point, obviously, you risk breaking scripts either way, because you've allowed the situation to remain for so long, but I think it's pretty clear the change in 0.69 was a mistake.
> 
> That's my opinion. I'll get off my soapbox now.
> 
> Regards,
> Chris Buxton
> 
>> On May 21, 2015, at 11:48 AM, Dick Franks <rwfranks at acm.org> wrote:
>> 
>> 
>> On 19 May 2015 at 09:38, Doug Barton <dougb at dougbarton.us> wrote:
>> On 5/18/15 5:30 PM, Dick Franks wrote:
>> All of this was discussed at length on this list in 2012/2013
>> 
>> Yes, and some of us told you at the time that while your reasoning was air tight, and self-consistent; the resulting change did not meet our needs.
>> 
>> The air tight and self-consistent reasoning was founded on a careful analysis of RFC1035. The present implementation of Net::DNS got where it got by following that reasoning.  Analysis and air tight reasoning are investments with a long-term yield in the form of design stability.
>> 
>> The pre-0.69 implementation was not based on a sound analysis of RFC1035, which is regrettable but these things happen.  This is the only flaw in Michael Fuhr's original vision.
>> 
>> 
>> For example, the obvious, glaring exception to your statement that "There is absolutely nothing useful you can do with the wire-format domain name representation" is that you can, and often need to, stuff it into a data store that will be used by something other than Net::DNS to generate zone files down the road.
>> 
>> It is certainly arguable that RFC1035 was wrong in not using RFC822 for the SOA RNAME field in zone file format. This is a mistake we all have to live with.  The need to jump through hoops to convert mail addresses into domain names is a direct consequence of that mistake. The need to do so arises from *your* design decision about what to stuff in *your* data store.
>> 
>> 
>> So while it makes perfect sense to have a way to generate 822 format from Net::DNS, and it might even make sense to have that be the default,
>> 
>> RFC822 format is the primary representation of entities that claim to be a mail address.  The wire-format and domain name representations are encodings of that primary representation.
>> 
>> 
>> it ALSO makes sense to have a way to get the wire format without having to jump through insane hoops to do so.
>> ... and just to save you time, no, it does not make sense for Net::DNS to decode the wire format, then have the other system re-encode it.
>> 
>> We will have to agree to differ about what does, or does not, make sense.
>> 
>> The conversion can be done in a single line.  The computational cost is insignificant compared with the cost of resolving the SOA record.
>> 
>> use Net::DNS::Mailbox;
>> 
>> my $email = 'John.Doe at example.com';
>> 
>> my $name = new Net::DNS::Mailbox($email)->string;  # zone file format
>> 
>> 
>> The attractions of doing things this way are:
>> 1) The conversion will forever remain in sync with current understanding of RFC1035 and RFC822 et seq.
>> 2) If you discover any example which violates the RFCs, I agree to let you kick me until it is fixed.
>> 3) The conversion accepts both RFC822 and the domain name encoded format, so there is no need to check which you have.
>> 
>> 
>> -- Dick
>> 
>> _______________________________________________
>> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150526/2e296a4e/attachment.bin>

From willem at nlnetlabs.nl  Tue May 26 10:34:14 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 26 May 2015 12:34:14 +0200
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <59C4199E-3919-42F0-963B-3E58596B0208@iis.se>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
 <CAKW6Ri4hmkuHSmCE58aDXAVsDaU8-qeAODHCdUHgiCTAgVtcRg@mail.gmail.com>
 <0AF03A2C-4ADF-4AD1-A801-8BC92D89C23A@buxtonfamily.us>
 <59C4199E-3919-42F0-963B-3E58596B0208@iis.se>
Message-ID: <55644C26.1040206@nlnetlabs.nl>

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

Please!

We *are* listening to this list!  We will always post a release
candidate before doing an actual release to this list for review.

Before we also did release candidates, only not via the list, but via
developers releases on CPAN and via the website.  This did (obviously)
not give us the desired feedback, so I have tried to inventory all
developers of packages using Net::DNS and invited them personally to
this list to improve on this situation.  Another step we have done to
improve is that we release far more often and with smaller changes
then before.

Net::DNS might never have given the lower level controls you needed
for zonemaster.  Before it might have given the (wrong) impression
that it did though.  For example with the writeable section counters
in the header that were silently ignored.

ldns also has an intermediate (interpreted) host format b.t.w., though
its rdata field structures are closer to the wire-format data than
those of Net::DNS yes.  If you really want more finer-grained control
to lower-level DNS, at the wire format, but also at the network and
I/O level, you might give getdns a go; though perl bindings are still
in the make.

Debugging DNS is not the only use case for Net::DNS.  There are also
many application that use Net::DNS not to debug DNS, but to get to
specific records and to do DNSSEC validation at the application level.

The SOA->rname change has been a mistake because it broke previous
behaviour.  At the time I deemed it a minor issue and safe because the
returned value was an parsed and formatted one anyway; and it did not
affect the reading and writing of presentation format.  We will make
sure to never break this way again or at least communicate very clear
and loudly about it on this list beforehand.   We will listen and act
on objections from the list.  The list was created for this very purpose.

- -- Willem

Op 26-05-15 om 11:15 schreef Einar L?nn:
> Also considering that basically every single user on this list
> wants a tool that can be used to debug DNS and not a fancy tool
> that does all the work for you I?m a bit sad that you let pride
> guide the project instead of actual user needs and requests. I dont
> think anyone, not one single user, has requested or wanted this
> change and when we (the users) try and tell you so you basically
> tell us how wrong we are.
> 
> It?s tiresome to have Net::DNS version ranges in our code and it?s
> even more tiresome when the maintainer(s) try and justify these
> changes. We created Net::LDNS for our new projects as we didnt like
> this user-unfriendly approach.
> 
> /Regards, Einar
> 
> On 25 May 2015, at 20:33, Chris Buxton <clists at buxtonfamily.us>
> wrote:
> 
>> Dick,
>> 
>> Let me pose this question: This field of the SOA record is
>> informational, and often (in the real world) doesn't lead to an
>> actual functioning email address. When dealing with DNS records,
>> how often does a script actually need this value in email address
>> format? Compare that with the frequency of needing this in DNS
>> domain name format, the way it is represented in DNS messages. I
>> believe you will find that the latter need is far more prevalent
>> than the former.
>> 
>> Now consider that you are doing extra work to decode this value,
>> which is basically never needed, and then asking the script
>> writer to do extra work to convert it back again. As you said,
>> it's an inconsequential amount of work in terms of execution time
>> (though not inconsequential in terms of coding time), but given
>> how infrequently anyone actually cares about the semantic meaning
>> of this field, vs. simply wanting to accurately record the fields
>> of an SOA record, it seems counterintuitive that the module would
>> behave this way.
>> 
>> And of course, there is the matter that it used to behave
>> differently. My scripts broke in the 0.69 update. That bothered
>> me. I rewrote them to stop using the (IMO broken) new behavior,
>> and now use the SOA object's string method followed by 'split' to
>> obtain the fields in DNS format.
>> 
>> I don't understand why this matters to you so much. There's an
>> easy conversion routine, so rather than break the API, it would
>> have been better to simply advertise that you have a handy
>> conversion routine available for those who want to work with the
>> data in email address format. At this point, obviously, you risk
>> breaking scripts either way, because you've allowed the situation
>> to remain for so long, but I think it's pretty clear the change
>> in 0.69 was a mistake.
>> 
>> That's my opinion. I'll get off my soapbox now.
>> 
>> Regards, Chris Buxton
>> 
>>> On May 21, 2015, at 11:48 AM, Dick Franks <rwfranks at acm.org>
>>> wrote:
>>> 
>>> 
>>> On 19 May 2015 at 09:38, Doug Barton <dougb at dougbarton.us>
>>> wrote: On 5/18/15 5:30 PM, Dick Franks wrote: All of this was
>>> discussed at length on this list in 2012/2013
>>> 
>>> Yes, and some of us told you at the time that while your
>>> reasoning was air tight, and self-consistent; the resulting
>>> change did not meet our needs.
>>> 
>>> The air tight and self-consistent reasoning was founded on a
>>> careful analysis of RFC1035. The present implementation of
>>> Net::DNS got where it got by following that reasoning.
>>> Analysis and air tight reasoning are investments with a
>>> long-term yield in the form of design stability.
>>> 
>>> The pre-0.69 implementation was not based on a sound analysis
>>> of RFC1035, which is regrettable but these things happen.  This
>>> is the only flaw in Michael Fuhr's original vision.
>>> 
>>> 
>>> For example, the obvious, glaring exception to your statement
>>> that "There is absolutely nothing useful you can do with the
>>> wire-format domain name representation" is that you can, and
>>> often need to, stuff it into a data store that will be used by
>>> something other than Net::DNS to generate zone files down the
>>> road.
>>> 
>>> It is certainly arguable that RFC1035 was wrong in not using
>>> RFC822 for the SOA RNAME field in zone file format. This is a
>>> mistake we all have to live with.  The need to jump through
>>> hoops to convert mail addresses into domain names is a direct
>>> consequence of that mistake. The need to do so arises from
>>> *your* design decision about what to stuff in *your* data
>>> store.
>>> 
>>> 
>>> So while it makes perfect sense to have a way to generate 822
>>> format from Net::DNS, and it might even make sense to have that
>>> be the default,
>>> 
>>> RFC822 format is the primary representation of entities that
>>> claim to be a mail address.  The wire-format and domain name
>>> representations are encodings of that primary representation.
>>> 
>>> 
>>> it ALSO makes sense to have a way to get the wire format
>>> without having to jump through insane hoops to do so. ... and
>>> just to save you time, no, it does not make sense for Net::DNS
>>> to decode the wire format, then have the other system re-encode
>>> it.
>>> 
>>> We will have to agree to differ about what does, or does not,
>>> make sense.
>>> 
>>> The conversion can be done in a single line.  The computational
>>> cost is insignificant compared with the cost of resolving the
>>> SOA record.
>>> 
>>> use Net::DNS::Mailbox;
>>> 
>>> my $email = 'John.Doe at example.com';
>>> 
>>> my $name = new Net::DNS::Mailbox($email)->string;  # zone file
>>> format
>>> 
>>> 
>>> The attractions of doing things this way are: 1) The conversion
>>> will forever remain in sync with current understanding of
>>> RFC1035 and RFC822 et seq. 2) If you discover any example which
>>> violates the RFCs, I agree to let you kick me until it is
>>> fixed. 3) The conversion accepts both RFC822 and the domain
>>> name encoded format, so there is no need to check which you
>>> have.
>>> 
>>> 
>>> -- Dick
>>> 
>>> _______________________________________________ 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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVZEwmAAoJEOX4+CEvd6SYNcMP/2OLefhJNybJW/BKBjTDJERK
nKVBqWJEFExXagJwBF6gMiA88wqXunU9DiNFEzV/4V0F5jOUmh1xpo90KQ5n9rYI
jU2LpGrk100+2dRbzOUB99L0M+1zrOeJ9u0aKi51HWq152eP0OJfcOD/4PHbjLud
cPqLZaNy276U37Ra0HK8+iSOI86wvqimlifpM6qoQUFTHO0JjSCbC1lpjlTv+9AL
gdPojsflu4p+/SjTfjtBOhTu524ZIX7SnqL3+Ww3LjeiE5paQR6zs6YzoicxpBib
+U3DnGMzRrdkbpzMe5MHW5RFJBmdYCoQE/1Gl/TevT/nh8+xOrx6yJfaLKqU9oxT
dJGtmQUEWUQ/5swiOQolWYN44QGtEmtM0lZWVigO7q4h/W9i84I49DuehBJP9wlc
LYRkPBgQ6y+75K38p7p0leEnQ++JQHtKDFwBf1GpkYsz1eNanZ4xbvqJZfW8j1BD
wiRJCxB1ziPWMOpPL/TiT7nFSogyBxT+BgD0SRYSjvtS4gqSYFIKga5eiO1+BbTa
S0jQGqB/DZBFP5X1XCaq4BxwghZNl6GLJZqYjYWiaqZk5arL5JzOZltiN/GOemCd
obuenNsrryspHczw5Q7CmlfL0Cs95kOZK7iSvQ2gKWGNvlvdba03iFdC5O2xhHAb
S7vQWR+49VnSxfAdAmbW
=b14L
-----END PGP SIGNATURE-----


From tlhackque at yahoo.com  Tue May 26 10:35:46 2015
From: tlhackque at yahoo.com (tlhackque)
Date: Tue, 26 May 2015 06:35:46 -0400
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <59C4199E-3919-42F0-963B-3E58596B0208@iis.se>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
 <CAKW6Ri4hmkuHSmCE58aDXAVsDaU8-qeAODHCdUHgiCTAgVtcRg@mail.gmail.com>
 <0AF03A2C-4ADF-4AD1-A801-8BC92D89C23A@buxtonfamily.us>
 <59C4199E-3919-42F0-963B-3E58596B0208@iis.se>
Message-ID: <55644C82.7080105@yahoo.com>

On 26-May-15 05:15, Einar L?nn wrote:
> Also considering that basically every single user on this list wants a tool that can be used to debug DNS and not a fancy tool that does all the work for you I?m a bit sad that you let pride guide the project instead of actual user needs and requests. I dont think anyone, not one single user, has requested or wanted this change and when we (the users) try and tell you so you basically tell us how wrong we are. 
>
> It?s tiresome to have Net::DNS version ranges in our code and it?s even more tiresome when the maintainer(s) try and justify these changes. We created Net::LDNS for our new projects as we didnt like this user-unfriendly approach.
>
> 	/Regards, Einar
>
> O
I agree that the change for SOA email address was a mistake and should
have been handled better.   At this point, perhaps the only solution
that could satisfy both camps is a switch that can be set to get one
behavior or the other.  (E.g. $Net::DNS::RFC822_WireFormat = 1)

However, for the record, I use Net::DNS as the basis for web-based
management tools: to read and display zone data, to add/change/remove
records via UPDATE, and some odd script-based jobs that check health
and/or do 1-off transformations.  It's cheaper and more flexible than
forking processes to run dig and nsupdate.  Debugging DNS happens, but
is not my primary use.

I suspect that people are active on this list when their needs aren't
met.  And since debugging DNS always needs "just one more thing", the
list traffic disproportionately represents debuggers over customers of
the high-level APIs. 

This controversy  aside, we should remember that Dick and the other
contributors have put a lot of work into producing a functional library,
and do so as volunteers.  The frustration over this and other issues
should not obscure that.

I'm all for having the APIs that enable debugging.  They're handy, and
they form the basis for the test suites of important DNS software.

But count one user who uses the high-level APIs and does not count
debugging DNS as the primary use case. 

-- 
This communication may not represent my employer's views,
if any, on the matters discussed. 



From einar.lonn at iis.se  Tue May 26 10:52:49 2015
From: einar.lonn at iis.se (=?Windows-1252?Q?Einar_L=F6nn?=)
Date: Tue, 26 May 2015 12:52:49 +0200
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <55644C26.1040206@nlnetlabs.nl>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
 <CAKW6Ri4hmkuHSmCE58aDXAVsDaU8-qeAODHCdUHgiCTAgVtcRg@mail.gmail.com>
 <0AF03A2C-4ADF-4AD1-A801-8BC92D89C23A@buxtonfamily.us>
 <59C4199E-3919-42F0-963B-3E58596B0208@iis.se> <55644C26.1040206@nlnetlabs.nl>
Message-ID: <09DB70F3-2617-4F4C-AF15-C7E790598485@iis.se>

On 26 May 2015, at 12:34, Willem Toorop <willem at nlnetlabs.nl> wrote:

> Signed PGP part
> Please!
> 
> We *are* listening to this list!  We will always post a release
> candidate before doing an actual release to this list for review.
> 
> Before we also did release candidates, only not via the list, but via
> developers releases on CPAN and via the website.  This did (obviously)
> not give us the desired feedback, so I have tried to inventory all
> developers of packages using Net::DNS and invited them personally to
> this list to improve on this situation.  Another step we have done to
> improve is that we release far more often and with smaller changes
> then before.
> 
> Net::DNS might never have given the lower level controls you needed
> for zonemaster.  Before it might have given the (wrong) impression
> that it did though.  For example with the writeable section counters
> in the header that were silently ignored.
> 
> ldns also has an intermediate (interpreted) host format b.t.w., though
> its rdata field structures are closer to the wire-format data than
> those of Net::DNS yes.  If you really want more finer-grained control
> to lower-level DNS, at the wire format, but also at the network and
> I/O level, you might give getdns a go; though perl bindings are still
> in the make.
> 
> Debugging DNS is not the only use case for Net::DNS.  There are also
> many application that use Net::DNS not to debug DNS, but to get to
> specific records and to do DNSSEC validation at the application level.
> 
> The SOA->rname change has been a mistake because it broke previous
> behaviour.  At the time I deemed it a minor issue and safe because the
> returned value was an parsed and formatted one anyway; and it did not
> affect the reading and writing of presentation format.  We will make
> sure to never break this way again or at least communicate very clear
> and loudly about it on this list beforehand.   We will listen and act
> on objections from the list.  The list was created for this very purpose.
> 
> ? Willem

Thank you Willem. 

Parts of what you mention above added to the problem as we got errors from different distributions along the way as they changed which version of Net::DNS they chose to package so maintenance was getting harder, when it comes to flags and release notes and what was done and what wasnt; it?s over my head really... But this last confirmation that you will listen to the list before changing the API again is very, very welcome. Thanks again and I do apologize if I was rude; I just felt a bit ignored, I think many of us did. ;P

	/Regards, Einar

> Op 26-05-15 om 11:15 schreef Einar L?nn:
> > Also considering that basically every single user on this list
> > wants a tool that can be used to debug DNS and not a fancy tool
> > that does all the work for you I?m a bit sad that you let pride
> > guide the project instead of actual user needs and requests. I dont
> > think anyone, not one single user, has requested or wanted this
> > change and when we (the users) try and tell you so you basically
> > tell us how wrong we are.
> >
> > It?s tiresome to have Net::DNS version ranges in our code and it?s
> > even more tiresome when the maintainer(s) try and justify these
> > changes. We created Net::LDNS for our new projects as we didnt like
> > this user-unfriendly approach.
> >
> > /Regards, Einar
> >
> > On 25 May 2015, at 20:33, Chris Buxton <clists at buxtonfamily.us>
> > wrote:
> >
> >> Dick,
> >>
> >> Let me pose this question: This field of the SOA record is
> >> informational, and often (in the real world) doesn't lead to an
> >> actual functioning email address. When dealing with DNS records,
> >> how often does a script actually need this value in email address
> >> format? Compare that with the frequency of needing this in DNS
> >> domain name format, the way it is represented in DNS messages. I
> >> believe you will find that the latter need is far more prevalent
> >> than the former.
> >>
> >> Now consider that you are doing extra work to decode this value,
> >> which is basically never needed, and then asking the script
> >> writer to do extra work to convert it back again. As you said,
> >> it's an inconsequential amount of work in terms of execution time
> >> (though not inconsequential in terms of coding time), but given
> >> how infrequently anyone actually cares about the semantic meaning
> >> of this field, vs. simply wanting to accurately record the fields
> >> of an SOA record, it seems counterintuitive that the module would
> >> behave this way.
> >>
> >> And of course, there is the matter that it used to behave
> >> differently. My scripts broke in the 0.69 update. That bothered
> >> me. I rewrote them to stop using the (IMO broken) new behavior,
> >> and now use the SOA object's string method followed by 'split' to
> >> obtain the fields in DNS format.
> >>
> >> I don't understand why this matters to you so much. There's an
> >> easy conversion routine, so rather than break the API, it would
> >> have been better to simply advertise that you have a handy
> >> conversion routine available for those who want to work with the
> >> data in email address format. At this point, obviously, you risk
> >> breaking scripts either way, because you've allowed the situation
> >> to remain for so long, but I think it's pretty clear the change
> >> in 0.69 was a mistake.
> >>
> >> That's my opinion. I'll get off my soapbox now.
> >>
> >> Regards, Chris Buxton
> >>
> >>> On May 21, 2015, at 11:48 AM, Dick Franks <rwfranks at acm.org>
> >>> wrote:
> >>>
> >>>
> >>> On 19 May 2015 at 09:38, Doug Barton <dougb at dougbarton.us>
> >>> wrote: On 5/18/15 5:30 PM, Dick Franks wrote: All of this was
> >>> discussed at length on this list in 2012/2013
> >>>
> >>> Yes, and some of us told you at the time that while your
> >>> reasoning was air tight, and self-consistent; the resulting
> >>> change did not meet our needs.
> >>>
> >>> The air tight and self-consistent reasoning was founded on a
> >>> careful analysis of RFC1035. The present implementation of
> >>> Net::DNS got where it got by following that reasoning.
> >>> Analysis and air tight reasoning are investments with a
> >>> long-term yield in the form of design stability.
> >>>
> >>> The pre-0.69 implementation was not based on a sound analysis
> >>> of RFC1035, which is regrettable but these things happen.  This
> >>> is the only flaw in Michael Fuhr's original vision.
> >>>
> >>>
> >>> For example, the obvious, glaring exception to your statement
> >>> that "There is absolutely nothing useful you can do with the
> >>> wire-format domain name representation" is that you can, and
> >>> often need to, stuff it into a data store that will be used by
> >>> something other than Net::DNS to generate zone files down the
> >>> road.
> >>>
> >>> It is certainly arguable that RFC1035 was wrong in not using
> >>> RFC822 for the SOA RNAME field in zone file format. This is a
> >>> mistake we all have to live with.  The need to jump through
> >>> hoops to convert mail addresses into domain names is a direct
> >>> consequence of that mistake. The need to do so arises from
> >>> *your* design decision about what to stuff in *your* data
> >>> store.
> >>>
> >>>
> >>> So while it makes perfect sense to have a way to generate 822
> >>> format from Net::DNS, and it might even make sense to have that
> >>> be the default,
> >>>
> >>> RFC822 format is the primary representation of entities that
> >>> claim to be a mail address.  The wire-format and domain name
> >>> representations are encodings of that primary representation.
> >>>
> >>>
> >>> it ALSO makes sense to have a way to get the wire format
> >>> without having to jump through insane hoops to do so. ... and
> >>> just to save you time, no, it does not make sense for Net::DNS
> >>> to decode the wire format, then have the other system re-encode
> >>> it.
> >>>
> >>> We will have to agree to differ about what does, or does not,
> >>> make sense.
> >>>
> >>> The conversion can be done in a single line.  The computational
> >>> cost is insignificant compared with the cost of resolving the
> >>> SOA record.
> >>>
> >>> use Net::DNS::Mailbox;
> >>>
> >>> my $email = 'John.Doe at example.com';
> >>>
> >>> my $name = new Net::DNS::Mailbox($email)->string;  # zone file
> >>> format
> >>>
> >>>
> >>> The attractions of doing things this way are: 1) The conversion
> >>> will forever remain in sync with current understanding of
> >>> RFC1035 and RFC822 et seq. 2) If you discover any example which
> >>> violates the RFCs, I agree to let you kick me until it is
> >>> fixed. 3) The conversion accepts both RFC822 and the domain
> >>> name encoded format, so there is no need to check which you
> >>> have.
> >>>
> >>>
> >>> -- Dick
> >>>
> >>> _______________________________________________ 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150526/51f6de8e/attachment.bin>

From rwfranks at acm.org  Wed May 27 20:28:28 2015
From: rwfranks at acm.org (Dick Franks)
Date: Wed, 27 May 2015 21:28:28 +0100
Subject: [net-dns-users] SOA rname as mailbox
In-Reply-To: <55644C82.7080105@yahoo.com>
References: <alpine.LFD.2.11.1505181159351.2812@bugs.loonybin.net>
 <CAKW6Ri5mE3mc791iXr8_VX1QCOwsTnvb+_NYV+0xjZ6AvdnA4w@mail.gmail.com>
 <555AF67E.3010908@dougbarton.us>
 <CAKW6Ri4hmkuHSmCE58aDXAVsDaU8-qeAODHCdUHgiCTAgVtcRg@mail.gmail.com>
 <0AF03A2C-4ADF-4AD1-A801-8BC92D89C23A@buxtonfamily.us>
 <59C4199E-3919-42F0-963B-3E58596B0208@iis.se>
 <55644C82.7080105@yahoo.com>
Message-ID: <CAKW6Ri7Kd_oNUY4Vqj13U0OCsxBJXHYpsHN7TWEu1zGV=1c1yw@mail.gmail.com>

On 26 May 2015 at 11:35, tlhackque <tlhackque at yahoo.com> wrote:

> On 26-May-15 05:15, Einar L?nn wrote:
>
[snip]


> > ... and it?s even more tiresome when the maintainer(s) try and justify
> these changes.


The justification is rooted in RFC1035.

[snip]

I agree that the change for SOA email address was a mistake and should
> have been handled better.   At this point, perhaps the only solution
> that could satisfy both camps is a switch that can be set to get one
> behavior or the other.  (E.g. $Net::DNS::RFC822_WireFormat = 1)
>

That would involve another change in API,  which would be about as welcome
as a fart in a spacesuit.

[snip]

I suspect that people are active on this list when their needs aren't
> met.  And since debugging DNS always needs "just one more thing", the
> list traffic disproportionately represents debuggers over customers of
> the high-level APIs.
>

Net::DNS is a "Perl interface to the Domain Name System".

It makes no claim to be a debugging engine, although there is plenty  of
debugging that can be done with it.

 This controversy  aside, we should remember that Dick and the other
> contributors have put a lot of work into producing a functional library,
> and do so as volunteers.  The frustration over this and other issues
> should not obscure that.
>

Thank you. Good to know I still have at least one friend!

I'm all for having the APIs that enable debugging.  They're handy, and
> they form the basis for the test suites of important DNS software.
>

We have been here before.  Olaf Kolkman posted a few years ago asking for
more specific proposals for a debugging API.  As far as I am aware, he
never received any meaningful response.

But count one user who uses the high-level APIs and does not count
> debugging DNS as the primary use case.
>

The overwhelming majority of users are in that category, never post on this
list, and have never filed a bug report.  The traffic here is in no way
representative of the user population at large.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150527/d37bf9f4/attachment.htm>

From robert at kuropkat.com  Fri Jun  5 02:32:55 2015
From: robert at kuropkat.com (Robert Kuropkat)
Date: Thu, 04 Jun 2015 22:32:55 -0400
Subject: [net-dns-users] Tracking intermediate packet status of queries
Message-ID: <55710A57.4010704@kuropkat.com>


All,

I'm new to Net::DNS and DNS as well so may well be missing something 
obvious.  I have some tests I want to do to validate results of RPZ 
configurations.  The problem is, the send() method seems to only return 
the status of the final packet of a query.  Unfortunately, the final 
status for several tests appear the same, so there is no way to validate 
the query in fact behaved as expected.  When I set the debug flag, I see 
the traffic I expect, but none of that data (except the last) is 
retained for programmatic analysis.

Example: Setting RPZ policy action to TCP-ONLY.  (sorry, doing this from 
memory...)

  * $resolver->send() (via UDP)
  * Initial query is truncated (tc=1), status, unknown error
  * query resent, forcing TCP connection
  * query returns answer correctly.  status NOERROR

I'd like to capture intermediate flag settings and resolver status to 
validate each step executed as expected.

A quick walk through the Net::DNS code shows it **may** be as simple as 
changing the $ans (return value) scaler to an array and saving each 
intermediate packet.  It's possible a flag could be set to default to 
current behaviour and return only the last packet to maintain backwards 
compatibility.  It seems internally, there are only two or three methods 
that would need to be modified as a result.  However, I'm not familiar 
enough with the framework to be sure that is all, or even be sure what I 
want is not really there already.

Help or suggestions much appreciated.  Requests for details will have to 
wait until I am back in the office tomorrow...

Robert Kuropkat

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

From dwessels at verisign.com  Fri Jun  5 15:02:18 2015
From: dwessels at verisign.com (Wessels, Duane)
Date: Fri, 5 Jun 2015 15:02:18 +0000
Subject: [net-dns-users] Tracking intermediate packet status of queries
In-Reply-To: <55710A57.4010704@kuropkat.com>
References: <55710A57.4010704@kuropkat.com>
Message-ID: <E1A72D45-7594-4E6A-8CA1-F9143CD6DD45@verisign.com>

Robert,

I would be surprised if you can get Net::DNS::Resolver to save and return all the raw messages.

Perhaps you can set Net::DNS::Resolver->igntc(1) and detect the TC bit yourself and then do your
own fallback to TCP?

DW


> On Jun 4, 2015, at 7:32 PM, Robert Kuropkat <robert at kuropkat.com> wrote:
> 
> 
> All,
> 
> I'm new to Net::DNS and DNS as well so may well be missing something obvious.  I have some tests I want to do to validate results of RPZ configurations.  The problem is, the send() method seems to only return the status of the final packet of a query.  Unfortunately, the final status for several tests appear the same, so there is no way to validate the query in fact behaved as expected.  When I set the debug flag, I see the traffic I expect, but none of that data (except the last) is retained for programmatic analysis.
> 
> Example: Setting RPZ policy action to TCP-ONLY.  (sorry, doing this from memory...)
> 	? $resolver->send() (via UDP)
> 	? Initial query is truncated (tc=1), status, unknown error
> 	? query resent, forcing TCP connection
> 	? query returns answer correctly.  status NOERROR
> I'd like to capture intermediate flag settings and resolver status to validate each step executed as expected.
> A quick walk through the Net::DNS code shows it **may** be as simple as changing the $ans (return value) scaler to an array and saving each intermediate packet.  It's possible a flag could be set to default to current behaviour and return only the last packet to maintain backwards compatibility.  It seems internally, there are only two or three methods that would need to be modified as a result.  However, I'm not familiar enough with the framework to be sure that is all, or even be sure what I want is not really there already.
> Help or suggestions much appreciated.  Requests for details will have to wait until I am back in the office tomorrow...
> Robert Kuropkat
> 
> _______________________________________________
> net-dns-users mailing list
> net-dns-users at nlnetlabs.nl
> https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4676 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150605/1f05c33e/attachment.bin>

From dwessels at verisign.com  Thu Jun 25 18:37:53 2015
From: dwessels at verisign.com (Wessels, Duane)
Date: Thu, 25 Jun 2015 18:37:53 +0000
Subject: [net-dns-users] Can't call method "zclass" on an undefined value at
 ... Net/DNS/Packet.pm line 474
Message-ID: <9786F862-EFC6-4429-A0A7-B602D96CFC41@verisign.com>

An issue was reported to the fpdns repository:

  https://github.com/kirei/fpdns/issues/8

I traced through the code, found what fpdns is doing and replicated it in the small program below.

  1 #!/usr/bin/perl
  2 use strict;
  3 use warnings;
  4 use Net::DNS::Packet;
  5 
  6 my $packet = new Net::DNS::Packet;
  7 my $q  = new Net::DNS::Question('.', 'IN', 'A');
  8 
  9 $packet->header->opcode('UPDATE');
 10 $packet->push('question', $q);


Essentially, it seems when a packet header has opcode set to UPDATE, the push method fails
because it expects the question (aka 'zone') section to be non-empty:

468 sub push {
469         my $self = shift;
470         my $list = $self->_section(shift);
471         my @rr   = grep ref($_), @_;
472 
473         if ( $self->header->opcode eq 'UPDATE' ) {
474                 my $zclass = ( $self->zone )[0]->zclass;
475                 foreach (@rr) {
476                         $_->class($zclass) unless $_->class =~ /ANY|NONE/;
477                 }
478         }
479 
480         return CORE::push( @$list, @rr );
481 }

I'm not sure, but this seems like a bug net Net::DNS.  If so I'll be happy to file the bug report...

DW           

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4676 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/net-dns-users/attachments/20150625/c94ae409/attachment.bin>

From rwfranks at acm.org  Thu Jun 25 19:46:58 2015
From: rwfranks at acm.org (Dick Franks)
Date: Thu, 25 Jun 2015 20:46:58 +0100
Subject: [net-dns-users] Can't call method "zclass" on an undefined
 value at ... Net/DNS/Packet.pm line 474
In-Reply-To: <9786F862-EFC6-4429-A0A7-B602D96CFC41@verisign.com>
References: <9786F862-EFC6-4429-A0A7-B602D96CFC41@verisign.com>
Message-ID: <CAKW6Ri6BwF8yyw6x5QCa=z4GfR85mA=MZ2B6PQ2CkhbiVmh90g@mail.gmail.com>

Thanks Duane, that is very helpful.

Please file RT#bug, so we can address it before next release, which has
been "next week" for several weeks!


Dick
________________________


On 25 June 2015 at 19:37, Wessels, Duane <dwessels at verisign.com> wrote:

> An issue was reported to the fpdns repository:
>
>   https://github.com/kirei/fpdns/issues/8
>
> I traced through the code, found what fpdns is doing and replicated it in
> the small program below.
>
>   1 #!/usr/bin/perl
>   2 use strict;
>   3 use warnings;
>   4 use Net::DNS::Packet;
>   5
>   6 my $packet = new Net::DNS::Packet;
>   7 my $q  = new Net::DNS::Question('.', 'IN', 'A');
>   8
>   9 $packet->header->opcode('UPDATE');
>  10 $packet->push('question', $q);
>
>
> Essentially, it seems when a packet header has opcode set to UPDATE, the
> push method fails
> because it expects the question (aka 'zone') section to be non-empty:
>
> 468 sub push {
> 469         my $self = shift;
> 470         my $list = $self->_section(shift);
> 471         my @rr   = grep ref($_), @_;
> 472
> 473         if ( $self->header->opcode eq 'UPDATE' ) {
> 474                 my $zclass = ( $self->zone )[0]->zclass;
> 475                 foreach (@rr) {
> 476                         $_->class($zclass) unless $_->class =~
> /ANY|NONE/;
> 477                 }
> 478         }
> 479
> 480         return CORE::push( @$list, @rr );
> 481 }
>
> I'm not sure, but this seems like a bug net Net::DNS.  If so I'll be happy
> to file the bug report...
>
> 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/20150625/901c197a/attachment.htm>

From willem at nlnetlabs.nl  Mon Jun 29 17:26:46 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Mon, 29 Jun 2015 19:26:46 +0200
Subject: [net-dns-users] Release candidate for Net::DNS 1.01
Message-ID: <55917FD6.606@nlnetlabs.nl>

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

Dear users of Net::DNS,

I am pleased to announce a release candidate for the upcoming 1.01
release of Net::DNS.

This is a candidate for the version with which we consider the
architectural rework and cleanup, that has started late 2012, to be
stable and finished.

This release has the RRs integrated that were previously only
available with Net::DNS::SEC, however without the signature generation
and verification functions. To enable those functions Net::DNS::SEC
still needs to be installed.

As part of the process, the whole of Net::DNS has been brought under
the MIT license already used by Net::DNS::SEC. We requested and have
received agreement and permission from all the principal authors to
apply this license to their respective modules.

Besides the incorporation of the Net::DNS::SEC RRs, this release
contains bug fixes and updates with current DNS parameters as usual.
For a complete list of changes and bugfixes see Changes below.

If no issues arise, the actual release will follow Monday the 6th of
July 2015.

link 	https://www.net-dns.org/download/Net-DNS-1.00_06.tar.gz
sha1 	52fae427c3211ffe792aa4d414225b825d64c51a
asc 	https://www.net-dns.org/download/Net-DNS-1.00_06.tar.gz.asc

Changes
=======
Feature
	The RRs previously only available with Net::DNS::SEC are now
	integrated with Net::DNS.  Net::DNS::SEC needs to be installed
	to enable the signature generation and verification functions.

Fix rt.cpan.org #105491

	Can't call method "zclass" on an undefined value at ...
	Net/DNS/Packet.pm line 474

Fix rt.cpan.org #105421

	Dead link in Net::DNS::FAQ

Fix rt.cpan.org #104657

	Wrong split on Cygwin

Fix rt.cpan.org #101810

	Dynamic update: rr_add overrides ttl of zero

Fix rt.cpan.org #101809

	CAA broken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVkX/RAAoJEOX4+CEvd6SYG5EP/j7ZIsEplMvRGntjFzScKZtP
OdVNEGlrrltgqpNXnnSpOxUitDmwhMFCyWxNYtipcTSjBunRuUU+GXk18PepSUYl
P5I0PfSOnS6O03YYLwhTWhwn1DMDZbHSeYwyMnEl26jhVZbNo3wXA8US5sjTDSCM
wISWkKrQ9g3X4H0e3ezkmdz1awBJ0GUjGEo6/ANEYu2FkJZbdsgR5NZlL0F+CSCQ
F/JwtAoovA0ldSyNUv/7TJJnJC7xtoLA9Mek1RA5y60bxzDQdvIeELYXhiCgSbW/
dTiwYy6HNvIKK2ZKHN8Olz0yunE/o3Ay/Cu88o5suBF6Sj2p+Y3OeN+UeARlUoBo
bG969kj4wl8jPBLGHO8Uz+elVdnQLA0Bnqc4b1+J0E2AJbTBugNWAlKjHrV35HgQ
kMEyNBxTNu3etsbrYsqYc6z3Xhq5C/hktE2XAj9hWTKWUrI1vKvph+dt2t9S2m28
OBFfvjZUl2qIy2/fFVncxffN9ZnGgzcE9h7qD7SXGTfb7+4Oe6xqNOKMp843MjSp
4CgYUfQHJrqZ2w9iDt4LtSI302QeU+b2Hyj3ANGHiC5UZCi6u6FBnmj8g4s5KUug
eEl/xh6x/C2uyFkY5z2/MZ0k6Eu62FAH13mVLwa2RGRpEw3e+NnSu0zUjBzTrV+n
81MT0IXaY2M8OLRTAQZF
=+6M2
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Mon Jul  6 17:32:59 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Mon, 06 Jul 2015 19:32:59 +0200
Subject: [net-dns-users] Net::DNS 1.01 Released
Message-ID: <559ABBCB.7070403@nlnetlabs.nl>

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

Dear users of Net::DNS,

I am very pleased to announce that we have just released version 1.01
of Net::DNS.

This is the first major release of Net::DNS since Michael Fuhr started
this project in 1997. Since then many people have contributed to the
Net::DNS project and shaped it into the distribution it is now. A very
incomplete list of authors (from the Copyright sections of the
modules) is: Rob Brown, Andreas Gustafsson, Olaf Kolkman, Sidney
Markowitz, Robert Martin-Legene, Chris Reinhardt, Mike Schiraldi, and
Andrew Tridgell. Thank you all, and also all the unmentioned people
for contributing to, developing on and maintaining Net::DNS!

I took over maintenance of the distribution at NLnet Labs from Olaf
Kolkman in 2012. Since then Dick Franks, who was always a prominent
contributor has become the primary developer of the distribution.

In late 2012 a major architectural rework commenced, initially to
support IDN, but later also to cleanup and to turn Net::DNS in an even
more robust and readable code base with a clear and unambiguous
interface. We have made this a major release because we consider this
architectural rework and cleanup now stable and finished.

This release has the RRs integrated that were previously only
available with Net::DNS::SEC, however without the signature generation
and verification functions. To enable those functions Net::DNS::SEC
still needs to be installed.

As part of the process, the whole of Net::DNS has been brought under
the MIT license already used by Net::DNS::SEC. We requested and have
received agreement and permission from all the principal authors to
apply this license to their respective modules.

Besides the incorporation of the Net::DNS::SEC RRs, this release
contains bug fixes and updates with current DNS parameters as usual.
For a complete list of changes and bugfixes see Changes below.


link 	https://www.net-dns.org/download/Net-DNS-1.01.tar.gz
sha1 	a4b9c177117397604cf0ee6f10ac80034aff37bc
asc 	https://www.net-dns.org/download/Net-DNS-1.01.tar.gz.asc


Changes
=======
Feature
	The RRs previously only available with Net::DNS::SEC are now
	integrated with Net::DNS.  Net::DNS::SEC needs to be installed
	to enable the signature generation and verification functions.

Fix rt.cpan.org #105491

	Can't call method "zclass" on an undefined value at ...
	Net/DNS/Packet.pm line 474

Fix rt.cpan.org #105421

	Dead link in Net::DNS::FAQ

Fix rt.cpan.org #104657

	Wrong split on Cygwin

Fix rt.cpan.org #102810

	Dynamic update: rr_add overrides ttl of zero

Fix rt.cpan.org #102809

	CAA broken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVmrvHAAoJEOX4+CEvd6SYfykP/3o0wAAOwUlhYr9kouDesyd8
0NuF5EmMD4oWt6g6hAY2t7HSqnAiNJx3QPjrl7SkJZVEG01FQQq8KOPdPTovMPqj
VG0kfrUwom/E+UN3f56L1zXr0cImeLGMd+fE3gc5KnlfJOViVEZaaJcfQ5wPkpLs
5rCRRA2VijIiKYnQMD4u0ZrL3vvDGTx3EZvOvD/WEhME45jTwCbuU5nZVUI0nAfH
KexaSh4ZgEhxKTRKpMcNaaS+qgtESuIc32sYjkQ/dV2oj8JK8O0vaLTPjR3W1lYh
XrQBy8vrYB+aEWHPsL8JMbJRaFRcMZvnF6JmDAApTxE5zDT9TPbLWKjEWHMfjjTI
nLdC8Cw9ITYliuayA9BUuBWxYm4drCjtWMrXJ4QAHbCVfQjpsx6KkWGzJcva99C+
b6dBU9Igc1+y8jUkIbsvHvJDv2HQa9duyacGp2sQZ5B7rALc3Hz3oEqZhBYmzgYM
f/jnagSPewcwL9dmdA4jRNEvHOihFLw6oRW3yajpVK4ImHwDaN+5Br2U60cFKIcr
HxN4mWjOOb10XO/HoZvYAchzp98uDxM8Cg3ol98DKKrgQtrRCMt2c4kBkurwU3Qo
pJmDZRPEN7Lu57+U1dOGI8FIlDvDTbK7Bw5u/MPaFm2UJoVF1PtOc3RrTjyptoHx
3VpDI8UH/LG4YVrCxQvN
=yiwP
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Wed Jul 29 07:38:53 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 29 Jul 2015 09:38:53 +0200
Subject: [net-dns-users] Release candidate for Net::DNS::SEC 1.01
Message-ID: <55B8830D.2090702@nlnetlabs.nl>

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

Dear all,

We have a release candidate for the upcoming 1.01 release of
Net::DNS::SEC.

This is the companion distribution for Net::DNS 1.01.
Since Net::DNS 1.01, all RRs related to DNSSEC have been migrated to
Net::DNS.  This distribution is now only needed to perform
cryptographic operations: i.e. signature generation and verification.

For a complete list of changes and bugfixes see the Changes below.

If no issues arise, the actual release will follow Monday the 3th of
August 2015.


link 	http://www.net-dns.org/download/Net-DNS-SEC-1.00_02.tar.gz
sha1 	ce66a5bb57115afd9334686d4c86d1d0db988e38
asc 	http://www.net-dns.org/download/Net-DNS-SEC-1.00_02.tar.gz.asc


Changes
=======
Feature
        The RRs previously implemented in Net::DNS::SEC are now
        integrated with Net::DNS.

Fix: rt.cpan.org #105808
        Version test for Pod::Test is broken

Fix: rt.cpan.org #105698
        Net-DNS 1.01 conflicts with Net-DNS-SEC 0.22
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVuIMNAAoJEOX4+CEvd6SYoSEQAKefu36evyJqty+ZK+qKbBYb
tHg39ZAtjelaZtZRo1PUwITyI+ASXx9TMZdbAQBkzFrcGJBsru+VgaUZ2M5o2gS6
ibQKg0u5fVQEA5Xmay+xwHPyymnPIk8gjI1hkYbqAGdI2Qo6kd09L3/cDKEaXG+l
e8+jpaAsdesQFKHv1U/Q1kGWZ46JImNs+u/a0H/dKdB43fEqpklIQNdUCfM3EC5H
f5wdiKngv0qPhPQ9LiRPY/dAP2jWCYIQhchue79Z5FlSNHeEJjC232fnDKj9DBCH
ccIRTZ+9gdDH0SqK3Jge1/TqR+bV1qQolwbgT9OQxBl8GKSuR7aSS8aImT8fXmkE
R3E+gLUy2RI5d/S8NXv8mIjBciRuM8YFGY8ba6YUIUIyjzXC9Md35CtVO1uPmfYc
o0V1yXdleBQgX5Z1AT4WexuKrbbsgd/Vi1J/cakoC9wccaYVeS6qqiUNRW8WaFwe
wHXBHcDQEL7LeaEJtfJeg4/riwotuP8ZFGo/s6l5sxa2l1wofOyJfRB0OdCiNdDw
aQMuSL+4EeO00dYDiWQ21PbLU3G6WII5qxb8s7JbA2Q4nC5Dof17dzAv1zHgpzeu
QFrf4aq46HuG7pAvAs5Kk49vH7YeOFNGLbrQvX1U+1vm/0RDnZzoPmzq6jlqZhHC
mTO6nhZPRFiLZdGHRPz1
=aClg
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Mon Aug  3 06:58:34 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Mon, 03 Aug 2015 08:58:34 +0200
Subject: [net-dns-users] Net::DNS::SEC 1.01 Released
Message-ID: <55BF111A.2070409@nlnetlabs.nl>

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

Dear all,

We have just released version 1.01 of Net::DNS::SEC.

This is the companion distribution for Net::DNS 1.01. Since Net::DNS
1.01, all RRs related to DNSSEC have been migrated to Net::DNS. This
distribution is now only needed to perform cryptographic operations:
i.e. signature generation and verification.

For a complete list of changes and bugfixes see Changes below


link 	http://www.net-dns.org/download/Net-DNS-SEC-1.01.tar.gz
sha1 	40533f5c50a05dcf3b3383e26f18daea0a05e34f
asc 	http://www.net-dns.org/download/Net-DNS-SEC-1.01.tar.gz.asc


Changes
=======
Feature
	The RRs previously implemented in Net::DNS::SEC are now
	integrated with Net::DNS.

Fix: rt.cpan.org #105808
	Version test for Pod::Test is broken

Fix: rt.cpan.org #105698
	Net-DNS 1.01 conflicts with Net-DNS-SEC 0.22
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVvxEWAAoJEOX4+CEvd6SYrykQAKKasp7btLh9Bsom8gwh9xi6
yMJ/fWjAd66cl7x2uGnVRCrc1+bf3KXsUjh4IO8ct8l90QCVHc9abNuJcJqXF1am
AFvq4gCBA8HAiYekpdSQApUCXPa/MBBGFjEzZXoBGngyfI/YjQ48D19Yfbr7ulkm
R4k1qBTU5tiE7HB00NSbrxrLQuEdjOrnk8MvTwwzj7WK9PfmV6nJbbWAGdBOGC0o
cmOVCKgfOoEQparfuQZjdvjUo7wUoM8WmeWmzpTgzuqu+wjeps8MzqUbJmM/Jc4I
GDpcnXbep6Ut2B+KZ3j2ZTZeV7FaoAWIver/2qjxtsVKUmkH2+RGKEHi2MVDeGhi
Ln3g9i52Zh2vhEoLYd1adDpj+cqE8DXo83weJi53e0pxaqvzy99qyeOUadPPUicU
Db8PW/Vd9H06SqSb+paYSqnf1xycf47q7DrVE2teRff3p0wkDUQTf+Dvva3Fqsiq
AkWEDGBEM//bCPty/l6Ch6/JtzGFCHayD+hRV2hDjWCXOkdS6Eqo/YUaJE58jtY+
IhOpiSBJ6WVSSocSQdQySecRH0PJBTw4C9Bzh5o3/tZ6uOyXs5QAzgS8lVw4UtmW
Vb27WGSQIRm4JU9pOQ6Yqv2tzpev3kAAE2Uyit47TW/bZn6j2ij1MUr3J/VIfPUQ
IZ9OwKuGSy3p3fCTzgxs
=jkJC
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Tue Sep  1 08:07:02 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 1 Sep 2015 10:07:02 +0200
Subject: [net-dns-users] Release candidate for Net::DNS 1.02
Message-ID: <55E55CA6.5040300@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

We have a candidate for the upcoming 1.02 bugfix release of Net::DNS.

This release addresses a single bug with Net::DNS::Resolver::Recurse
in handling delegations containing empty-non-terminals.

For a complete list of changes and bug fixes see the Changes below.

Please review this candidate carefully. If no issues arise, the actual
release will follow Monday the 7th of September 2015.


link: https://www.net-dns.org/download/Net-DNS-1.01_01.tar.gz
sha1: fa77c760a284d4db8da0cb297adc929b0434cf6a
asc : https://www.net-dns.org/download/Net-DNS-1.01_01.tar.gz.asc


Changes
=======
Fix rt.cpan.org #106565

Net::DNS::Resolver::Recurse and IPv6 Reverse DNS

Fix rt.cpan.org #105808

Version test for Pod::Test is broken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV5VymAAoJEOX4+CEvd6SYD+wP/1T0oR253WlDPM7/P1HlVZhl
qHOqAaUjcKPKEclvX8+96G2sxEX/7ZgLH03u4PQ6alhua9YJH1U/m2iQ8dAkkkzb
JzSIxqTj6FH8Y9TAdQfTDiW28nKPV+5OOEYmlU83FOtAWy7f8VJSpiZAI1j7yvRt
gQwnrFaFSUmzqAMwZ9ViyGbxgA+MF6Iz8SBobTI7iqvodcTAXUAvvuweCmttKg78
ibBOgidp9tPQiWU7ZW08ACYzf3qgN0shZ5D/KkFTEtVQsjHUBXfJlJKSgYeYxGwO
nQoXGAs1cW1ev315oTT/TjeBPpMKCRBWehkHu302WIhnSrIkScfJN/2dijF3u/uG
aRZ2+lIP4BxfUSIKKYfkTVGT+pH8jzwKxYGN4344DYaweZ/gAgLA8FxMmVGWc0FS
ro4gsC+Og3l9q+YstOuI7YthOmH3eqa8d0zRt86d3RD6wfGX9ozq8e7y35zQYcNg
j8rYDDEdFzFRu3sg8Lqk9MH67nQ0DXeSEtcOu90t8Etl8Msbvio1hLuEVVGCV9so
d+X+cKyg38l9Z/i3hV+m/JVTh3hfTWPb/uKE0jFlhlhbhDtA4frVtlpSqOw1Ys3G
BrOXNdJrK6ALEJFcmSnZiFRlDnKK3NkAqN+Cx6y0Fo/FDPZhd/dcHKAFNvZGjzWO
YytfOhG2tHnfnO1sE2Vx
=hvBl
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Tue Sep  8 08:22:23 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 8 Sep 2015 10:22:23 +0200
Subject: [net-dns-users] Net::DNS 1.02 release delayed
Message-ID: <55EE9ABF.2010102@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

We publish candidates for releases and ask you to try them out to
receive feedback on possible issues that we might have missed and have
an opportunity to correct them before the actual release.

Besides your feedback, release candidates are also published as
developer releases (through PAUSE) so they get tested on a wide range
of different platforms by the CPAN testers.

Unfortunately their test-report collecting and processing site has
been down now (since August 30). This time we did not receive feedback
from the developer release. We have seen one fail (besides passes) in
the CPAN testers log tail though.

Furthermore, developer releases are also processed by cpancover.org
which provides coverage details of the unit tests. The reports for our
recent developer releases show too few covered files, suggesting that
the unit tests somehow stopped halfway. It might just as well have
another cause, but we don?t know.

These things combined have made us decide to delay the release for one
more week. By then we hope to have our usual CPAN testers feedback, or
have more insight in what the issue may be.

So, if all is well, the actual release of Net::DNS 1.02 will follow
Tuesday the 14th of September 2015. Find our latest develop
release/release candidate below.


link: https://www.net-dns.org/download/Net-DNS-1.01_04.tar.gz
sha1: efccbecd29957625d6f5b32f524447742c4fad27
asc : https://www.net-dns.org/download/Net-DNS-1.01_04.tar.gz.asc


Changes
=======
Fix rt.cpan.org #106565

Net::DNS::Resolver::Recurse and IPv6 Reverse DNS

Fix rt.cpan.org #105808

Version test for Pod::Test is broken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV7pq+AAoJEOX4+CEvd6SYWDMP/Rb/qHihC0fwCl0d6MY7kTcK
FqiY3MJW7VJBOIyea8AW1gQNjSkU/IUdVs2annfY0GcNTxXkEC48lRYEPp+FMPK5
aoqJxv9pJ9RfBBamLyDsGrD8OX9fxUzHNeYqA1+5G6ozkYGNpVXTxutanq/nheof
jZIR143kv64OXy9F5oJbFNaHVSiK+w1WdMyCwiVNQc5h6yp8anseg+aVlcfln9kZ
nrxCW0wBWczbbpypUDngHCzU1eV8u3ZXlaZ0klJ8QRFmhD8mROOr2EcWE5SkKZbU
Bxs1mIVAmrq7o7nx59muCaZQFedhMxJ25DmwIAxQfsljhEbJRg/ZEPYVxmWUrnL2
0SG0hTGg1i37nopU1USDVftxOx6pbz9boOA5uLMYZYBiflen3Mz1cgSeb3exCMab
hcKlQUCBi6tsoE+A4bA9HPE/UlqMBp0IB6eOAd8n2E5A3xuuVYHVJfWFn9H6qSQR
i/qHXpKNwoKAA7Eu/HqSoXNUzc3PlBFXZYvft39Hs6ZXsniUlszSkHr/julLrRU/
EfsNqYukwDlF+Mcauu3IDghYdC/zffbZkFwU/Xzqg7JTioXSHLiwHlRArqWyn8yT
mRWYmpoLQt3WumT/bg3IeJBNzuOtDbM2fxrWy1yEtY97fnanfAWLz1zD8tygxzVk
6B7mEsKFQ2c6qFBIM7Te
=EPnt
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Tue Sep  8 08:22:23 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 8 Sep 2015 10:22:23 +0200
Subject: [net-dns-users] Net::DNS 1.02 release delayed
Message-ID: <55EE9ABF.20507@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

We publish candidates for releases and ask you to try them out to
receive feedback on possible issues that we might have missed and have
an opportunity to correct them before the actual release.

Besides your feedback, release candidates are also published as
developer releases (through PAUSE) so they get tested on a wide range
of different platforms by the CPAN testers.

Unfortunately their test-report collecting and processing site has
been down now (since August 30). This time we did not receive feedback
from the developer release. We have seen one fail (besides passes) in
the CPAN testers log tail though.

Furthermore, developer releases are also processed by cpancover.org
which provides coverage details of the unit tests. The reports for our
recent developer releases show too few covered files, suggesting that
the unit tests somehow stopped halfway. It might just as well have
another cause, but we don?t know.

These things combined have made us decide to delay the release for one
more week. By then we hope to have our usual CPAN testers feedback, or
have more insight in what the issue may be.

So, if all is well, the actual release of Net::DNS 1.02 will follow
Tuesday the 14th of September 2015. Find our latest develop
release/release candidate below.


link: https://www.net-dns.org/download/Net-DNS-1.01_04.tar.gz
sha1: efccbecd29957625d6f5b32f524447742c4fad27
asc : https://www.net-dns.org/download/Net-DNS-1.01_04.tar.gz.asc


Changes
=======
Fix rt.cpan.org #106565

Net::DNS::Resolver::Recurse and IPv6 Reverse DNS

Fix rt.cpan.org #105808

Version test for Pod::Test is broken
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV7pq+AAoJEOX4+CEvd6SYWDMP/Rb/qHihC0fwCl0d6MY7kTcK
FqiY3MJW7VJBOIyea8AW1gQNjSkU/IUdVs2annfY0GcNTxXkEC48lRYEPp+FMPK5
aoqJxv9pJ9RfBBamLyDsGrD8OX9fxUzHNeYqA1+5G6ozkYGNpVXTxutanq/nheof
jZIR143kv64OXy9F5oJbFNaHVSiK+w1WdMyCwiVNQc5h6yp8anseg+aVlcfln9kZ
nrxCW0wBWczbbpypUDngHCzU1eV8u3ZXlaZ0klJ8QRFmhD8mROOr2EcWE5SkKZbU
Bxs1mIVAmrq7o7nx59muCaZQFedhMxJ25DmwIAxQfsljhEbJRg/ZEPYVxmWUrnL2
0SG0hTGg1i37nopU1USDVftxOx6pbz9boOA5uLMYZYBiflen3Mz1cgSeb3exCMab
hcKlQUCBi6tsoE+A4bA9HPE/UlqMBp0IB6eOAd8n2E5A3xuuVYHVJfWFn9H6qSQR
i/qHXpKNwoKAA7Eu/HqSoXNUzc3PlBFXZYvft39Hs6ZXsniUlszSkHr/julLrRU/
EfsNqYukwDlF+Mcauu3IDghYdC/zffbZkFwU/Xzqg7JTioXSHLiwHlRArqWyn8yT
mRWYmpoLQt3WumT/bg3IeJBNzuOtDbM2fxrWy1yEtY97fnanfAWLz1zD8tygxzVk
6B7mEsKFQ2c6qFBIM7Te
=EPnt
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Wed Sep 16 11:29:22 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 16 Sep 2015 13:29:22 +0200
Subject: [net-dns-users] Net::DNS 1.02 released
Message-ID: <55F95292.8030703@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

We have just released version 1.02 of Net::DNS.

This is a bugfix release. Most prominent fix is correcting the
handling of delegations containing empty-non-terminals with
Net::DNS::Resolver::Recurse. Also the dependency on the MIME::Base32
distribution is removed to accommodate MS Windows installations.

A new version (1.02) of Net::DNS::SEC is released too. This bugfix
release deals with an exception raised in a Net::DNS unit test
(t/10-keyset.t).


link http://www.net-dns.org/download/Net-DNS-1.02.tar.gz
sha1 3c1da57957d0ba458472296273d7609feeb44fe5
asc  http://www.net-dns.org/download/Net-DNS-1.02.tar.gz.asc


link http://www.net-dns.org/download/Net-DNS-SEC-1.02.tar.gz
sha1 e5515763399e5616a90bee532387862843c59461
asc  http://www.net-dns.org/download/Net-DNS-SEC-1.02.tar.gz.asc


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

    suppress messages: Can't locate Net/DNS/Resolver/linux.pm

Fix rt.cpan.org #106916

    Dependency on MIME::Base32 makes Net::DNS not installable on MSWin32

Fix rt.cpan.org #106565

    Net::DNS::Resolver::Recurse and IPv6 Reverse DNS

Fix rt.cpan.org #105808

    Version test for Pod::Test is broken


Changes for Net::DNS::SEC
=========================
Fix: Bug in t/10-keyset.t raises exception in Net::DNS
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJV+VKSAAoJEOX4+CEvd6SYHWgP/00UktKIyJy8FVlItGqztRXS
Vo8gIrlNyR6bXLPPNByHzMZ4p1GNSBBXdCSU9wMqRaRwAJCuKpf9ucPtRrI02mch
0hjotroWiQX0ll96x+W9xLFA/lfo/t3fcP/2BNATpWAQZ0dWthl47ZccOqEetDFP
vWAorZbD+efldGu3ggW9lrxidT5091EgdK4s1pquX9wmX3nbUxsYdLoyyvolEFEp
jQTWPKaK8w+rGkckhL4kH1X7W5m5Dfco+5NdAdbVnRAjjkvMkHuhr4SRy+/bfWTM
rFB9MtYgk56Tuc9xX07yN0HJmjz+Cfz+VtxG+Nac6aXw5jfyJ4ALFJ7V5n8kwDjl
0ivfAljrYIcrFFdaSA+NZJlgTyGuxSYxkOSuwNsowHU8N6y7tok+aKMxoVni6OQr
M2jYVQZucFsT0mtIZgewldoMnooONwzwL5siGctQaGV1EfXnsSwmdegukuOxIQrg
+sanmiFPuPwhiJwsoPrAZi+9Cu7pN3w0vpr5SAocEhhnNnpU+o/CE8l84DXdnXdB
S5wO8Ndov8up2IZ/LahysHs6LymI2iDg/QsV+LGTwUS1nMKpkvnwhdfO7YxpgyPm
YRMjZHDtJXuxMoJ3fZybu+lolBCmYx1x31dSwcMl9lo7GrpeChHKj1ch5Jz6HZgm
+VQShhj0bViEUQLBzeyd
=y/LJ
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Fri Oct 30 12:44:11 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Fri, 30 Oct 2015 13:44:11 +0100
Subject: [net-dns-users] Release candidate for Net::DNS 1.03
Message-ID: <5633661B.2050506@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear All,

We have a candidate for the upcoming 1.03 bugfix/feature release of
Net::DNS.

This release addresses several very long outstanding bugs. The oldest,
TCP support for bgsend, which was submitted in 2005.

For a complete list of changes and bugfixes see the CHANGES file.

If no issues arise, the actual release will follow Friday the 6th of
November 2015.


link: https://www.net-dns.org/download/Net-DNS-1.02_09.tar.gz
sha1: 7e18c1eef8db62ba3d7f807334aa63959638edf1
asc : https://www.net-dns.org/download/Net-DNS-1.02_09.tar.gz.asc


Changes
=======
Fix rt.cpan.org #107897

	t/10-recurse.t freezes, never completes

Fix rt.cpan.org #101978

	Update Net::DNS to use IO::Socket::IP

Fix rt.cpan.org #84375

	Timeout doesn't work with bgsend/bgread

Fix rt.cpan.org #47050

	persistent sockets for Resolver::bg(send|read|isready)

Fix rt.cpan.org #15515

	bgsend on TCP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWM2YbAAoJEOX4+CEvd6SYD0MP/3AWki57JYBqqaDwBITxvPeg
T3d8qvHb8TdaR+qTMTWrMWhIQN3U30g02UYT5lVVJUilZ75fDJhGZExuCYMSbUJj
0kkHueErVuUjn6X0Ri8TBv4s09V/xc534JxY3O48PVNLI4QvAH2RKk0fMwxObbfA
M/XGyG56r1uHPsREuHMbqvlLy3969mL9VHtbeH/yfXPbBsZzvdMFqsl8TxV9TDRN
o4p8ovAe6W96VZ1FvaLIfpVxweb/jGPwONcGyzTltacHZfkY+KuRrNkHgT2gcHHC
z/9QuqrAiRlNyxx30H4U1N5weourhsmJL7YirZP3ZyDs2s5u9qWxeiDqLP+tm1zt
OkZiz3CtEsWvCCWMV4eG3TDJaY1e6U8G2kRtyQkaxKLaglZ9JMT6pQaRM9AYlHtU
AW3PRQ/RFuQCE56N5c1WoyrjC3gP5v4ABWDsYUnXtaEof8rsuH+q/HY4tUMj4vtn
Ei6Eg/Gj8S+wPLTidH6mPHHeVrLvhqxiM8/8WMfT6hU7gg051sHY+vhiuWf+hDLj
lJ/JnmSlKSgUx/HuGPKGNEabk2V3rEh5c82o+BrT/f3acMnK1zbFJp7JsbhXnjya
BzlrrYLS3kN2HlpWghO4dhGLqhzAoRz87UzCgntmAUbdPEjYw9HAlD29+zAv65G2
BcEmE9o79Fza24hyNbPp
=DIFK
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Fri Nov  6 16:04:12 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Sat, 7 Nov 2015 01:04:12 +0900
Subject: [net-dns-users] Net::DNS 1.03 Released
Message-ID: <563CCF7C.5000105@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear All,

We have a new release, version 1.03 of Net::DNS.

This release contains work on Net::DNS? Resolver. We now use
IO::Socket::IP for better and more equally treated IPv6 support.
Also the recursive resolver has been optimized.

This release has some very old  Request Tickets resolved, which
contained feature requests, for TCP support and persistent sockets for
the Resolver::bg(send|read|isready) functions.

For a complete list of changes and bugfixes see Chanes below.


link: https://www.net-dns.org/download/Net-DNS-1.03.tar.gz
sha1: e4c79fc288b9fc06c27bbcc9fb48d26ae590492a
asc : https://www.net-dns.org/download/Net-DNS-1.03.tar.gz.asc


Changes
=======
Fix rt.cpan.org #107897

        t/10-recurse.t freezes, never completes

Fix rt.cpan.org #101978

        Update Net::DNS to use IO::Socket::IP

Fix rt.cpan.org #84375

        Timeout doesn't work with bgsend/bgread

Fix rt.cpan.org #47050

        persistent sockets for Resolver::bg(send|read|isready)

Fix rt.cpan.org #15515

        bgsend on TCP
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWPM98AAoJEOX4+CEvd6SY59QP/RR+KCm3aXukw0Miytf0sZzF
qqBKGZ1HZ9eMFC/JNXYoaxAuavuMLl4s31ByLV1BjQTXSU/XKgkoNQZXaFhvA+AD
sSNvT0wrTylD3lSf+NIvUSV/qhUM6+ZgTghBExy21OiJ0dY/Oxyzn8hIK3biYTuY
j9/Rg9ejqE4r2s2txI4upwjopU5Wr2M0abP8ItWCKDTr+knvmeib1QaJQoPS07mH
reDXtIfB0hyrvI9r88wUDU3ojom4Yd9s0c3fxEi3gTSwwJtrXb03IagrFJh/9JFW
MV3iDzUqd6U/TT0rF0WiIJ+EhhZB/wuHzn8V8/7m2m0DCP1rF93UxPV77qXM7KiX
MABRcvXDkimQHabbGXjGU1KwqAB+Zgxp5c8Y6j+hO0j3khugP9RA0ZcFxCpCfYq1
XjUwXBl6xQL6QDGaiZ7rGZ8n2f18APcWb27vZXNQ7629A3O8tNR8EZeH6V9mrdAB
pnv4ZTcX7TcogMzeJYLN0bLF26darNLHCmTVFTgjkwAIoOSwqSNdvdbd+qzlfzZR
w8w3cJq82rd3dDITO7/8fjWSSsEtdeebPdYU07A8EZqssdJhlyduV2zn6pljbya/
1fURyfB31Gad7NT+nq9WPfnsqK4rE1xeYB+wT6Q2pkmvAE0Oh3rG4REV1vifl8nb
jSh5+63Dv4LvnVWW31hC
=JyMt
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Thu Dec  3 11:15:30 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Thu, 3 Dec 2015 12:15:30 +0100
Subject: [net-dns-users] Fast-track release candidate for the emergency
 recovery and bugfix release 1.04 of Net::DNS
Message-ID: <56602452.3080005@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

We have a candidate for the upcoming 1.04 emergency recovery and
bugfix release of Net::DNS.

The 1.03 release of Net::DNS had bugfixes (TCP and persistent sockets
for bg(send|read|isreead)) that were unfortunately tackled in such a
way that dependent modules broke.  This release contains fixes that
make those dependent modules work again (without loosing the earlier
addressed fixes).

We have been doing release candidates to help to prevent these sort of
situations from happening.  We realize however that just one week is a
short period to do a proper review and also that some issues might not
be immediately obvious.

To improve we will from now on always do regressions testing of
modules dependent on Net::DNS ourselves before doing the release
candidates. The results of these regressions tests are put online
here: https://www.net-dns.org/regression/.  Packages that still have
regression with the release candidate now, do have it for known, non
hazardous, or reasons that are being addressed (see footnote 1).

For a complete list of changes and bugfixes see the Changes section belo
w.

Because of the severity of the bugs and also in an attempt to prevent
further fixes based on version 1.03, this is a fast-track release
candidate.  We still ask you review this candidate carefully and
thoroughly and report back if there are issues!  If no issues arise,
the actual release will follow Tuesday the 8th of December 2015.


link: https://www.net-dns.org/download/Net-DNS-1.03_03.tar.gz
sha1: b7716be4a497909688826e272a5360e45a3af571
asc : https://www.net-dns.org/download/Net-DNS-1.03_03.tar.gz.asc


Changes
=======
Fix rt.cpan.org #109183

        Semantics of "retry" and "retrans" options has changed with 1.03

Fix rt.cpan.org #109152

        Deprecated method make_query_packet breaks calling code

Fix rt.cpan.org #109135

        Resolver behaves differently with long and short IPv6 address
	format

Fix rt.cpan.org #108745

        Net::DNS::Resolver bgsend


Footnotes
=========
(1) Explanation of regressions that still occur for 1.03_03 as seen
    on https://www.net-dns.org/regression/:

	? Mail-SpamAssassin is because of a warning given for the
	  developer release version number and is harmless

	? IO-Lambda 1.25 simply has to rollback it?s change that it did
	  for the 1.03 release (IO-Lambda 1.24 works again)

	? POE-Component-Server-DNS has a bug which has been reported
	  with a suggested fix (which has been tested with
	  POE-Component-Server-DNS-0.30-fixed).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWYCRSAAoJEOX4+CEvd6SYjzUQAJ0Cid3V8XXfHSJq7ZWD3CUp
YkQRUeA6FzvT5NhX44YXe3Z47GMKAzOISZtenMTOazZFhWrDeQGE3ArwZQksVMJi
S7H7AbXv2x78q8bsOIwmWo/C2Tt/Vv3K9kz9m3fbTIMakaBYPnrIkcYWkt2GfllQ
NR0gDz08BhoQktILCxS/YCJeLcpqMC8oiTodn1+Z4I3tHR2C1ie+8+eOHH929a3g
SLg51kQFQ8VvYWtkZsmqOWOwGXzygirjnz4nkkRwRKcu+d+YVZU2z3l3udGdnuz8
nI9/AH1rL8JkWFXQdxGaICv7SXF4vCAj13GZsWaCYbTKfFT+OYkp4iu/2H7WJfnW
F2n5DDjZbx5FOOPNUjoZjOUPaYGo6g7c2KAGcI+VFHwLc51NZ3wc/ZZeXmSBIX61
EmNxpVKm1n66GxEKW3iyG0Ig056/pCMdBt/D+pob2v7Clr1MCZzCtEdvMKR5EEBX
nyarUcg/AZYbSCnOvLxMsXa2NGTkmATqseWaUJLpT1yE2X8PTQoMn8M90NnpPhfF
jXHJDHD4RkbDN8HdbFvYs5F8bVtmWkJ7n1QzAA9fFoq7hXHJ1GORSiHaEQ7zqFV/
il6PCG6yIxQ0aLvfydfGnsGFvlHwiYT8Y6XsK4nL4xURAkWhH6UlTH1mjSrIOhAp
m7yZNkLiJaPX9gsJI2/7
=xpee
-----END PGP SIGNATURE-----


From willem at nlnetlabs.nl  Tue Dec  8 20:54:02 2015
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Tue, 8 Dec 2015 21:54:02 +0100
Subject: [net-dns-users] Net::DNS 1.04 released
Message-ID: <5667436A.90206@nlnetlabs.nl>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear users of Net::DNS,

We have a new release, version 1.04 of Net::DNS.

This is a emergency recovery and bugfix release.

The 1.03 release of Net::DNS addressed some long standing request
tracker issues (TCP and persistent sockets for bg(send|read|isreead)),
but unfortunately and unintentionally in such a way that some
dependent modules broke.

This release has fixes to make those modules work again without
reintroducing those issues that version 1.03 had resolved.

To support us in this effort we have started to do regression testing
of dependent modules ourselves, by running the dependent module?s test
suite against new Net::DNS code.  The results of these tests are put
online here: https://www.net-dns.org/regression/.

For a complete list of changes and bugfixes see Changes below.


link: https://www.net-dns.org/download/Net-DNS-1.04.tar.gz
sha1: b420a9bf8fdc8f264dde2306746232f9fba191d6
asc : https://www.net-dns.org/download/Net-DNS-1.04.tar.gz.asc


Changes
=======
Fix rt.cpan.org #109183

        Semantics of "retry" and "retrans" options has changed with 1.03

Fix rt.cpan.org #109152

        Deprecated method make_query_packet breaks calling code

Fix rt.cpan.org #109135

        Resolver behaves differently with long and short IPv6 address
	format

Fix rt.cpan.org #108745

        Net::DNS::Resolver bgsend
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWZ0NqAAoJEOX4+CEvd6SYX8UP/iOxxnELAz7CI6yLR7RzqMlh
KwkEfw3LeNZijgxInRYIGrBC9hOYdChHldZAL60ZTvWqyuUBd+8RKfD+HFdN2zrI
E9omWNJdNMaMUNl5G8JKaOtedEMHrhkjvfolu8Xy/tbldhk2H0H8LAJZCkGYra67
NENia9TKTtMrGA7LwOGQSX+F+OvG23j/ZEodh8T/luC0dQLcc6U0MVTN+6vgAunZ
g1x1PozmYE/n7rbPvxld+wxCGlETXQv/LbTn6UXi/D0yk+L2pTr23GsOMtNKr48o
1piQagxrMUew9yW9SvL4OlRtIc9codsP81gxanU2SJsWqwWu4L36jUpZpe++gUgC
WyFRbKXyuIOkyCy5PTKi/340/Vnn8lrUYC8mFGWlCGsL6IkgjMO2zZN0rb2zCpdf
anLgcSfvHIB1RGIdd4NNGIVQWedNHWNPVJnLV7QuOS7pTDFpJeDH/AeXfUzJiv6k
svKK09VGnTWg8way+Xb1iQYuXvTa9kcnzez3X+muPtzho5mcStcaJNpKm9LKPqk5
qzCNGU9UWWEaKK39XgkSr1tFlb+ZNIzu57BSCwMYfJuGjKyD3+fWr9cvgCjuMgE0
UVDi9THhpERxjrZNEqvFqGL/+V2qX9jobOzU02H9okunennRLmgLGAyAbPa1J6Ha
A5joCCJjA/7ni6PMq9/C
=tzb4
-----END PGP SIGNATURE-----