From dougb at dougbarton.us Tue Dec 18 20:06:46 2012 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 18 Dec 2012 12:06:46 -0800 Subject: [net-dns-users] Very exciting to have a list! Message-ID: <50D0CCD6.8000601@dougbarton.us> Thanks to NLnet, and especially Willem for setting this up. Personally I think it will be very useful, and I'm sitting on at least 1 idea that I can't wait to share. :) Doug From chris at buxtonfamily.us Tue Dec 18 20:22:55 2012 From: chris at buxtonfamily.us (Chris Buxton) Date: Tue, 18 Dec 2012 12:22:55 -0800 Subject: [net-dns-users] IXFR methods Message-ID: <29B2FF62-FC99-4D15-AE73-205E491E7DFB@buxtonfamily.us> Hello all, As Doug said, it's very nice to have a list. Has anyone else created an IXFR method for Net::DNS::Resolver? I have, and I think it's pretty good, but I think it could probably be improved. Here's my code -- requires perl 5.10 or later: # Hack IXFR capability into Net::DNS::Resolver sub Net::DNS::Resolver::Base::ixfr($$$) { my( $res, $zone, $serial ) = @_; local $_; # Send IXFR requests over TCP $res->usevc(1); # Construct the request. It contains an abbreviated SOA record in # the authority section, where the only fields that matter are name, # class, type, and old serial number. my $packet = new Net::DNS::Packet( $zone, 'IXFR' ); my $soa = Net::DNS::RR->new( name => $zone, type => 'SOA', mname => '', rname => '', serial => $serial, refresh => 0, retry => 0, expire => 0, minimum => 0 ); $packet->push( authority => $soa ); # Send the request and store the result in an array reference. my $result = $res->send( $packet ); # The method here is, we're going to accumulate records into arrays # of @$items, and then put those into @$hunks like [ $mode, $items # ]. We then push each $hunk onto @diff. $mode will switch from '+' # to '-' and back again for each new @$hunk. Therefore: # # @diff = ( # [ $mode, [ $rr, ... ] ], # ... # ) # # Each @$hunk ends with an SOA record. Every time we encounter an # SOA record, we start a new hunk right afterward (with the next # record) and switch the $mode (the operator for each hunk). # # If you look carefully, you'll see that the very first SOA record # is inserted into an empty @$items, but this @$items array doesn't # get attached to @diff before being replaced with a fresh array. So # we're processing it to set the $mode, but we're otherwise throwing # it away. # # The last hunk (started after the final SOA record of the IXFR) has # no records. Always. So we remove it before returning @diff. # Therefore, an IXFR that requests changes since the current serial # will return an empty array; an AXFR-style IXFR will contain # exactly one hunk. To summarize: # # @diff == 1 # no changes since the presented serial number # @diff == 2 # AXFR-style IXFR # @diff > 2 # Normal IXFR containing changes # # Algorithm to interpret an IXFR courtesy of Mark Andrews @ISC, via # a quick and dirty awk script he posted to BIND Users. # Get ready to parse the result. my( @diff, $hunk, $items ); my $mode = '-'; for my $rr ( $result->answer ) { given( $rr->type ) { when( 'SOA' ) { push @$items, $rr; $mode = ( $mode eq '-' ? '+' : '-' ); $hunk = [ $mode, [] ]; $items = $hunk->[1]; push @diff, $hunk; } when( [ qw( RRSIG NSEC NSEC3 NSEC3PARAM ) ] ) { # Strip out DNSSEC records like this, as we can't really # do anything useful with them } when( 'TSIG' ) { # TODO: Add some error checking here # For now, strip these out also } default { # Anything else gets added to @$items push @$items, $rr; } } } # Discard the empty hunk from the end and return everything else pop @diff; return @diff; } Chris From jtk at cymru.com Wed Dec 19 02:38:52 2012 From: jtk at cymru.com (John Kristoff) Date: Tue, 18 Dec 2012 20:38:52 -0600 Subject: [net-dns-users] section RR counts read only Message-ID: <20121218203852.6ff2ffbb@localhost> I had some code that set qdcount, ancount, nscount and arcount in the header of a crafted Net::DNS message. Well, I was setting them and I assume it worked, but I hadn't tested it in awhile. I recently discovered that Net::DNS behavior changed between 0.68 and 0.69 that permits you to only now read these values. This isn't a big deal, but being able to set them, as I recall I was able to do anyway, was useful for seeing how various implementations would react. If it's not a big deal to bring back that functionality, it might come in handy. John From dwessels at verisign.com Tue Dec 18 21:42:56 2012 From: dwessels at verisign.com (Wessels, Duane) Date: Tue, 18 Dec 2012 13:42:56 -0800 Subject: [net-dns-users] IXFR methods In-Reply-To: <29B2FF62-FC99-4D15-AE73-205E491E7DFB@buxtonfamily.us> References: <29B2FF62-FC99-4D15-AE73-205E491E7DFB@buxtonfamily.us> Message-ID: <6D7B63CD-E125-49B6-9B6A-A2D3C53F19CA@verisign.com> Chris, Looks good, but I don't understand why you're discarding the DNSSEC types? Isn't it possible that the caller would want those records? DW On Dec 18, 2012, at 12:22 PM, Chris Buxton wrote: > Hello all, > > As Doug said, it's very nice to have a list. > > Has anyone else created an IXFR method for Net::DNS::Resolver? I have, and I think it's pretty good, but I think it could probably be improved. > > Here's my code -- requires perl 5.10 or later: > > # Hack IXFR capability into Net::DNS::Resolver > sub Net::DNS::Resolver::Base::ixfr($$$) > { > my( $res, $zone, $serial ) = @_; > local $_; > > # Send IXFR requests over TCP > $res->usevc(1); > > # Construct the request. It contains an abbreviated SOA record in > # the authority section, where the only fields that matter are name, > # class, type, and old serial number. > my $packet = new Net::DNS::Packet( $zone, 'IXFR' ); > my $soa = Net::DNS::RR->new( > name => $zone, > type => 'SOA', > mname => '', > rname => '', > serial => $serial, > refresh => 0, > retry => 0, > expire => 0, > minimum => 0 > ); > $packet->push( authority => $soa ); > > # Send the request and store the result in an array reference. > my $result = $res->send( $packet ); > > # The method here is, we're going to accumulate records into arrays > # of @$items, and then put those into @$hunks like [ $mode, $items > # ]. We then push each $hunk onto @diff. $mode will switch from '+' > # to '-' and back again for each new @$hunk. Therefore: > # > # @diff = ( > # [ $mode, [ $rr, ... ] ], > # ... > # ) > # > # Each @$hunk ends with an SOA record. Every time we encounter an > # SOA record, we start a new hunk right afterward (with the next > # record) and switch the $mode (the operator for each hunk). > # > # If you look carefully, you'll see that the very first SOA record > # is inserted into an empty @$items, but this @$items array doesn't > # get attached to @diff before being replaced with a fresh array. So > # we're processing it to set the $mode, but we're otherwise throwing > # it away. > # > # The last hunk (started after the final SOA record of the IXFR) has > # no records. Always. So we remove it before returning @diff. > # Therefore, an IXFR that requests changes since the current serial > # will return an empty array; an AXFR-style IXFR will contain > # exactly one hunk. To summarize: > # > # @diff == 1 # no changes since the presented serial number > # @diff == 2 # AXFR-style IXFR > # @diff > 2 # Normal IXFR containing changes > # > # Algorithm to interpret an IXFR courtesy of Mark Andrews @ISC, via > # a quick and dirty awk script he posted to BIND Users. > > # Get ready to parse the result. > my( @diff, $hunk, $items ); > my $mode = '-'; > > for my $rr ( $result->answer ) > { > given( $rr->type ) > { > when( 'SOA' ) > { > push @$items, $rr; > $mode = ( $mode eq '-' ? '+' : '-' ); > $hunk = [ $mode, [] ]; > $items = $hunk->[1]; > push @diff, $hunk; > } > when( [ qw( RRSIG NSEC NSEC3 NSEC3PARAM ) ] ) > { > # Strip out DNSSEC records like this, as we can't really > # do anything useful with them > } > when( 'TSIG' ) > { > # TODO: Add some error checking here > # For now, strip these out also > } > default > { > # Anything else gets added to @$items > push @$items, $rr; > } > } > } > > # Discard the empty hunk from the end and return everything else > pop @diff; > return @diff; > } > > Chris > _______________________________________________ > net-dns-users mailing list > net-dns-users at nlnetlabs.nl > https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users From calle at init.se Wed Dec 19 07:40:15 2012 From: calle at init.se (Calle Dybedahl) Date: Wed, 19 Dec 2012 08:40:15 +0100 Subject: [net-dns-users] List of API changes in versions after 0.68? Message-ID: <9C854D30-6286-4BE3-9DA6-D16016975FF7@init.se> Hi there. Is there a list somewhere of all the API changes in post-0.68 versions of Net::DNS? I've noticed two of them (what Net::DNS::RR::SOA->rname returns changed, and Net::DNS::RR->new($string) throws an exception instead of returning undef on failure), since they made our unit tests fail. I see here on the list that John Kristoff happened onto another (header count values aren't settable any longer). Which raises the suspicion that there are more of them. Is there a list somewhere of all API changes? There is a Changes file, but as far as I can see none of the three changes above are mentioned in it. The diff between releases 0.68 and 0.71 is almost 35000 lines, so reading that is not really viable. Note that I'm not arguing against any of the changes, I just want to know what they are, so I can adjust our code if necessary. -- Calle Dybedahl calle at init.se -*- +46 703 - 970 612 From willem at nlnetlabs.nl Wed Dec 19 09:39:58 2012 From: willem at nlnetlabs.nl (Willem Toorop) Date: Wed, 19 Dec 2012 10:39:58 +0100 Subject: [net-dns-users] List of API changes in versions after 0.68? In-Reply-To: <9C854D30-6286-4BE3-9DA6-D16016975FF7@init.se> References: <9C854D30-6286-4BE3-9DA6-D16016975FF7@init.se> Message-ID: <50D18B6E.5090501@nlnetlabs.nl> Hi Calle, I have tried to make such an overview (with Dick, for internal communication and archival purposes). It is not complete, but I believe it gives a good overview of the architectural choices with their argumentation and the accountability towards breaking backwards compatibility. I have it attached. I hope it can help you. The 0.69-0.71 releases have lead to a few good resolutions: * More releases with fewer changes * Better interaction with maintainers of other packages that critically depend on Net::DNS (this list is a result) I intend to post about future release candidates (developer releases) on this list to let you all evaluate a new release and give feedback. I also intent to inventory the packages using Net::DNS and attend them to the list. Best regards, -- Willem Op 19-12-12 08:40, Calle Dybedahl schreef: > Hi there. > > Is there a list somewhere of all the API changes in post-0.68 versions of Net::DNS? I've noticed two of them (what Net::DNS::RR::SOA->rname returns changed, and Net::DNS::RR->new($string) throws an exception instead of returning undef on failure), since they made our unit tests fail. I see here on the list that John Kristoff happened onto another (header count values aren't settable any longer). Which raises the suspicion that there are more of them. > > Is there a list somewhere of all API changes? There is a Changes file, but as far as I can see none of the three changes above are mentioned in it. The diff between releases 0.68 and 0.71 is almost 35000 lines, so reading that is not really viable. > > Note that I'm not arguing against any of the changes, I just want to know what they are, so I can adjust our code if necessary. > -------------- next part -------------- Architectural changes ===================== Resource record template ???????????????????????? Resource record interface is implemented using the following functions to facilitate conversions to and from string and wire format: ? decode_rdata ## decode rdata from wire?format byte string ? encode_rdata ## encode rdata as wire?format byte string ? format_rdata ## format rdata portion of RR string ? parse_rdata ## parse RR attributes in argument list Some of these functions may be omitted, the interface model then being completed by default implementations inherited from the RR base type. These functions loosely replace the previously required new, rr_rdata, new_from_string and rdatastr functions. If all interface functions are omitted, the RR is an unknown RRTYPE with implementation defined by RFC3597. The new functions provide (much clearer) separation of concerns. Note that in the old architecture, all RRs should be constructed via Net::DNS::RR::new() and new_from_string() functions of the type?specific subclass, which were not intended to be called directly. Additionally the functions _normalize_dnames and _canonicalRdata are no longer needed as they are now handled by the classes implementing the owner name and domain name rdata fields. Default values for rdata fields may be set with the optional defaults() function. This was provided for completeness, and intended to offer convenience when creating a new RR from a hash specification. ** Consequences RR.pm currently contains a compatibility layer which implements the "old" interface as methods which are inherited by the "new" architecture RR subtype modules. The compatibility layer is controlled by a configuration constant COMPATIBLE, which switches between the two RR subtype interfaces. This provides a useful method of testing if the transition plan actually works. There is no well defined relationship between releases of Net::DNS and Net::DNS::SEC, so one possible migration scenario would be to operate Net::DNS in compatible mode for some number of revisions. This will allow Net?DNS?SEC?0.16 and earlier to continue operating. Net?DNS? SEC?0.17 and later versions could then be implemented using the "new" interface, and operated using compatibility mode until such time as it is deemed appropriate to turn it off (when 0.16 becomes too old to use). Note that RRSIGs for wildcards, a feature that is in Net?DNS?SEC from the subversion trunk only and not in the releases, does not currently work with the new architecture. [I have only tested against 0.16, being the latest release ? RWF] Resource record owner names ??????????????????????????? RR owner names are represented internally by Net::DNS::DomainName1035 (compressible domain name) objects. This makes it possible, when Net::LibIDN is available, to construct RRs with Unicode owner names which will be represented in IDN A?label format. ** Consequences: This has no impact on backwards compatibility as the user only has access to Perl native strings. Conversions between character encodings occur (conceptually at least) somewhere close to the wire. You need to be aware that domain labels are stored in wire?format, which minimises the total number of conversions for the core functionality of resolving domain names. Other uses, zone file parsing and pretty printing for example, incur less favourable treatment, with two conversions where none might be expected. Resource record rdata domain name fields ???????????????????????????????????????? RDATA domain names are represented internally by Net::DNS::DomainName objects. This makes it possible, when Net::LibIDN is available, to construct RDATA containing Unicode domain names which will be represented in IDN A?label format. RR subtype modules which are subject to compression and/or downcasing requirements are implemented using Net::DNS::DomainName1035 and Net::DNS::DomainName2535 objects which specialise the base type by the substitution of a new encode() method. The list of modules affected appears in RFC3597 as amended. Canonicalisation of RR wire?format data is implemented by calling the RR subtype encode() method with an undefined value instead of the reference to the name compression hash. (Dick, for creating and verifying RRSIGs?) Yes, at least to the extent tested by Net::DNS::SEC test suite. ** Consequences: This has no impact on backwards compatibility as the user only has access to Perl native strings. Resource records with rdata fields containing text ?????????????????????????????????????????????????? Rdata fields containing text are represented internally by Net::DNS::Text objects. This allows text rdata fields to be constructed using the full Unicode character set. Affected rdata fields are: HINFO?>cpu, HINFO?>os, NAPTR?>flags, NAPTR?>service, NAPTR?>regexp and TXT?>txtdata. Of these, TXT is the only RR where Unicode text is likely to be used. ** Consequences: The relevent RFCs define text to be encoded on the wire using ASCII, which is a proper subset of the UTF8 encoding used by the Text module. The interpretation of non?ASCII character codes has never been defined, and presumably never (ab)used. There is therefore no impact on backwards compatibility. Text rdata fields will return a standard Perl string using the internal encoding appropriate for the platform. Characters which cannot otherwise be represented will be expressed as RFC1035 numeric escape sequences. Resource records with rdata fields containing mailboxes ??????????????????????????????????????????????????????? Mailboxes rdata fields are represented internally by Net::DNS::Mailbox objects and can now be constructed with the mailbox name in RFC822 format; i.e. user at domain or name. Affected rdata fields are: MINFO?>rmailbx, MINFO?>emailbx, RP?>mbox and SOA?>rname. RFC1035 defines the encoding method to be used for mail addresses and therefore responsibility for such encoding/decoding should lie with Net::DNS and not be devolved to the user. ** Consequences: Those rdata fields will now return the email box in RFC822 format. This is a difference that we are willing to accept because of the enrichment it provides for the type. The "old" encoded form is also accepted when modifying these fields. The packet header incorporates EDNS0 ???????????????????????????????????? Header extensions provided by the EDNS0 OPT resource record are now accessible transparently through the $packet?>header interface. This includes the DO flag, extended response codes and UDP packet size. Directly accessing opt?>class or opt?>ttl functions now triggers a warning (once) advising the use of the appropriate function instead. ** Consequences: Net::DNS::Header now needs to be associated with a Net::DNS::Packet and must not be constructed independently any more. The quantity attributes qdcount, ancount, nscount and arcount (or their dynamic update counterparts) now return the number of RRs in the addressed section. As a consequence they can not be set directly. For a decoded packet, the counter value is derived from the packet header and may differ from the actual number of RRs in the corresponding section if a decoding error occurred. However, for a newly constructed packet, the header count reflects the current length of the section. DNS parameters in separate module ????????????????????????????????? The DNS parameters are now also provided in a separate module Net::DNS::Parameters. This file will (in the future) automatically be generated from the authoritative resource at IANA: http://www.iana.org/assignments/dns?parameters/dns?parameters.xml Net::DNS internally uses Net::DNS::Parameters for all dns parameters, but they are also still present in DNS.pm for backwards compatibility. This change also removes the circularities present in the module dependency "tree" which results in unnecessary multiple compilation of some modules. It now really _is_ a tree. ** Consequences: The name of opcode 4 is altered from NS_NOTIFY_OP to NOTIFY. This pulls the code into line with the opcode registry but will break backwards compatibility. Dick, Should we change this back and put it on the wish list for a more major version update? No, I think not; we should regard the IANA registry as the definitive source of mnemonics. As this occurs in both forward and reverse tables, there is no backward compatibility workaround that will please everyone. Users are likely to respond positively if we are seen to be tying ourselves to published standards which will offer them long?term stability albeit incurring a small one?off inconvenience. We are very lucky that this appears to be the only inconsistent mnemonic. Packet decoding errors ?????????????????????? Packet decoding errors are now collected in the $@ ($EVAL_ERROR) variable. Before the error message was returned in the second item of the array returned when construction a Net::DNS::Packet in array context. Now that second argument contains the number of octets successfully decoded. This makes packet decoding more robust and gives more refined control over the decoding process (by returning a pointer to potentially uninterpreted data). ** Consequences: We believe it is safe because requesting an error message before also required a test for the returned packet to be defined (i.e. not undef). This behaviour is backwards compatible. The only thing different is the error message which is now in $@. In the worst case a number will be printed as an error message. Exception-based error handling schemes can now be supported simply by adding 'die if $@' to propagate the exception. The entire packet is now decoded immediately; the previous deferred decoding scheme has been abandoned. As a consequence, no exceptions will be raised for decoding errors during calls to the packet->answer and similar methods. This was a design response to the problem of determining the length of a decoded packet encountered by Mark Andrews. Upgradable aplists in APL RRs ????????????????????????????? APL RRs now allow for gradually appending (negate,family)address/prefix items. ** Consequences: Net::DNS::RR::APL::ApItem is replaced with Net::DNS::RR::APL::Item that cannot be constructed independently. It is unlikely (and not the intention) that people ever used Net::DNS::RR::APL::ApItem directly. Therefore we believe it is safe. From rwfranks at acm.org Wed Dec 19 15:14:06 2012 From: rwfranks at acm.org (Dick Franks) Date: Wed, 19 Dec 2012 15:14:06 +0000 Subject: [net-dns-users] IXFR methods In-Reply-To: <6D7B63CD-E125-49B6-9B6A-A2D3C53F19CA@verisign.com> References: <29B2FF62-FC99-4D15-AE73-205E491E7DFB@buxtonfamily.us> <6D7B63CD-E125-49B6-9B6A-A2D3C53F19CA@verisign.com> Message-ID: On 18 December 2012 21:42, Wessels, Duane wrote: > > Looks good, but I don't understand why you're discarding the DNSSEC types? Isn't it > possible that the caller would want those records? I agree, to be useful it should provide everything that AXFR would provide. > On Dec 18, 2012, at 12:22 PM, Chris Buxton wrote: >> Has anyone else created an IXFR method for Net::DNS::Resolver? [snip] Is this intended as an idea to be integrated into Net::DNS itself? >> Here's my code -- requires perl 5.10 or later: Why 5.10? If it is to be part of Net::DNS, it will need to be portable to all revisions back to 5.6.1. (note that 0.69 and 0.70 tickled Perl bugs in 5.8.5 .. 5.8.8, and quite possibly 5.8.3 and 5.8.4 also) If not, then it *must* be renamed to something which does not conflict with Net::DNS namespace. As a general principle, user code should only use the methods as described in the documentation, and refrain from direct access to any internal data structures or defining additional methods. That said, creative solutions to real problems are always welcomed, and may result in an extension of the API and/or revised documentation. Dick -- From rwfranks at acm.org Wed Dec 19 15:31:10 2012 From: rwfranks at acm.org (Dick Franks) Date: Wed, 19 Dec 2012 15:31:10 +0000 Subject: [net-dns-users] section RR counts read only In-Reply-To: <20121218203852.6ff2ffbb@localhost> References: <20121218203852.6ff2ffbb@localhost> Message-ID: On 19 December 2012 02:38, John Kristoff wrote: > I had some code that set qdcount, ancount, nscount and arcount in the > header of a crafted Net::DNS message. Well, I was setting them and I > assume it worked, but I hadn't tested it in awhile. I recently > discovered that Net::DNS behavior changed between 0.68 and 0.69 that > permits you to only now read these values. > > This isn't a big deal, but being able to set them, as I recall I was > able to do anyway, was useful for seeing how various implementations > would react. If it's not a big deal to bring back that functionality, it > might come in handy. It should *never* come in handy! If the packet arrived on the wire, the counts are set from the header which, in the absence of corruption or truncation, will be identical to the number of RRs in the corresponding section. For packets not decoded from the wire, the count is obtained from the size of the relevant section and automatically tracks any changes of the contents. If you do attempt to change ancount etc., the request will fail silently. (This is to avoid upsetting some of the Net::DNS::SEC modules, which still follow the old model). Dick -- From rwfranks at acm.org Wed Dec 19 16:45:03 2012 From: rwfranks at acm.org (Dick Franks) Date: Wed, 19 Dec 2012 16:45:03 +0000 Subject: [net-dns-users] List of API changes in versions after 0.68? In-Reply-To: <9C854D30-6286-4BE3-9DA6-D16016975FF7@init.se> References: <9C854D30-6286-4BE3-9DA6-D16016975FF7@init.se> Message-ID: On 19 December 2012 07:40, Calle Dybedahl wrote: > Is there a list somewhere of all the API changes in post-0.68 versions of Net::DNS? I've noticed two of them (what Net::DNS::RR::SOA->rname returns changed, rname is supposed to be a mailbox address, and RFC1035 defines the transformation to/from a domain name. I took the view that the interface to the user should be RFC822 syntax on the basis that Net::DNS should encompass everything that RFC1035 requires, and not leave arbitrary bits of it for the user to sort out himself. > and Net::DNS::RR->new($string) throws an exception instead of returning undef on failure), since they made our unit tests fail. Failure to create an RR at all (as distinct from one with no valid RDATA) is usually an irrecoverable error. The exception based model relieves the user of testing the returned object reference after every new() call, and provides the information needed to discover what went wrong. The old model left the user with no information at all. I see here on the list that John Kristoff happened onto another (header count values aren't settable any longer). Which raises the suspicion that there are more of them. The present code base was tested against the same set of test script as 0.68 and passed with only minor discrepancies which mostly arose from problems with the tests themselves. This was done on the assumption that the key elements of the API would be tested, and therefore if it passed, the API would be the same or acceptably close to the original. Perhaps that was too optimistic a view. > Is there a list somewhere of all API changes? There is a Changes file, but as far as I can see none of the three changes above are mentioned in it. The diff between releases 0.68 and 0.71 is almost 35000 lines, so reading that is not really viable. The bulk of that lies in the RR subtype implementations and either do the same as they did before, or what the relevant RFCs say that they should have done before. The handling of mailbox attributes is the only significant departure. > Note that I'm not arguing against any of the changes, I just want to know what they are, so I can adjust our code if necessary. Willem has already posted an explanation of the reasoning behind some of the changes. One area of the API which "looks the same" but behaves differently, is the use of new() with named arguments. The attribute names are treated as object method names and called with the specified argument. The user no longer has direct access to the hash which gets blessed as an RR object. Also, in many cases the internal data structure is radically different, which will break code which accesses the internal data. But you never do that, do you? Dick -- From clists at buxtonfamily.us Wed Dec 19 17:20:33 2012 From: clists at buxtonfamily.us (Chris Buxton) Date: Wed, 19 Dec 2012 09:20:33 -0800 Subject: [net-dns-users] IXFR methods In-Reply-To: References: <29B2FF62-FC99-4D15-AE73-205E491E7DFB@buxtonfamily.us> <6D7B63CD-E125-49B6-9B6A-A2D3C53F19CA@verisign.com> Message-ID: <0A422CB2-7975-49D0-8783-4F3E84470CCE@buxtonfamily.us> On Dec 19, 2012, at 7:14 AM, Dick Franks wrote: > On 18 December 2012 21:42, Wessels, Duane wrote: >> >> Looks good, but I don't understand why you're discarding the DNSSEC types? Isn't it >> possible that the caller would want those records? > > I agree, to be useful it should provide everything that AXFR would provide. I did this because my specific use case did not need these records. But for a more general solution, I should not do that. I'll fix it, and then update the code that calls it to ignore DNSSEC and TSIG records. >> On Dec 18, 2012, at 12:22 PM, Chris Buxton wrote: > >>> Has anyone else created an IXFR method for Net::DNS::Resolver? > [snip] > > Is this intended as an idea to be integrated into Net::DNS itself? That would be great, once the code is better. >>> Here's my code -- requires perl 5.10 or later: > > Why 5.10? Because I use that as a base version for most of my code. In this case, it uses given/when and ~~, neither of which are available in 5.8. Again, this can be fixed. > If it is to be part of Net::DNS, it will need to be portable to all > revisions back to 5.6.1. > (note that 0.69 and 0.70 tickled Perl bugs in 5.8.5 .. 5.8.8, and > quite possibly 5.8.3 and 5.8.4 also) I don't have any idea what changed between 5.6.1 and 5.8. Are there any other parts of the method that would need to be fixed to work with 5.6.1? > If not, then it *must* be renamed to something which does not conflict > with Net::DNS namespace. > > As a general principle, user code should only use the methods as > described in the documentation, and refrain from direct access to any > internal data structures or defining additional methods. > That said, creative solutions to real problems are always welcomed, > and may result in an extension of the API and/or revised > documentation. I disagree. Splicing the method onto the Net::DNS::Resolver class, for my own use, gives me much cleaner code elsewhere. I started this discussion with the hope that the code could be improved and eventually accepted as an addition to the Net::DNS::Resolver class, or else replaced by something better that does the same thing. Chris From rwfranks at acm.org Wed Dec 19 18:54:34 2012 From: rwfranks at acm.org (Dick Franks) Date: Wed, 19 Dec 2012 18:54:34 +0000 Subject: [net-dns-users] IXFR methods In-Reply-To: <0A422CB2-7975-49D0-8783-4F3E84470CCE@buxtonfamily.us> References: <29B2FF62-FC99-4D15-AE73-205E491E7DFB@buxtonfamily.us> <6D7B63CD-E125-49B6-9B6A-A2D3C53F19CA@verisign.com> <0A422CB2-7975-49D0-8783-4F3E84470CCE@buxtonfamily.us> Message-ID: On 19 December 2012 17:20, Chris Buxton wrote: > Because I use that as a base version for most of my code. In this case, it uses given/when and ~~, neither of which are available in 5.8. Again, this can be fixed. > >> If it is to be part of Net::DNS, it will need to be portable to all >> revisions back to 5.6.1. >> (note that 0.69 and 0.70 tickled Perl bugs in 5.8.5 .. 5.8.8, and >> quite possibly 5.8.3 and 5.8.4 also) > > I don't have any idea what changed between 5.6.1 and 5.8. Lots. especially character coding and string handling which is a minefield for the unwary. Are there any other parts of the method that would need to be fixed to work with 5.6.1? I did not spot anything. >> If not, then it *must* be renamed to something which does not conflict >> with Net::DNS namespace. >> >> As a general principle, user code should only use the methods as >> described in the documentation, and refrain from direct access to any >> internal data structures or defining additional methods. >> That said, creative solutions to real problems are always welcomed, >> and may result in an extension of the API and/or revised >> documentation. > > I disagree. Splicing the method onto the Net::DNS::Resolver class, for my own use, gives me much cleaner code elsewhere. Maybe convenient for you, but it risks breaking Net::DNS resolver code which is absolutely unacceptable. Ask yourself how we could debug or explain an apparent Net::DNS failure induced by your code making unsolicited additions into our code. > I started this discussion with the hope that the code could be improved and eventually accepted as an addition to the Net::DNS::Resolver class, or else replaced by something better that does the same thing. I am fairly warm to the idea of adding IXFR to Net::DNS. Please raise a CPAN RT bug report requesting the IXFR function to be added to Net::DNS (wish list). Just a one-liner will do; we can discuss code at some later date. Dick -- From calle.dybedahl at init.se Thu Dec 20 07:29:37 2012 From: calle.dybedahl at init.se (Calle Dybedahl) Date: Thu, 20 Dec 2012 08:29:37 +0100 Subject: [net-dns-users] section RR counts read only In-Reply-To: References: <20121218203852.6ff2ffbb@localhost> Message-ID: <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se> On 19 dec 2012, at 16:31, Dick Franks wrote: > It should *never* come in handy! > > If the packet arrived on the wire, the counts are set from the header > which, in the absence of corruption or truncation, will be identical > to the number of RRs in the corresponding section. You're making assumptions about how people will want to use your module, and by doing so unnecessarily limiting what it can be used for. We have, for example, written small DNS servers in Perl specifically to respond to queries with packets that were broken in ways ordinary nameservers couldn't be configured to produce, for testing and investigation purposes. If Net::DNS had prevented us from creating those packets, that would have been extremely frustrating and in the best case caused us a lot of unnecessary work. In the worst case it would have prevented us entirely from doing what we wanted to do. I'm reminded of this old quote from Larry Wall: "Usenet was not designed to stop you from saying stupid things, because that would also stop me from saying clever things." -- Calle Dybedahl calle at init.se -*- +46 703 - 970 612 From rwfranks at acm.org Thu Dec 20 12:19:16 2012 From: rwfranks at acm.org (Dick Franks) Date: Thu, 20 Dec 2012 12:19:16 +0000 Subject: [net-dns-users] section RR counts read only In-Reply-To: <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se> References: <20121218203852.6ff2ffbb@localhost> <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se> Message-ID: On 20 December 2012 07:29, Calle Dybedahl wrote: > You're making assumptions about how people will want to use your module, and by doing so unnecessarily limiting what it can be used for. I am making the assumption that end users want what Net::DNS claims to provide: Perl interface to the Domain Name System. The internal components like Header.pm exist to facilitate that primary mission. Injecting corrupt packets into the global DNS is a violation of the relevant standards; the design should, where possible, minimise that risk. > I'm reminded of this old quote from Larry Wall: > "Usenet was not designed to stop you from saying stupid things, because that would also stop me from saying clever things." Larry said nothing about breaking usenet. DIck -- From olaf at NLnetLabs.nl Thu Dec 20 13:42:59 2012 From: olaf at NLnetLabs.nl (Olaf Kolkman) Date: Thu, 20 Dec 2012 14:42:59 +0100 Subject: [net-dns-users] section RR counts read only In-Reply-To: References: <20121218203852.6ff2ffbb@localhost> <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se> Message-ID: On Dec 20, 2012, at 1:19 PM, Dick Franks wrote: > On 20 December 2012 07:29, Calle Dybedahl wrote: >> You're making assumptions about how people will want to use your module, and by doing so unnecessarily limiting what it can be used for. > > I am making the assumption that end users want what Net::DNS claims to > provide: Perl interface to the Domain Name System. > > The internal components like Header.pm exist to facilitate that > primary mission. Injecting corrupt packets into the global DNS is a > violation of the relevant standards; the design should, where > possible, minimise that risk. > I agree with the primary mission and that the primary mission is first consideration. However, IMHO there is a bonafide secondary mission. Therefore we should not make it impossible for people that have a genuine requirement for injecting corrupt packets to the wire (e.g. for testing, troubleshooting, and other usefulness). So I wouldn't want us to dismiss that angle to easily. --Olaf NLnet Labs Olaf M. Kolkman www.NLnetLabs.nl olaf at NLnetLabs.nl Science Park 400, 1098 XH Amsterdam, The Netherlands -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtk at cymru.com Thu Dec 20 14:21:25 2012 From: jtk at cymru.com (John Kristoff) Date: Thu, 20 Dec 2012 08:21:25 -0600 Subject: [net-dns-users] section RR counts read only In-Reply-To: References: <20121218203852.6ff2ffbb@localhost> <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se> Message-ID: <20121220082125.04689492@localhost> On Thu, 20 Dec 2012 12:19:16 +0000 Dick Franks wrote: > I am making the assumption that end users want what Net::DNS claims to > provide: Perl interface to the Domain Name System. I am an end user and I would actually prefer to have just what I originally and Calle most eloquently described. > The internal components like Header.pm exist to facilitate that > primary mission. Injecting corrupt packets into the global DNS is a > violation of the relevant standards; the design should, where > possible, minimise that risk. I fail to see how this facilitates any attempt to corrupt the system. A low level interface, even an undocumented one if you insist, that enables the developer to test and observe otherwise unexpected behavior hardly seems to be much of a risk here, but rather quite handy. Thanks for listening, John From rwfranks at acm.org Thu Dec 20 15:58:49 2012 From: rwfranks at acm.org (Dick Franks) Date: Thu, 20 Dec 2012 15:58:49 +0000 Subject: [net-dns-users] section RR counts read only In-Reply-To: References: <20121218203852.6ff2ffbb@localhost> <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se> Message-ID: IMHO the secondary mission would be better served by a separate purpose-built test tool distribution, driven by users who need it, and which would not be routinely redistributed as part of general purpose Linux distributions. This could be built by using most of the standard Net::DNS components, but with provision to inject corruptions in a controlled manner. Most of the task could be achieved by a modified version of Packet.pm plus a little ingenuity. Net::DNS::TestKit ? I am not volunteering to write it, but if anyone wishes to pursue the idea, I will be happy to help get it started. Dick -- On 20 December 2012 13:42, Olaf Kolkman wrote: > > On Dec 20, 2012, at 1:19 PM, Dick Franks wrote: > > On 20 December 2012 07:29, Calle Dybedahl wrote: > > You're making assumptions about how people will want to use your module, > and by doing so unnecessarily limiting what it can be used for. > > > I am making the assumption that end users want what Net::DNS claims to > provide: Perl interface to the Domain Name System. > > The internal components like Header.pm exist to facilitate that > primary mission. Injecting corrupt packets into the global DNS is a > violation of the relevant standards; the design should, where > possible, minimise that risk. > > > I agree with the primary mission and that the primary mission is first > consideration. > > However, IMHO there is a bonafide secondary mission. Therefore we > should not make it impossible for people that have a genuine requirement > for injecting corrupt packets to the wire (e.g. for testing, > troubleshooting, and other usefulness). So I wouldn't want us to dismiss > that angle to easily. > > > > --Olaf > > > > > > *NLnet > *Labs > Olaf M. Kolkman > > www.NLnetLabs.nl > olaf at NLnetLabs.nl > > Science Park 400, 1098 XH Amsterdam, The Netherlands > > > > > _______________________________________________ > 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: From jtk at cymru.com Thu Dec 20 16:22:17 2012 From: jtk at cymru.com (John Kristoff) Date: Thu, 20 Dec 2012 10:22:17 -0600 Subject: [net-dns-users] section RR counts read only In-Reply-To: References: <20121218203852.6ff2ffbb@localhost> <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se> Message-ID: <20121220102217.779e40a5@localhost> On Thu, 20 Dec 2012 15:58:49 +0000 Dick Franks wrote: > This could be built by using most of the standard Net::DNS > components, but with provision to inject corruptions in a controlled > manner. Most of the task could be achieved by a modified version of > Packet.pm plus a little ingenuity. > > Net::DNS::TestKit ? Sounds reasonable to me. Shall I submit it as a wish list item in cpan? John From fenghe at nsbeta.info Sat Dec 22 10:27:05 2012 From: fenghe at nsbeta.info (Feng He) Date: Sat, 22 Dec 2012 18:27:05 +0800 Subject: [net-dns-users] How to translate the email in SOA In-Reply-To: <20121220102217.779e40a5@localhost> References: <20121218203852.6ff2ffbb@localhost> <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se> <20121220102217.779e40a5@localhost> Message-ID: <1419291356172025@web18h.yandex.ru> Hi, To translate an email address into SOA format I can use Net::DNS::Mailbox. But translating from the SOA to a regular email address, what module will we use? I currently use my own subroutine: sub restore_email_from_soa { my $email = shift; $email =~ s/\.$//; if ($email =~ /^(.*?)(? References: <20121218203852.6ff2ffbb@localhost> <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se> <20121220102217.779e40a5@localhost> <1419291356172025@web18h.yandex.ru> Message-ID: <168131356173141@web6f.yandex.ru> I am sorry that Net::DNS::Mailbox does nothing what I thought. For translating an email address into SOA I have to write a subroutine like: sub format_email_for_soa { my $self = shift; my $email = shift; my ($user,$tld) = split/\@/,$email; $user =~ s/\./\\./g; $user. '.' .$tld . '.'; } Do these have any problem? Thanks. 22.12.2012, 18:27, "Feng He" : > Hi, > > To translate an email address into SOA format I can use Net::DNS::Mailbox. > But translating from the SOA to a regular email address, what module will we use? > > I currently use my own subroutine: > > sub restore_email_from_soa { > > ????my $email = shift; > ????$email =~ s/\.$//; > > ????if ($email =~ /^(.*?)(? ????????my $user = $1; > ????????my $tld = $2; > ????????$user =~ s/\\//g; > ????????return $user . '@'. $tld; > ?????} > } > > Im not sure if it suits all the conditions. > > Thanks. From rwfranks at acm.org Sat Dec 22 13:39:10 2012 From: rwfranks at acm.org (Dick Franks) Date: Sat, 22 Dec 2012 13:39:10 +0000 Subject: [net-dns-users] How to translate the email in SOA In-Reply-To: <168131356173141@web6f.yandex.ru> References: <20121218203852.6ff2ffbb@localhost> <361784E6-632C-4699-8CA8-A9ED22CC7B6A@init.se> <20121220102217.779e40a5@localhost> <1419291356172025@web18h.yandex.ru> <168131356173141@web6f.yandex.ru> Message-ID: On 22 December 2012 10:45, Feng He wrote: > I am sorry that Net::DNS::Mailbox does nothing what I thought. Net::DNS::Mailbox is an internal component which is not designed to be used by end users. > For translating an email address into SOA I have to write a subroutine like: There is no need to do that! If you use Net::DNS 0.69 or later, all the conversions are done for you. #!/usr/bin/perl -w use Net::DNS 0.69; my $resolver = new Net::DNS::Resolver(); my $example = 'nsbeta.info'; my $reply = $resolver->send( $example, 'SOA' ) || die; my ($soa) = grep { $_->type eq 'SOA' } $reply->answer; $soa->print; print "RNAME mailbox: ", $soa->rname, "\n"; my $different = 'john.doe at example.com'; print "\n\nchanged RNAME: ", $soa->rname($different), "\n\n"; $soa->print; exit; From Willem at NLnetLabs.nl Mon Dec 24 21:51:28 2012 From: Willem at NLnetLabs.nl (Willem Toorop) Date: Mon, 24 Dec 2012 22:51:28 +0100 Subject: [net-dns-users] Release candidate for Net::DNS 0.72 Message-ID: <50D8CE60.6070605@NLnetLabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, We have a Net::DNS 0.71_01 developers release which is a release candidate for Net::DNS 0.72. This is a minor bugfix release. It resolves some issues with TSIG introduced since the 0.69 release. For details see Changes below. Please let us know if anything is wrong. If all is well, given the few changes, I believe it is safe to do the actual 0.72 release on short notice. Say next Friday. Merry Christmas, Willem Toorop link: http://www.net-dns.org/download/Net-DNS-0.71_01.tar.gz sha1: 4b57f967610d4a1bc6ba82e40c58f25794293ebb Changes: ======== Fix rt.cpan.org #82148 nxrrset fails to ignore RDATA. Fix rt.cpan.org #82134 TSIG key and algorithm names not downcased in digest. Class not forced to ANY. Fix rt.cpan.org #82063 yxrrset, nxrrset and rr_del functions should force zero TTL. Fix rt.cpan.org #82047 Clarify documentation to indicate that header counts may differ from the number of RRs present if a packet is corrupt. Fix rt.cpan.org #81941 Clarify documentation to make clear that bgread will not switch to TCP when a truncated packet is received. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ2M5aAAoJEOX4+CEvd6SYsHAP/1CS/eH5wfFulD7/XLk8o+4O wMV4SDG8g8K5xsQ6pWOEHPZLKlFJLF2h7UXZgMKE+3rq6u1Bco0MBiE15vt4+cOF hZ991io/OET/5Fddl2SMWTQcqw1hohypTZEm8nX9kwFrYuO/qffdpbhk0F5HhW3i NPUh0COgqwC6pAjm2fsH1hFzeHvWNyKMpa16zgZHUNe71sCzhcLx0MvUdhQI4rLy UCuHtLD4cBhv26ItJ/syV1VlLSgALYkIN7Xy0Sg0oLeG+EYjWDhEJEJ8UtS5+XR5 SRSKPBQpgCSC/Gmjwn2wJVw0KU45PUGUVYxJvLhnfE5JtMqVY4NlrqPPnRjq2ETp VyAj7Sz5d9GB182cQZfVk3mDBoPXPD1gUaU/bCUl6Pdd7Am8aUV3FCi1Nwdl3C48 LFY42dcUFlLICgSrJnfbkzTIVGISnT9Nr22TFg6v0Jiscj0bhCVuRF4URZSAQIWM 4Pu9nQXE4DTpR0TD37D3E+KoRDPy2r8htaqDw1Bqp3wrQWw4VzKdIhb/FP596uDE Z5Ru8zLFmR0DejaxFZULM1debRLSKK3cX9yVFGCHm82+k5PpKFxRJX7gvb9qMyZz gMv3S2djOq6Kw5i/nkGqX4x93OqqJF6ITh+L/2mBQD69tqX1TCkYrYGIgz5OWC14 ofE5agECaMSrSwirPKvd =CoaS -----END PGP SIGNATURE----- From willem at nlnetlabs.nl Fri Dec 28 15:25:00 2012 From: willem at nlnetlabs.nl (Willem Toorop) Date: Fri, 28 Dec 2012 16:25:00 +0100 Subject: [net-dns-users] Net::DNS 0.72 released Message-ID: <50DDB9CC.2030708@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am pleased to announce version 0.72 of Net::DNS. This is a minor bugfix release. It resolves some issues with TSIG introduced since the 0.69 release. For details see Changes below. Best regards, Willem Toorop link: http://www.net-dns.org/download/Net-DNS-0.72.tar.gz sha1: b55801c7c467d47752558df34fcd93f602c9e56d Changes ======= **** 0.72 Dec 28, 2012 Fix rt.cpan.org #82148 nxrrset fails to ignore RDATA. Fix rt.cpan.org #82134 TSIG key and algorithm names not downcased in digest. Class not forced to ANY. Fix rt.cpan.org #82063 yxrrset, nxrrset and rr_del functions should force zero TTL. Fix rt.cpan.org #82047 Clarify documentation to indicate that header counts may differ from the number of RRs present if a packet is corrupt. Fix rt.cpan.org #81941 Clarify documentation to make clear that bgread will not switch to TCP when a truncated packet is received. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQ3bnMAAoJEOX4+CEvd6SYua8P/iyAeDX/pj3IusJcIHhT4GGv a2MC+6YjEKfj1TvOXE+G33g+134eMiM7gL+hISbs4lBnWrA6a6be+mri41Va9j/A sDwEaKleYw2djeG6Q8nAaOD9NwCTBYACWMhQUEVk2t0E1Qt8AqATG/hckiFewbVP wYZhDamzPzAyG5lIMPR1LfSW9NhyyCk2jZU15cq4lD73HLHcgsN37GX3PO5bated UdOSNAZiuRGs9lDVv13/kMHUPJNxNxwhoWaM+pBLO6DgZ/YKxR90/lLglmfuSe0S BzDU/AcR5XkOZlGaRXK/3tRi5e/UFIipodbZUPvwEXP6w3ak7KTWQ9BStU4L1nAT CiPmCPh3mlbEDWh3qp7WZ29Tq7sFeOVyslB6xMwLr+Tor3zK9pmVc5fm57tAlRpV 3T8pXMx9DjxQhoVVYUB/zERGpFEW+nhhWQRq9Mgam7Hn0PqBG6HvaFoQAK1TsDnL dEdVMCFuWSGFvxE9B+leYHYMblWqcY73zSprM4ZnI96HRE4ObhWGfGtkT1IPSkue lQIsHqpwJEp3XObn6MeUf1erEDb2w1IQyAAWYfWAMo1JsH2CQbY1rZoaQNxZfRyt mLW1mGWmvdh6AeWUfCQd8v7VZDYlW6YpzucQ9fz3NooJtzvq4rl/7xVMwMn2AzBn 61jGVDqSvpC/r7ckpiQb =rb09 -----END PGP SIGNATURE-----