Re: [dns-operations] reopening discussion of stalled i-d: draft-ietf-dnsop-edns-chain-query
Paul Vixie p...@redbarn.org wrote: Tony Finch mailto:d...@dotat.at Sunday, November 30, 2014 6:26 AM You can do that with the current DNS protocol: just send all the queries and wait for all the replies. (This is particularly easy over TCP.) There's no need for more than one round trip in most cases, or maybe two if the answer involves CNAME/MX/SRV etc. so, you're willing to send a query for every ancestor domain, even the ones that turn out not to be zone cuts. That will usually be only one, and the server will have to send back a proof of no zone cut whether you ask for it separately or as part of a bulk query. you're also willing to transmit microburst UDP, or to depend on RDNS servers having effectively unlimited TCB capacity. i am not hip to any of that. Those are fair complaints. However your initial reason was latency, but chain queries do not improve latency compared to the current protocol. And chain queries will often require TCP so your TCB complaint applies to them as well. (And if you start with UDP and have to do a TCP fallback you lose the latency benefits.) Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Lundy, Fastnet, Irish Sea: Variable 4, becoming north 5 to 7, perhaps gale 8 later. Slight or moderate, occasionally rough later. Fair then rain. Good, occasionally poor. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
On Sun, Nov 30, 2014 at 02:29:15PM -0800, Paul Vixie wrote: Doug Barton mailto:do...@dougbarton.us Sunday, November 30, 2014 1:21 PM ... We still need a way to verify the entire contents of the zone however. This goes beyond just transfers, it would be nice to be able to verify that a zone downloaded using a method other than transfers is both accurate and complete. why? (your use case is not obvious from what you've written.) are you trying to ensure that errors that creep by TCP's error checking or that result from silent sending-side failures where both the starting and ending SOA are present but the middle is corrupt? or are you trying to ensure that a tertiary server can't be lied to by its secondary server? Silent on-disk corruption. It happens, and it would be nice to be able to detect that. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Looking for a public blackhole/sinkhole IP address
Not replying to anyone in particular Wouldn't it be possible to pick an address on your own network (perhaps in your DMZ) and then create rules on any firewall in front of that address that simply drops all packets? If a public address were announced, why not have an outbound firewall rule to drop the traffic? I suppose this may not scale to major ISPs/backbone carriers however. -- William Brown Messaging Team Technology Services, WNYRIC, Erie 1 BOCES Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] Reminder: Workshop on DNS Future Root Service Architecture, Hong Kong, December 8-9, 2014
Hi all, A reminder that, if you are coming to the Workshop on DNS Future Root Service Architecture, Hong Kong, December 8-9, 2014 meeting to please let Paul Vixie p...@redbarn.org or myself Warren Kumari war...@kumari.net know. We have a room block at venue hotel. To reserve a room in this block, visit the URL shown below: https://bookings.ihotelier.com/The-Mira-Hong-Kong/bookings.jsp?hotelID=85171groupID=1333820 If you have reserved a room at the conference hotel, *and did not use the signup link*, please let us know, so we can associate you with our room block[0]. Participants are invited to submit proposals for several open slots, with final selection to be made during the workshop itself. The current agenda: Monday: 0900-0910: Welcome from ISOC-HK (local host) 0910-0915: Welcome from ZDNS/BII (sponsor) 0915-0920: Welcome from CNNIC (sponsor) 0920-0930: Logistics and late agenda changes (co-chairs) 0930-0945: Current problem statement (co-chairs) 0945-1030: Decreasing Access Time to Root Servers by Running One on Loopback (W. Kumari, P. Hoffman) (present current draft, field questions and objections, propose text or logic revisions) 1030-1100: Break (coffee) 1100-1145: How to scale the DNS root system? (X. Li, P. Vixie) (present current draft, field questions and objections, propose text or logic revisions) 1145-1230: Open discussion of the two drafts, with expected refinements to the problem statement 1230-1400: Lunch (hosted) 1400-1430: Testbed for IPv6-only DNS development (Dr. Linjian Song, BII Lab) 1430-1500: Evolution of DNS root zone operation and management (Dr. Declan Ma, ZDNS Lab) 1500-1530: Offering DNS root zone on unmanaged anycast: comparisons with AS112 (Paul Hoffman) 1530-1600: Integrity protection for entire zones (Presented TBD) 1600-1700: Open (proposals welcome, workshop participants to decide in the moment) 1700-1900: (Unscheduled private time) 1900-2200: Dinner (hosted) Tuesday: 0900-0930: Summary of day 1, new issues, closed issues, opened issues (co-chairs) 0930-1030: Summary of changes to text of Internet Drafts accepted during workshop 1030-1100: Break (coffee) 1100-1230: Open (proposals welcome, workshop participants to decide in the moment) 1230-1400: Lunch (hosted) Thank you, and sorry for the interruption. W -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] cool idea regarding root zone inviolability
Paul Vixie mailto:p...@redbarn.org Sunday, November 30, 2014 2:29 PM why? (your use case is not obvious from what you've written.) ... Chuck Anderson mailto:c...@wpi.edu Monday, December 01, 2014 7:09 AM Silent on-disk corruption. It happens, and it would be nice to be able to detect that. if you're concerned about operating system or hardware or network errors, then i assume you're also concerned about them hitting your name server executable, in which case you'll be running a file system like ZFS that catches these things. if you're concerned about malevolent on-disk editing, then i assume you're running something like tripwire to snapshot with secure hashes every file in your operating system, and that it will have hooks to manage and monitor the zone files as well. either way i'm not seeing a unique has to be done with an in-zone signature situation here. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Assuring the contents of the root zone
Paul Hoffman mailto:paul.hoff...@vpnc.org Monday, December 01, 2014 3:48 PM People have asked for two things: 1) Getting the root zone by means other than AXFR, such as by HTTP 2) Being sure that they got the exact root zone, including all of the glue records i think you meant zone not root zone here. A signed hash meets (2) regardless of how the zone was transmitted. not inevitably. the verification tool would be new logic, either built into the secondary name server, or as an outboard tool available to the transfer mechanism. when i compare the complexity-cost of that tool to the contents of the ftp://ftp.internic.net/domain directory, i see that existing tools whose complexity-cost i already pay would work just fine. (those being pgp and md5sum). so, a detached signature can in some cases meet (2) far more easily than an in-band signature. it's also the case that rsync and similar tools (and AXFR) use TCP which most of us consider reliable even though its checksums aren't nearly as strong as SCTP's. therefore your problem statement being sure they got the exact right zone would have to refer to an MiTM, possibly inside the secondary server (if the zone receiver is a tertiary), or possibly on-path. in either case, to frustrate the MiTM, the proposed in-band signature would have to be DNSSEC based. and there is already an in-band DNSSEC-based zone identity/coherency test -- zone walking. why would we add another way to do the same thing we could do with existing DNSSEC data? ... Adding a record that says here is a hash of this zone, and adding an RRSIG for that record, is the simplest solution. There are other solutions that are exactly as secure; however, they are all more complex, and some involve using the zone signing key for signing something other than the contents of an RRSIG. i think walking the existing zone and verifying that there are no records between the nsecs and that every signature is valid and that the nsec chain ends at the apex, is simpler. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Assuring the contents of the root zone
Here is a strawman, to try and understand the discussion. If we imagine some datastream which is the result of an AXFR or HTTP request. cmd | tr 'AZ' 'az'| sort -u | checker this takes the stream, does LWSP replacement, and sorts the lines alphabetically and generates eg SHA256 the tr phase is just for example. presumably a more complex set of rules are required to DeMangLE the case conversion and punycode but the sense is, that we have a deterministic state of any label in the zone and its attributes as an encoding. The sort phase generates a single understood (POSIX sort) order of bytes. These can then be compared. Why is this worse than eg an RR by RR comparison, walking the NSEC chains? What I like about it, is that its applicable to being given the data OOB. if you have what is a putative zone, then you can apply this logic, and determine if the zone matches what is published elsewhere as a canonical state of the zone. The RR by RR and NSEC walk feels like a DNS experts approach. Not a systems/generic approach. -G On 2 December 2014 at 11:29, Paul Vixie p...@redbarn.org wrote: Paul Hoffman paul.hoff...@vpnc.org Monday, December 01, 2014 3:48 PM People have asked for two things: 1) Getting the root zone by means other than AXFR, such as by HTTP 2) Being sure that they got the exact root zone, including all of the glue records i think you meant zone not root zone here. A signed hash meets (2) regardless of how the zone was transmitted. not inevitably. the verification tool would be new logic, either built into the secondary name server, or as an outboard tool available to the transfer mechanism. when i compare the complexity-cost of that tool to the contents of the ftp://ftp.internic.net/domain ftp://ftp.internic.net/domain directory, i see that existing tools whose complexity-cost i already pay would work just fine. (those being pgp and md5sum). so, a detached signature can in some cases meet (2) far more easily than an in-band signature. it's also the case that rsync and similar tools (and AXFR) use TCP which most of us consider reliable even though its checksums aren't nearly as strong as SCTP's. therefore your problem statement being sure they got the exact right zone would have to refer to an MiTM, possibly inside the secondary server (if the zone receiver is a tertiary), or possibly on-path. in either case, to frustrate the MiTM, the proposed in-band signature would have to be DNSSEC based. and there is already an in-band DNSSEC-based zone identity/coherency test -- zone walking. why would we add another way to do the same thing we could do with existing DNSSEC data? ... Adding a record that says here is a hash of this zone, and adding an RRSIG for that record, is the simplest solution. There are other solutions that are exactly as secure; however, they are all more complex, and some involve using the zone signing key for signing something other than the contents of an RRSIG. i think walking the existing zone and verifying that there are no records between the nsecs and that every signature is valid and that the nsec chain ends at the apex, is simpler. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Assuring the contents of the root zone
On Dec 1, 2014, at 5:29 PM, Paul Vixie p...@redbarn.org wrote: i think you meant zone not root zone here. I meant root zone because I have heard nearly no one talk about verifying other zones. If what is created works for other zones, great. A signed hash meets (2) regardless of how the zone was transmitted. not inevitably. the verification tool would be new logic, either built into the secondary name server, or as an outboard tool available to the transfer mechanism. Others on this list have asked for a third use case, namely zone files sitting on disk. when i compare the complexity-cost of that tool to the contents of the ftp://ftp.internic.net/domain directory, i see that existing tools whose complexity-cost i already pay would work just fine. (those being pgp and md5sum). so, a detached signature can in some cases meet (2) far more easily than an in-band signature. Your proposal skips over the how do I trust this signing key part. You might want to force everyone else to do the work you have done to get to that trust; others might want a simpler solution. it's also the case that rsync and similar tools (and AXFR) use TCP which most of us consider reliable even though its checksums aren't nearly as strong as SCTP's. therefore your problem statement being sure they got the exact right zone would have to refer to an MiTM, possibly inside the secondary server (if the zone receiver is a tertiary), or possibly on-path. Yes. in either case, to frustrate the MiTM, the proposed in-band signature would have to be DNSSEC based. No offense, but you're making no sense. Above, you give a counter-example to that assertion. and there is already an in-band DNSSEC-based zone identity/coherency test -- zone walking. why would we add another way to do the same thing we could do with existing DNSSEC data? Maybe I'm just being dense, but I'm not seeing how zone walking validates the contents of the glue records. i think walking the existing zone and verifying that there are no records between the nsecs and that every signature is valid and that the nsec chain ends at the apex, is simpler. It is. Unless I'm missing something, it is also incomplete. (And, of course, doesn't work for zones that use NSEC3...) --Paul Hoffman ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Assuring the contents of the root zone
Paul Hoffman mailto:paul.hoff...@vpnc.org Monday, December 01, 2014 7:42 PM On Dec 1, 2014, at 5:29 PM, Paul Vixie p...@redbarn.org wrote: ... the verification tool would be new logic, either built into the secondary name server, or as an outboard tool available to the transfer mechanism. Others on this list have asked for a third use case, namely zone files sitting on disk. there's a program called dnssec-verify inside BIND9, and no doubt similar programs inside LDNS, OpenDNSSEC, and PowerDNSSEC, that handles zone files sitting on disk. (note, i'm in an almost pure SSD world at this point, i need to stop saying disk soon.) when i compare the complexity-cost of that tool to the contents of the ftp://ftp.internic.net/domain directory, i see that existing tools whose complexity-cost i already pay would work just fine. (those being pgp and md5sum). so, a detached signature can in some cases meet (2) far more easily than an in-band signature. Your proposal skips over the how do I trust this signing key part. You might want to force everyone else to do the work you have done to get to that trust; others might want a simpler solution. a detached signature would be validated using out-of-band methods. for example you might fetch the .MD5 file using some other method or fetch-source, and for PGP there are key servers and so forth. but i'm not recommending detached signatures per se. DNSSEC is the way to go. in either case, to frustrate the MiTM, the proposed in-band signature would have to be DNSSEC based. No offense, but you're making no sense. Above, you give a counter-example to that assertion. no offense taken. you suggested a DNSSEC-based signing key, i was trying (and failing) to agree with you. and there is already an in-band DNSSEC-based zone identity/coherency test -- zone walking. why would we add another way to do the same thing we could do with existing DNSSEC data? Maybe I'm just being dense, but I'm not seeing how zone walking validates the contents of the glue records. i apologize for not saying so explicitly: nothing can directly validate the contents of the glue records. two indirect methods exist, which are (1) looking it up in a validating RDNS and seeing if the content of the glue record you got with your zone is the same as the one signed by DNSSEC, in a provisional validation environment that asks what if this glue is correct?, and (2) using the glue and noting whether the zones reached by that NS+glue are signed with a key matching that zone's signed DS RR. if they are signed with the right key then it doesn't matter whether the address glue was correct or not. but you raise a very interesting issue, which is that the definition of zone does not include address glue. if the per-zonefile or per-axfr signature that you'd like to bind to the zone has to cover its glue, then we have a very interesting set of new problems, like does this mean all address glue or only necessary address glue (under our leaf delegations), does it include both A and RR's, which one is hashed first, and so on. all those rules would have to be spelled out in any signature that was made over all the stuff you get in an AXFR, or that you might find in a zone file sitting on disk rather than made over the zone. since NS RR's aren't signed in the parent, a zone-walk won't verify them, and perhaps that's your most compelling argument for some new signature which does cover those, since any unsigned child could be spoofed if the zone file (or AXFR contents) were tampered with. i think walking the existing zone and verifying that there are no records between the nsecs and that every signature is valid and that the nsec chain ends at the apex, is simpler. It is. Unless I'm missing something, it is also incomplete. (And, of course, doesn't work for zones that use NSEC3...) i don't think the root zone will ever use NSEC3. but for the sake of unsigned delegations from the root zone, and other zones besides the root zone that might want a similar kind of verification, i'll bite: is there a stream cipher that will remain both correct and secure when the zone is incrementally updated with IXFR and UPDATE deltas? because if the cost of an IXFR or UPDATE is that the whole zone has to be re-hashed, then this mechanism will be impractical for any zone which is either larger than the root zone is today or modified more frequently than the root zone is today. i'm imagining a stream cipher that begins as the H(K,zone) and then is updated to be H(K,H_old,delta) for each change to the zone, which would have to be calculated by the responder in the case of UPDATE, but could then be issued as a succession of new zone signature RR's during IXFR. the zone signature RR would have to be like SOA, there-can-be-only-one, so what might look like a set of them in an IXFR, is really a bunch of changes to the one-and-only. canonicalizing each delta, and whether or not to include
Re: [dns-operations] Assuring the contents of the root zone
On 12/1/14 9:03 PM, Paul Vixie wrote: i apologize for not saying so explicitly: nothing can directly validate the contents of the glue records. two indirect methods exist, which are (1) looking it up in a validating RDNS and seeing if the content of the glue record you got with your zone is the same as the one signed by DNSSEC, in a provisional validation environment that asks what if this glue is correct?, and (2) using the glue and noting whether the zones reached by that NS+glue are signed with a key matching that zone's signed DS RR. if they are signed with the right key then it doesn't matter whether the address glue was correct or not. but you raise a very interesting issue, which is that the definition of zone does not include address glue. if the per-zonefile or per-axfr signature that you'd like to bind to the zone has to cover its glue, then we have a very interesting set of new problems, like does this mean all address glue or only necessary address glue (under our leaf delegations), does it include both A and RR's, which one is hashed first, and so on. all those rules would have to be spelled out in any signature that was made over all the stuff you get in an AXFR, or that you might find in a zone file sitting on disk rather than made over the zone. since NS RR's aren't signed in the parent, a zone-walk won't verify them, and perhaps that's your most compelling argument for some new signature which does cover those, since any unsigned child could be spoofed if the zone file (or AXFR contents) were tampered with. Paul V., Thanks for responding to Paul H. on the topic I raised a couple of days ago. :) (I mentioned delegation NS records, since they are less controversial than actual glue, but it's the same issue.) While what you propose can be done, it would add more complexity than a simple zone signature that covers the entire zone. In any case, now that you've acknowledged that DNSSEC doesn't cover the intended use case, perhaps we can dispense with that line of argument? Doug ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Assuring the contents of the root zone
George, It's hard for me to see how this would easily handle dynamic updates. Doug On 12/1/14 5:56 PM, George Michaelson wrote: Here is a strawman, to try and understand the discussion. If we imagine some datastream which is the result of an AXFR or HTTP request. cmd | tr 'AZ' 'az'| sort -u | checker this takes the stream, does LWSP replacement, and sorts the lines alphabetically and generates eg SHA256 the tr phase is just for example. presumably a more complex set of rules are required to DeMangLE the case conversion and punycode but the sense is, that we have a deterministic state of any label in the zone and its attributes as an encoding. The sort phase generates a single understood (POSIX sort) order of bytes. These can then be compared. Why is this worse than eg an RR by RR comparison, walking the NSEC chains? What I like about it, is that its applicable to being given the data OOB. if you have what is a putative zone, then you can apply this logic, and determine if the zone matches what is published elsewhere as a canonical state of the zone. The RR by RR and NSEC walk feels like a DNS experts approach. Not a systems/generic approach. -G ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Assuring the contents of the root zone
Its not designed to handle dynamic updates. Its designed to handle being given, or accessing an entire zone state, and having a canonicalization method which can be applied by anyone, using POSIX tools to determine if its correct and complete On 2 December 2014 at 15:38, Doug Barton do...@dougbarton.us wrote: George, It's hard for me to see how this would easily handle dynamic updates. Doug On 12/1/14 5:56 PM, George Michaelson wrote: Here is a strawman, to try and understand the discussion. If we imagine some datastream which is the result of an AXFR or HTTP request. cmd | tr 'AZ' 'az'| sort -u | checker this takes the stream, does LWSP replacement, and sorts the lines alphabetically and generates eg SHA256 the tr phase is just for example. presumably a more complex set of rules are required to DeMangLE the case conversion and punycode but the sense is, that we have a deterministic state of any label in the zone and its attributes as an encoding. The sort phase generates a single understood (POSIX sort) order of bytes. These can then be compared. Why is this worse than eg an RR by RR comparison, walking the NSEC chains? What I like about it, is that its applicable to being given the data OOB. if you have what is a putative zone, then you can apply this logic, and determine if the zone matches what is published elsewhere as a canonical state of the zone. The RR by RR and NSEC walk feels like a DNS experts approach. Not a systems/generic approach. -G ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] DNSimple under attack?
Their website can't be reachable from my end. And one of my domains with them can't be resolved. Thanks. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] DNSimple under attack?
Yes they are. Try their twitter feed for additional info @dnsimple. On Dec 1, 2014 10:05 PM, Ken Peng yhp...@orange.fr wrote: Their website can't be reachable from my end. And one of my domains with them can't be resolved. Thanks. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Assuring the contents of the root zone
George Michaelson wrote: Its not designed to handle dynamic updates. Its designed to handle being given, or accessing an entire zone state, and having a canonicalization method which can be applied by anyone, using POSIX tools to determine if its correct and complete george, dns is dynamic now. a signature method must address the update case. here's what i wrote in response to paul-h: i'm imagining a stream cipher that begins as the H(K,zone) and then is updated to be H(K,H_old,delta) for each change to the zone, which would have to be calculated by the responder in the case of UPDATE, but could then be issued as a succession of new zone signature RR's during IXFR. the zone signature RR would have to be like SOA, there-can-be-only-one, so what might look like a set of them in an IXFR, is really a bunch of changes to the one-and-only. ... -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Assuring the contents of the root zone
I think the use of *must* here is non-normative. You make a strong case that a canonicalization must understand dynamic update. But you also chose to ignore a huge world of context where people are presented with zones as a fait accompli. Not as participants in port 53, but as files. I think we're silly to exclude mechanisms which are understandable by anyone, over what are (for much of their life) represented as files. There is a tool in bind which reads a .jnl. So, if I take the outcome of a dynamic update, secure it in a transactionally complete .jnl, and then apply the tool.. I have a file of a zone state, and a given point in time, for a given serial. At which point, I can canonicalize it, and apply checks against a published statement of the zones integrity. I don't want to exhaust anyones patience. I've said my bit, I am content if you have some closing last word on this, I won't post any more on this idea just now. I can tell that I am swimming against the tide. On 2 December 2014 at 16:13, Paul Vixie p...@redbarn.org wrote: George Michaelson wrote: Its not designed to handle dynamic updates. Its designed to handle being given, or accessing an entire zone state, and having a canonicalization method which can be applied by anyone, using POSIX tools to determine if its correct and complete george, dns is dynamic now. a signature method must address the update case. here's what i wrote in response to paul-h: i'm imagining a stream cipher that begins as the H(K,zone) and then is updated to be H(K,H_old,delta) for each change to the zone, which would have to be calculated by the responder in the case of UPDATE, but could then be issued as a succession of new zone signature RR's during IXFR. the zone signature RR would have to be like SOA, there-can-be-only-one, so what might look like a set of them in an IXFR, is really a bunch of changes to the one-and-only. ... -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Assuring the contents of the root zone
g'day, mate. it's 1030pm here, so likely broad daylight down under. George Michaelson mailto:g...@apnic.net Monday, December 01, 2014 10:18 PM I think the use of *must* here is non-normative. You make a strong case that a canonicalization must understand dynamic update. But you also chose to ignore a huge world of context where people are presented with zones as a fait accompli. Not as participants in port 53, but as files. i'm sorry, friend, i didn't mean to leave those out. zones held in files which only change when the file is edited or regenerated are a special case of update, as in zero updates. although BIND9 has a delicious ixfr-from-differences feature that can turn successive versions of a primary zone file into a stream of IXFR's, that's just gravy in this case. for your proposed use case, where the receiving end transfers a zone file and then runs posix tools to canonicalize it, extract its hash, and compare that hash to the hash of the canonicalized (by the way, spell check says i mean cannibalized and i'm not sure it's wrong) zone zone, would be entirely possible. i regret that i did not say so before. I think we're silly to exclude mechanisms which are understandable by anyone, over what are (for much of their life) represented as files. yes, we would be, and so i'm not. as it were. There is a tool in bind which reads a .jnl. So, if I take the outcome of a dynamic update, secure it in a transactionally complete .jnl, and then apply the tool.. I have a file of a zone state, and a given point in time, for a given serial. At which point, I can canonicalize it, and apply checks against a published statement of the zones integrity. yes, and yes. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
