[DNSOP] Incremental zone hash - XHASH
Rather than having a full zone hash this can be done as a chain of hashes (XHASH). The XHASH would include all records at a signed name (where a signed name is NOT an NSEC3 name) up until the next signed name (where a signed name is NOT a NSEC3 name) in DNSSEC order similar to ZONEMD. If there is a NSEC3 record and its RRSIGs in this range it is included in the hash computation. Where a NSEC3 record matches the name of a record that exists in the zone it is hashed with that name. The record type appears at both top and bottom of zone similar to NS. The chain is only deemed to be complete if there is a hash record at the zone apex. This allows for incremental construction and destruction of the XHASH chain similar to the way the presence of NSEC at the zone apex indicates that chain is complete. If there are records that are not at or under the zone apex they are included in the final XHASH of the zone sorting from the zone apex to the end of the namespace then from the start of the namespace to the zone apex. Such records at not normally visible to queries other than AXFR/IXFR. AXFR/IXFR permit such records. XHASH would allow for UPDATE to incrementally adjust the chain without having to hash the entire zone at once. XHASH would allow for a slave server to verify a zone is still complete after a IXFR by just checking the areas of the zone impacted by the IXFR. e.g. example.com SOA example.com NS ns.example.com example.com DNSKEY … example.com NSEC a.example.com NS SOA RRSIG NSEC DNSKEY XHASH example.com XHASH … a.example.com NS ns.a.example.com a.example.com NSEC b.example.com NS RRSIG NSEC XHASH a.example.com XHASH … ns.a.example.com A … b.example.com NS ns.b.example.com b.example.com NSEC ns.example.com NS RRSIG NSEC XHASH b.example.com XHASH … ns.b.example.com A … ns.example.com A … ns.example.com … ns.example.com NSEC example.com A RRSIG NSEC XHASH ns.example.com XHASH … Each of the groupings shows which records plus RRSIGs that are included in the XHASH calculation. To prevent removal/introduction of RRSIGs of XHASH records a DNSKEY flag bit is be needed to indicate which RRSIG(XHASH) should/should not be present once the chain is complete. The same applies to RRSIG(ZONEMD). Verification of a AXFR would be slightly slower than with ZONEMD as there are more RRSIG records to be processed, -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QNAME minimisation on the standards track?
Jonathan That's *exactly* the type of operational issues that I am interesting in documenting. (That doesn't mean the other chairs or the working group feel the same way, in fact they probably won't! Tim On Fri, Jul 20, 2018 at 9:40 AM, Jonathan Reed < jreed=40akamai@dmarc.ietf.org> wrote: > > On Tue, 17 Jul 2018, manu tman wrote: > > I'd like to see this standardized too. >> Side note: I would also be interested to get a return of experience from >> people operating qname minimization at scale, >> > > I suspect you're looking for feedback from recursive operators, but I'd > like to share our experience as an authoritative operator. Supporting > QNAME minimization as an authoritative implies correctly responding NOERROR > to empty-non-terminals (ENTs) within the zone. RFC 4592 clarifies the > interaction between wildcards and ENTs, however this poses a problem with > customer-provided zone data. > > RFC 4592's behavior is not intuitive to most of our customers, and given > that many other authoritative operators did not (and perhaps still don't) > correctly handle interaction between wildcards and ENTs, we received > significant customer pushback when we started correctly handling ENTs and > wildcards. In short, as far as customers are concerned, '*' should always > match "across" dots. _We_ all understand why it doesn't, but it's not > intuitive to our customers, and it is no longer the case that the person > managing a company's zone has an extensive background in DNS. (Nor, > frankly, should it be the case). > > Here's a common example: Consider a SaaS/cloud provider that onboards > customers through CNAMEs. For example, cloudco.biz would onboard > example.com by creating "example.com.cloudco.biz" and CNAMEing it to some > internal name. The SaaS provider also typically has a wildcard at/below > the apex of their zone (*.cloudco.biz) to gracefully handle their > customers who may put the CNAME in place before they have been fully > provisioned. > > Such a zone, by definition, potentially has ENTs at every possible TLD. > Thus, www.notyetprovisioned.com.clouco.biz will never match the wildcard > at the apex, because of the ENT at com.cloudco.biz. The SaaS provider is > now causing a significant outage for their in-the-process-of-onboarding > customers, and the provider is rightly very unenthusiastic about copying > that apex wildcard down to every TLD. The problem is further compounded > with ccTLDs (www.example.co.uk.cloudco.biz creates two ENTs: one at uk, > one at co.uk). This rapidly becomes an untenable solution for our > customers, and they're likely to seek out another authoritative provider. > > I realize this is a somewhat a special case, but there were (still are?) > many large authoritative DNS providers in this position, and our effort to > support QNAME minimization pushed a large operational problem onto our > customers. > > -Jon > > -- > Jonathan Reed > Senior Performance Engineer > Akamai Technologies > > > the type of issues encountered, what are the ratios of such errors >> hint @marek :) >> >> Manu >> >> On Tue, Jul 17, 2018 at 2:35 PM Paul Wouters wrote: >> On Tue, 17 Jul 2018, tjw ietf wrote: >> >> > Subject: Re: [DNSOP] QNAME minimisation on the standards track? >> > >> > I’d like to see a more fleshed out operational considerations >> section. >> >> That would be good indeed. Especially with respect to broken DNS >> load >> balancers. >> >> I have enabled it in Fedora from the start and did run into a few >> problem >> domains, and some people turning it off. But that happened less >> than I >> had expected. Red Hat did not yet enable this in RHEL7 but it is >> planned >> to be enabled in RHEL8. >> >> But I do believe qname minimisation is an important privacy >> enhancing >> technology that we should strongly promote as a standards track >> document. >> >> Paul >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The DNSOP WG has placed draft-wessels-dns-zone-digest in state "Candidate for WG Adoption"
The DNSOP WG has placed draft-wessels-dns-zone-digest in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The DNSOP WG has placed draft-kh-dnsop-7706bis in state "Candidate for WG Adoption"
The DNSOP WG has placed draft-kh-dnsop-7706bis in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-kh-dnsop-7706bis/ Comment: Needs some more review before we adopt. but still. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-13.txt
[ Top-post ] Thank you to Ólafur and Dave for their comments -- I know that the discussion on the draft has been long and the draft is filled with minutia, but we'd dearly love more feedback, positive or negative. W On Thu, Jul 19, 2018 at 11:42 PM Dave Lawrence wrote: > > Warren Kumari writes: > > On Wed, Jul 18, 2018 at 9:36 AM Warren Kumari wrote: > > > > > > The authors are more than happy to change the name to that... > > but we would really really appreciate more comments / review. > > I support publication as-is, existing title and all. It is a valuable > document about the operational considerations for which DNSSEC signers > really need better guidance. I do not think the title needs changing, > as it clearly says it is targeted at the publishing side. > > The "publication considered harmful" claim needs explanation as to the > harms that would be caused. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Incremental zone hash - XHASH
The same zone NSEC3 signed with a.example.com in OPTOUT range example.com SOA example.com NS ns.example.com example.com DNSKEY … example.com NSEC3PARAM 1 0 0 - example.com XHASH … 3QNILC4QRC2P5CRN7JGVB5S3BPG0SHUV.example.com 1 1 0 - NSEC3 1 1 0 - ONIB9MGUB9H0RML3CDF5BGRJ59DKJHVK.example.com NS RRSIG XHASH a.example.com NS ns.a.example.com ns.a.example.com A … b.example.com NS ns.b.example.com b.example.com XHASH … ns.b.example.com A … ns.example.com A … ns.example.com … ns.example.com XHASH … ONIB9MGUB9H0RML3CDF5BGRJ59DKJHVK.example.com NSEC3 1 1 0 - PTJ67J96LVVVBU5K3V6N10B6QMO17275 NS SOA RRSIG DNSKEY NSEC3PARAM XHASH PTJ67J96LVVVBU5K3V6N10B6QMO17275.example.com NSEC 1 1 0 - 3QNILC4QRC2P5CRN7JGVB5S3BPG0SHUV.example.com A RRSIG XHASH -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] The DNSOP WG has placed draft-song-atr-large-resp in state "Candidate for WG Adoption"
The DNSOP WG has placed draft-song-atr-large-resp in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-song-atr-large-resp/ Comment: We don't know if theWG is ready to adopt this, but marking this down so the chairs do not forget. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QNAME minimisation on the standards track?
That's a great feedback Jonathan! Thanks Manu On Fri, Jul 20, 2018 at 6:40 AM Jonathan Reed wrote: > > On Tue, 17 Jul 2018, manu tman wrote: > > > I'd like to see this standardized too. > > Side note: I would also be interested to get a return of experience from > people operating qname minimization at scale, > > I suspect you're looking for feedback from recursive operators, but I'd > like to share our experience as an authoritative operator. Supporting > QNAME minimization as an authoritative implies correctly responding > NOERROR to empty-non-terminals (ENTs) within the zone. RFC 4592 clarifies > the interaction between wildcards and ENTs, however this poses a problem > with customer-provided zone data. > > RFC 4592's behavior is not intuitive to most of our customers, and given > that many other authoritative operators did not (and perhaps still don't) > correctly handle interaction between wildcards and ENTs, we received > significant customer pushback when we started correctly handling ENTs and > wildcards. In short, as far as customers are concerned, '*' should always > match "across" dots. _We_ all understand why it doesn't, but it's not > intuitive to our customers, and it is no longer the case that the person > managing a company's zone has an extensive background in DNS. (Nor, > frankly, should it be the case). > > Here's a common example: Consider a SaaS/cloud provider that onboards > customers through CNAMEs. For example, cloudco.biz would onboard > example.com by creating "example.com.cloudco.biz" and CNAMEing it to some > internal name. The SaaS provider also typically has a wildcard at/below > the apex of their zone (*.cloudco.biz) to gracefully handle their > customers who may put the CNAME in place before they have been > fully provisioned. > > Such a zone, by definition, potentially has ENTs at every possible TLD. > Thus, www.notyetprovisioned.com.clouco.biz will never match the wildcard > at the apex, because of the ENT at com.cloudco.biz. The SaaS provider is > now causing a significant outage for their in-the-process-of-onboarding > customers, and the provider is rightly very unenthusiastic about copying > that apex wildcard down to every TLD. The problem is further compounded > with ccTLDs (www.example.co.uk.cloudco.biz creates two ENTs: one at uk, > one at co.uk). This rapidly becomes an untenable solution for our > customers, and they're likely to seek out another authoritative provider. > > I realize this is a somewhat a special case, but there were (still are?) > many large authoritative DNS providers in this position, and our effort to > support QNAME minimization pushed a large operational problem onto our > customers. > > -Jon > > -- > Jonathan Reed > Senior Performance Engineer > Akamai Technologies > > > the type of issues encountered, what are the ratios of such errors > hint @marek :) > > > > Manu > > > > On Tue, Jul 17, 2018 at 2:35 PM Paul Wouters wrote: > > On Tue, 17 Jul 2018, tjw ietf wrote: > > > > > Subject: Re: [DNSOP] QNAME minimisation on the standards track? > > > > > > I’d like to see a more fleshed out operational considerations > section. > > > > That would be good indeed. Especially with respect to broken DNS > load > > balancers. > > > > I have enabled it in Fedora from the start and did run into a few > problem > > domains, and some people turning it off. But that happened less > than I > > had expected. Red Hat did not yet enable this in RHEL7 but it is > planned > > to be enabled in RHEL8. > > > > But I do believe qname minimisation is an important privacy > enhancing > > technology that we should strongly promote as a standards track > > document. > > > > Paul > > > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Publication has been requested for draft-ietf-dnsop-kskroll-sentinel-15
Tim Wicinski has requested publication of draft-ietf-dnsop-kskroll-sentinel-15 as Proposed Standard on behalf of the DNSOP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-huque-dnsop-multi-provider-dnssec
All Thanks for all the comments on this draft. The Call for Adoption is ending today but it seems that there is consensus to adopt this work in DNSOP and support this work. The chairs thank everyone for the feedback. Authors should upload a new version with the draft-ietf-dnsop-multi-provider-dnssec name. Thanks! Tim for all the chairs On Fri, Jul 6, 2018 at 8:26 PM, Tim Wicinski wrote: > > We've had some interest in moving this document forward, and the chairs > wanted to kick off this Call for Adoption before Montreal so if there > are concerns there will be some meeting time to address. > > This document is label as: Informational. The document is attempting > to document operational deployment models on deploying DNSSEC signed > zones across multiple platforms. > > This starts a Call for Adoption for: draft-huque-dnsop-multi- > provider-dnssec > > The draft is available here: https://datatracker.ietf.org/ > doc/draft-huque-dnsop-multi-provider-dnssec/ > > Please review this draft to see if you think it is suitable for > adoption by DNSOP, and comments to the list, clearly stating your view. > The authors will be at the next meeting to address questions or concerns. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 20 July 2018 > > Thanks, > Tim > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] IETF102 Actions and Updates
All Thanks for a pretty productive week and thanks for breaking in our new chair slowly. Rough Minutes have been uploaded: https://datatracker.ietf.org/doc/minutes-102-dnsop/ And I apologize - I took notes of the last topic on Thursday but have somehow lost them. I will listen to the audio and update those comments early next week. If you have issues with the minutes drop the chairs a note, *or* send us a pull request: https://github.com/DNSOP/wg-materials/blob/master/dnsop-ietf102/dnsop-ietf102-minutes-1.txt IETF103: I am thinking we will focus on one meeting next time, though who knows, we may get 100 new documents next month. Also, we will send some documents through for adoption in August, but the chairs feel that Europe is much more civilized in how they take the month as a holiday, and will probably slow down more than normal. - Actions: Here is what we have in terms of actions from this week. If we missed something, it's my fault. * draft-ietf-dnsop-kskroll-sentinel - Submitted to IESG * draft-ietf-dnsop-isp-ip6rdns - Submitted to IESG * draft-ietf-dnsop-attrleaf * draft-ietf-dnsop-attrleaf-fix - WGLC has ended, Shepherd write up is underway (with thanks to Mr. Crocker!), and working with Benno on this. He's double checking everything to make sure pushing the button won't end the world. - The chairs feel these documents need to move thru the process promptly so other working groups can seek their guidance. * draft-ietf-dnsop-rfc5011-security-considerations - We are holding this for now, and the chairs feel that there is an issue with consensus and content that will most likely kill this moving forward. * draft-ietf-dnsop-terminology-bis - Write-up is wrapping up and *will be submitted* by Monday at the latest. * draft-ietf-dnsop-dns-capture-format - WGLC last call ended with two issues to be addressed. These will be resolved in Early August after Holiday. * draft-huque-dnsop-multi-provider-dnssec: Adopted ! * draft-ietf-dnsop-algorithm-update - is almost ready for WGLC * draft-dupont-dnsop-rfc2845bis - is almost ready for WGLC * draft-wessels-dns-zone-digest - Candidate for adoption * draft-kh-dnsop-7706bis - Candidate for adoption. * draft-bortzmeyer-rfc7816bis - Candidate for adoption * draft-song-atr-large-resp - Candidate for adoption, though more contentious. * DNS Cookies and their Operational Impacts - We expect to see drafts addressing these issues, as well as drafts urging to move cookies to Historic to appear. * Addressing the Zone Apex Synthetic Records (CNAME/ALIAS/ANAME/ZNAME) - We will continue to work to address this gap between the user community and the protocol folks. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IETF102 Actions and Updates
I've been watching actively but quietly. Stellar work! Congratulations! Steve Crocker On Fri, Jul 20, 2018 at 2:40 PM, Tim Wicinski wrote: > > All > > Thanks for a pretty productive week and thanks for > breaking in our new chair slowly. > > Rough Minutes have been uploaded: > > https://datatracker.ietf.org/doc/minutes-102-dnsop/ > > And I apologize - I took notes of the last topic on Thursday but have > somehow lost them. I will listen to the audio and update those comments > early next week. > > If you have issues with the minutes drop the chairs a note, *or* > send us a pull request: > > https://github.com/DNSOP/wg-materials/blob/master/dnsop- > ietf102/dnsop-ietf102-minutes-1.txt > > IETF103: I am thinking we will focus on one meeting next time, > though who knows, we may get 100 new documents next month. > > Also, we will send some documents through for adoption in August, but > the chairs feel that Europe is much more civilized in how they take > the month as a holiday, and will probably slow down more than normal. > > - > Actions: > > Here is what we have in terms of actions from this week. > If we missed something, it's my fault. > > * draft-ietf-dnsop-kskroll-sentinel - Submitted to IESG > > * draft-ietf-dnsop-isp-ip6rdns - Submitted to IESG > > * draft-ietf-dnsop-attrleaf > * draft-ietf-dnsop-attrleaf-fix > - WGLC has ended, Shepherd write up is underway (with thanks > to Mr. Crocker!), and working with Benno on this. He's > double checking everything to make sure pushing the button > won't end the world. > > - The chairs feel these documents need to move thru the process > promptly so other working groups can seek their guidance. > > * draft-ietf-dnsop-rfc5011-security-considerations > - We are holding this for now, and the chairs feel that > there is an issue with consensus and content that will > most likely kill this moving forward. > > * draft-ietf-dnsop-terminology-bis > - Write-up is wrapping up and *will be submitted* by Monday at > the latest. > > * draft-ietf-dnsop-dns-capture-format > - WGLC last call ended with two issues to be addressed. > These will be resolved in Early August after Holiday. > > * draft-huque-dnsop-multi-provider-dnssec: Adopted ! > > * draft-ietf-dnsop-algorithm-update - is almost ready for WGLC > > * draft-dupont-dnsop-rfc2845bis - is almost ready for WGLC > > * draft-wessels-dns-zone-digest - Candidate for adoption > > * draft-kh-dnsop-7706bis - Candidate for adoption. > > * draft-bortzmeyer-rfc7816bis - Candidate for adoption > > * draft-song-atr-large-resp - Candidate for adoption, though more > contentious. > > * DNS Cookies and their Operational Impacts > - We expect to see drafts addressing these issues, as well as > drafts urging to move cookies to Historic to appear.. > > * Addressing the Zone Apex Synthetic Records (CNAME/ALIAS/ANAME/ZNAME) > - We will continue to work to address this gap between the user > community > and the protocol folks. > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-10.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations WG of the IETF. Title : A Common Operational Problem in DNS Servers - Failure To Respond. Authors : M. Andrews Ray Bellis Filename: draft-ietf-dnsop-no-response-issue-10.txt Pages : 25 Date: 2018-07-20 Abstract: The DNS is a query / response protocol. Failing to respond to queries, or responding incorrectly, causes both immediate operational problems and long term problems with protocol development. This document identifies a number of common kinds of queries to which some servers either fail to respond or else respond incorrectly. This document also suggests procedures for TLD and other zone operators to apply to help reduce / eliminate the problem. The document does not look at the DNS data itself, just the structure of the responses. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-no-response-issue-10 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-no-response-issue-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-no-response-issue-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Incremental zone hash - XHASH
perfect! Mark Andrews wrote: Rather than having a full zone hash this can be done as a chain of hashes (XHASH). The XHASH would include all records at a signed name (where a signed name is NOT an NSEC3 name) up until the next signed name (where a signed name is NOT a NSEC3 name) in DNSSEC order similar to ZONEMD. If there is a NSEC3 record and its RRSIGs in this range it is included in the hash computation. Where a NSEC3 record matches the name of a record that exists in the zone it is hashed with that name. The record type appears at both top and bottom of zone similar to NS. The chain is only deemed to be complete if there is a hash record at the zone apex. This allows for incremental construction and destruction of the XHASH chain similar to the way the presence of NSEC at the zone apex indicates that chain is complete. If there are records that are not at or under the zone apex they are included in the final XHASH of the zone sorting from the zone apex to the end of the namespace then from the start of the namespace to the zone apex. Such records at not normally visible to queries other than AXFR/IXFR. AXFR/IXFR permit such records. XHASH would allow for UPDATE to incrementally adjust the chain without having to hash the entire zone at once. XHASH would allow for a slave server to verify a zone is still complete after a IXFR by just checking the areas of the zone impacted by the IXFR. e.g. example.com SOA example.com NS ns.example.com example.com DNSKEY … example.com NSEC a.example.com NS SOA RRSIG NSEC DNSKEY XHASH example.com XHASH … a.example.com NS ns.a.example.com a.example.com NSEC b.example.com NS RRSIG NSEC XHASH a.example.com XHASH … ns.a.example.com A … b.example.com NS ns.b.example.com b.example.com NSEC ns.example.com NS RRSIG NSEC XHASH b.example.com XHASH … ns.b.example.com A … ns.example.com A … ns.example.com … ns.example.com NSEC example.com A RRSIG NSEC XHASH ns.example.com XHASH … Each of the groupings shows which records plus RRSIGs that are included in the XHASH calculation. To prevent removal/introduction of RRSIGs of XHASH records a DNSKEY flag bit is be needed to indicate which RRSIG(XHASH) should/should not be present once the chain is complete. The same applies to RRSIG(ZONEMD). Verification of a AXFR would be slightly slower than with ZONEMD as there are more RRSIG records to be processed, -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-dns-capture-format
All The WG Last Call for draft-ietf-dnsop-dns-capture-format and the chairs feel we have enough consensus to move this forward. HOWEVER, two things did come up with some reviews that happened in the last few days: - The packet format has a version number, but the draft does not document or explain this. - There is a concern that the math on the packet size may be slightly off. Sara has agreed to work on the text for the version number, and I agreed to sit down and count all the bits and make sure things are accurate. Sara will be on Holiday until August, so we hope to have these issues sorted out "very soon" and we will move this along. I'll work on the Shepherd write up (unless someone in the working group wants to do it!) as well. Thanks Tim On Fri, Jul 6, 2018 at 8:32 PM, Tim Wicinski wrote: > > All, > > We feel that the authors have addressed all outstanding issues, and this > document is ready to move forward. Also, the chairs wanted to kick off > this Working Group before Montreal so if there are any issues that need > some face time, we'll have it. > > One thing which arose early in the process was the issue of IPR and how > it would be resolved. The simple answer is that it is resolved farther > up the process chain. I spent time reading RFC 3979 on this topic: > https://tools.ietf.org/html/rfc3979#section-10 > > This starts a Working Group Last Call for draft-ietf-dnsop-dns-capture-f > ormat > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/ > > The Current Intended Status of this document is: Standards Track > > Please review the draft and offer relevant comments. If this does not > seem appropriate please speak out. If someone feels the document is *not* > ready for publication, please speak out with your reasons. > > This starts a two week Working Group Last Call process, and ends on: 20 > July 2018 > > thanks > tim > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Incremental zone hash - XHASH
Mark, Thanks for the email. My first reaction is that it adds a lot of additional records to the zone. If I understand correctly, one XHASH for every NSEC/NSEC3, plus an RRSIG for each XHASH. You didn't really say how (or if) XHASH could be used on an unsigned zone. My second reaction is that it is (necessarily) more complex than what we proposed with ZONEMD. It seems like it probably works, but I haven't really spent time thinking about it in depth. The use case that my coauthors and I are trying to address with ZONEMD is to verify authenticity for relatively stable zones being distributed to servers other than the ones in the NS RRset. For this XHASH feels like too much. Too much data and too much complexity. I'm not sure if you're proposing XHASH as an alternative to, or in addition to, ZONEMD. If the latter then I'd say get input from operators of dynamic zones and see if they think the tradeoff of extra data and complexity is of net benefit to them. DW > On Jul 20, 2018, at 3:31 AM, Mark Andrews wrote: > > Rather than having a full zone hash this can be done as a chain > of hashes (XHASH). > > The XHASH would include all records at a signed name (where a signed > name is NOT an NSEC3 name) up until the next signed name (where a > signed name is NOT a NSEC3 name) in DNSSEC order similar to ZONEMD. > If there is a NSEC3 record and its RRSIGs in this range it is included > in the hash computation. Where a NSEC3 record matches the name of a > record that exists in the zone it is hashed with that name. The record > type appears at both top and bottom of zone similar to NS. > > The chain is only deemed to be complete if there is a hash record at > the zone apex. This allows for incremental construction and destruction > of the XHASH chain similar to the way the presence of NSEC at the zone > apex indicates that chain is complete. > > If there are records that are not at or under the zone apex they are included > in the final XHASH of the zone sorting from the zone apex to the end of the > namespace then from the start of the namespace to the zone apex. Such records > at not normally visible to queries other than AXFR/IXFR. AXFR/IXFR permit > such > records. > > XHASH would allow for UPDATE to incrementally adjust the chain without > having to hash the entire zone at once. > > XHASH would allow for a slave server to verify a zone is still complete > after a IXFR by just checking the areas of the zone impacted by the IXFR. > > e.g. > > example.com SOA > example.com NS ns.example.com > example.com DNSKEY … > example.com NSEC a.example.com NS SOA RRSIG NSEC DNSKEY XHASH > example.com XHASH … > > a.example.com NS ns.a.example.com > a.example.com NSEC b.example.com NS RRSIG NSEC XHASH > a.example.com XHASH … > ns.a.example.com A … > > b.example.com NS ns.b.example.com > b.example.com NSEC ns.example.com NS RRSIG NSEC XHASH > b.example.com XHASH … > ns.b.example.com A … > > ns.example.com A … > ns.example.com … > ns.example.com NSEC example.com A RRSIG NSEC XHASH > ns.example.com XHASH … > > Each of the groupings shows which records plus RRSIGs that are > included in the XHASH calculation. > > To prevent removal/introduction of RRSIGs of XHASH records a DNSKEY > flag bit is be needed to indicate which RRSIG(XHASH) should/should not > be present once the chain is complete. The same applies to RRSIG(ZONEMD). > > Verification of a AXFR would be slightly slower than with ZONEMD as there > are more RRSIG records to be processed, > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
