From klaus.mailinglists at pernau.at Tue May 4 13:59:56 2021 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Tue, 4 May 2021 15:59:56 +0200 Subject: [dns-operations] validating zones before distribution to secondaries Message-ID: Hello! In my setup I receive zones from various hidden primaries to my "incoming" nameserver. Before my "distribution" nameserver fetches the zone from the "incoming" nameserver (and hence sends NOTIFYs to the public secondaries) I I want to perform various checks on the zone loaded on the incoming nameserver. Currently I use a freaky Bind9 setup with several perl scripts. Do you know if there exists any software tool that were written for such setups? For example a Secondary which fetches a zone not automatically but only on request? Or a nameserver which fetches a zone but only "loads" it if an external tool validates the zone? Thanks Klaus From anandb at ripe.net Tue May 4 14:30:28 2021 From: anandb at ripe.net (Anand Buddhdev) Date: Tue, 4 May 2021 16:30:28 +0200 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: References: Message-ID: On 04/05/2021 15:59, Klaus Darilion wrote: Hi Klaus, > In my setup I receive zones from various hidden primaries to my > "incoming" nameserver. Before my "distribution" nameserver fetches the > zone from the "incoming" nameserver (and hence sends NOTIFYs to the > public secondaries) I I want to perform various checks on the zone > loaded on the incoming nameserver. > > Currently I use a freaky Bind9 setup with several perl scripts. Do you > know if there exists any software tool that were written for such > setups? For example a Secondary which fetches a zone not automatically > but only on request? Or a nameserver which fetches a zone but only > "loads" it if an external tool validates the zone? I don't think any of the existing name servers have that facility. I know that the latest Knot DNS can do DNSSEC validation of incoming XFRs, and I guess this implies general DNS correctness checks. However, if you want to do custom checks, you'll have to do this yourself. You might want to look at Tony Finch's nsnotifyd, which is a custom program that can monitor zones for changes, and run custom commands when changes are detected. It can also listen for NOTIFY messages and act immediately on zone changes. You could use it to run your custom checks before distributing your zones. https://github.com/fanf2/nsnotifyd Regards, Anand Buddhdev From sca at andreasschulze.de Tue May 4 16:28:30 2021 From: sca at andreasschulze.de (A. Schulze) Date: Tue, 4 May 2021 18:28:30 +0200 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: References: Message-ID: Am 04.05.21 um 16:30 schrieb Anand Buddhdev: > You might want to look at Tony Finch's nsnotifyd, which is a custom > program that can monitor zones for changes, and run custom commands when > changes are detected. It can also listen for NOTIFY messages and act > immediately on zone changes. You could use it to run your custom checks > before distributing your zones. > https://github.com/fanf2/nsnotifyd Yes, Tony's program it's a little bit tricky to build but works... Andreas From ietf-dane at dukhovni.org Tue May 4 17:22:01 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 4 May 2021 13:22:01 -0400 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: References: Message-ID: <5A7F7C05-F4F6-4EDD-83B3-2F37D4194751@dukhovni.org> > > On May 4, 2021, at 12:28 PM, A. Schulze wrote: > >> https://github.com/fanf2/nsnotifyd > > Yes, Tony's program it's a little bit tricky to build but works... For a useful standalone component, I rather like: ldns-verify-zone -- Viktor. From regnauld at nsrc.org Tue May 4 18:53:59 2021 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 4 May 2021 20:53:59 +0200 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: References: Message-ID: <20210504185359.GQ32158@macbook.x0.dk> Klaus Darilion (klaus.mailinglists) writes: > Hello! > > In my setup I receive zones from various hidden primaries to my "incoming" > nameserver. Before my "distribution" nameserver fetches the zone from the > "incoming" nameserver (and hence sends NOTIFYs to the public secondaries) I > I want to perform various checks on the zone loaded on the incoming > nameserver. > > Currently I use a freaky Bind9 setup with several perl scripts. Do you know > if there exists any software tool that were written for such setups? For > example a Secondary which fetches a zone not automatically but only on > request? Or a nameserver which fetches a zone but only "loads" it if an > external tool validates the zone? On the validation side, take a look at: https://github.com/tobez/validns Cheers, Phil From klaus.mailinglists at pernau.at Tue May 4 18:59:41 2021 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Tue, 4 May 2021 20:59:41 +0200 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: References: Message-ID: <54e9b924-a52c-cad3-0768-92e72da7509d@pernau.at> Hi Anand! Am 04.05.2021 um 16:30 schrieb Anand Buddhdev: > > You might want to look at Tony Finch's nsnotifyd, which is a custom > program that can monitor zones for changes, and run custom commands when > changes are detected. It can also listen for NOTIFY messages and act > immediately on zone changes. You could use it to run your custom checks > before distributing your zones. We already use a self written tool, quite similar to nsnotifyd to catch NOTIFYs and start the zone validation. After sucessfull validation, I would like to use standard XFR between name servers to further distribute the zone. I want to avoid doing manual zone transfers with tools like dig, or manually copying zone files, as this is IMO not so reliable. Hence, a nameserver as secondary which does not perform any SOA-checks itself, but only performs SOA-checks when triggered externally (ie "rndc refresh zone") would be nice. Unfurtunately I am not aware of a name server which can be configured like that* regards Klaus * A hack would be PowerDNS with master=some.non.responding.ip. Then SOA checks would fail, but incoming transfer could be triggered by "pdns_control retrieve zone ip.address.of.primary" From dot at dotat.at Tue May 4 20:24:29 2021 From: dot at dotat.at (Tony Finch) Date: Tue, 4 May 2021 21:24:29 +0100 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: References: Message-ID: <29162c85-2f53-3667-46ab-7aac3d58d74@dotat.at> A. Schulze wrote: > > > https://github.com/fanf2/nsnotifyd > > Yes, Tony's program it's a little bit tricky to build but works... I am really pleased to hear that you have found nsnotifyd helpful! It's hard to tell if silence is due to happy users or no users :-) I regret that I am pathologically ignorant about autoconf. I hate using it to build other people's software so I don't use it in my build systems. Sorry if my basic Makefile has caused trouble for you. nsnotifyd is somewhat problematic because it is relatively oldskool C and relies on the ancient BIND resolver library. (Or the libc resolver if that works.) I tried to be careful when I wrote it, but its foundations are not very firm... [ our house is on the site of an old brickworks, and a map from 1888 shows there was a water-filled pit somewhere nearby; when they were demolishing the warehouse at the back of our garden to build flats, our house shook in sympathy - yeah, the foundations are not very firm! ] Tony. -- f.anthony.n.finch https://dotat.at/ protect and enlarge the conditions of liberty and social justice From sca at andreasschulze.de Tue May 4 21:32:03 2021 From: sca at andreasschulze.de (A. Schulze) Date: Tue, 4 May 2021 23:32:03 +0200 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: <20210504185359.GQ32158@macbook.x0.dk> References: <20210504185359.GQ32158@macbook.x0.dk> Message-ID: <22bfdb6a-7e0f-fe6b-ddad-52bf8522855f@andreasschulze.de> Am 04.05.21 um 20:53 schrieb Phil Regnauld: > On the validation side, take a look at: > > https://github.com/tobez/validns validns seem to be unmaintained. Build fail with current openssl :/ From casey at deccio.net Tue May 4 23:45:07 2021 From: casey at deccio.net (Casey Deccio) Date: Tue, 4 May 2021 17:45:07 -0600 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: References: Message-ID: > On May 4, 2021, at 7:59 AM, Klaus Darilion wrote: > > In my setup I receive zones from various hidden primaries to my "incoming" nameserver. Before my "distribution" nameserver fetches the zone from the "incoming" nameserver (and hence sends NOTIFYs to the public secondaries) I I want to perform various checks on the zone loaded on the incoming nameserver. > > Currently I use a freaky Bind9 setup with several perl scripts. Do you know if there exists any software tool that were written for such setups? For example a Secondary which fetches a zone not automatically but only on request? Or a nameserver which fetches a zone but only "loads" it if an external tool validates the zone? With a focus on mostly DNSSEC, but also some general DNS, you can use DNSViz for pre-deployment testing, as shown here: https://github.com/dnsviz/dnsviz#pre-deployment-dns-testing It is not automated, so you would have to build in scripts around it. Casey From arsen.stasic at univie.ac.at Wed May 5 05:47:22 2021 From: arsen.stasic at univie.ac.at (Arsen STASIC) Date: Wed, 5 May 2021 07:47:22 +0200 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: <22bfdb6a-7e0f-fe6b-ddad-52bf8522855f@andreasschulze.de> References: <20210504185359.GQ32158@macbook.x0.dk> <22bfdb6a-7e0f-fe6b-ddad-52bf8522855f@andreasschulze.de> Message-ID: <20210505054722.GD2897@univie.ac.at> * A. Schulze [2021-05-04 23:32 (+0200)]: > > >Am 04.05.21 um 20:53 schrieb Phil Regnauld: >> On the validation side, take a look at: >> >> https://github.com/tobez/validns > >validns seem to be unmaintained. Build fail with current openssl :/ https://github.com/DENICeG/validns Is a fork of validns and should work :) cheers, arsen From Robert.Mortimer at nominet.uk Wed May 5 08:14:24 2021 From: Robert.Mortimer at nominet.uk (Robert Mortimer) Date: Wed, 5 May 2021 08:14:24 +0000 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: <22bfdb6a-7e0f-fe6b-ddad-52bf8522855f@andreasschulze.de> References: <20210504185359.GQ32158@macbook.x0.dk> <22bfdb6a-7e0f-fe6b-ddad-52bf8522855f@andreasschulze.de> Message-ID: Also Validns isn't happy with all of the current DNSSEC algorithms. -----Original Message----- From: dns-operations On Behalf Of A. Schulze Sent: Tuesday, May 4, 2021 10:32 PM To: dns-operations at lists.dns-oarc.net Subject: Re: [dns-operations] validating zones before distribution to secondaries Am 04.05.21 um 20:53 schrieb Phil Regnauld: > On the validation side, take a look at: > > https://github.com/tobez/validns validns seem to be unmaintained. Build fail with current openssl :/ _______________________________________________ dns-operations mailing list dns-operations at lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations From regnauld at nsrc.org Wed May 5 09:11:01 2021 From: regnauld at nsrc.org (Phil Regnauld) Date: Wed, 5 May 2021 11:11:01 +0200 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: References: <20210504185359.GQ32158@macbook.x0.dk> <22bfdb6a-7e0f-fe6b-ddad-52bf8522855f@andreasschulze.de> Message-ID: <20210505091101.GA32158@macbook.x0.dk> The DENIC version might be more up to date. Either way, I'll be working with the current maintainer at integrating DENIC fixes and other outstanding PRs, icluding improving support for newer algorithms. Alternatively, offers to take over maintenance will be seriously considered :) If it's a tool enough organizations find useful, it could certainly be transferred to a place like OARC (thinking out loud). Cheers, Phil Robert Mortimer (Robert.Mortimer) writes: > Also Validns isn't happy with all of the current DNSSEC algorithms. > > -----Original Message----- > From: dns-operations On Behalf Of A. Schulze > Sent: Tuesday, May 4, 2021 10:32 PM > To: dns-operations at lists.dns-oarc.net > Subject: Re: [dns-operations] validating zones before distribution to secondaries > > > > Am 04.05.21 um 20:53 schrieb Phil Regnauld: > > On the validation side, take a look at: > > > > https://github.com/tobez/validns > > validns seem to be unmaintained. Build fail with current openssl :/ > > > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations From benno at NLnetLabs.nl Thu May 6 22:57:07 2021 From: benno at NLnetLabs.nl (Benno Overeinder) Date: Fri, 7 May 2021 00:57:07 +0200 Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: References: Message-ID: Hi Klaus, On 04/05/2021 15:59, Klaus Darilion wrote: > In my setup I receive zones from various hidden primaries to my > "incoming" nameserver. Before my "distribution" nameserver fetches the > zone from the "incoming" nameserver (and hence sends NOTIFYs to the > public secondaries) I I want to perform various checks on the zone > loaded on the incoming nameserver. > We are close to release CreDNS in NSD4. CreDNS is a module in NSD4 that works as a gatekeeper between the zone transfer and serving the zone. The validation can be done by an external program like ldns-verify-zone or a resolver if you want to verify the zone partially (e.g. after an IXFR). See also the slides and search for "CreDNS" in https://nlnetlabs.nl/downloads/presentations/20191013_CENTRTech41-ODS-CreDNS.pdf. Cheers, --Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/ From edward.lewis at icann.org Fri May 7 14:14:39 2021 From: edward.lewis at icann.org (Edward Lewis) Date: Fri, 7 May 2021 14:14:39 +0000 Subject: [dns-operations] ROW#10 - Final call for proposals Message-ID: <2F45A73D-CD50-4666-91AE-7F8AB535D10C@icann.org> ROW#10: Register now & submit your proposal before May 14th, 2021 The 10th Registration Operations Workshop [regiops.net] (ROW#10) is scheduled to take place via remote participation on June 8th, 2021, 13:00 - 16:00 UTC. IMPORTANT: Registration is required to enable participation! Those interested in attending the virtual meeting are required to register at the following link in order to receive the access information for the online session: https://regiops.net/events/row10registration/ [regiops.net] Please note that the call for presentation and panel proposals is still active. Proposals in the form of a short abstract shall be submitted to row at viagenie.ca. Deadline is May 14th, 2021. Discussions of workshop topics may also take place on the regiops at googlegroups.com mailing list. In keeping with the Registration Operations' focus of the ROW, possible topics for this session could be: ? RDAP implementation experience ? DNS abuse ? DNS privacy and encryption ? Differentiated access ? Authentication and authorization ? Credential Security/Credential Management ? DNSSEC operationalization (CSYNC, managing transfers of secured domains) ? Registration support functions (data escrow/business continuity) ? Automation ? Other innovative uses for registration and resolution technologies Please feel free to disseminate this Call to other lists where it might be of interest. We look forward to your participation! For additional event details and previous ROW sessions, please visit https://regiops.net [regiops.net]. ROW Program Committee Stay tuned for further updates! Follow @ROW_by_Viagenie [twitter.com] ROW website: https://regiops.net [regiops.net] Contact us: row at viagenie.ca ROW mailing list: regiops at googlegroups.com ROW series: co-sponsored by Verisign [verisign.com] & ICANN, organized by Viagenie [viagenie.ca] (cross-posting to multiple lists - sorry for any duplicates) -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at nohats.ca Mon May 10 22:49:40 2021 From: paul at nohats.ca (Paul Wouters) Date: Mon, 10 May 2021 18:49:40 -0400 (EDT) Subject: [dns-operations] validating zones before distribution to secondaries In-Reply-To: <20210505091101.GA32158@macbook.x0.dk> References: <20210504185359.GQ32158@macbook.x0.dk> <22bfdb6a-7e0f-fe6b-ddad-52bf8522855f@andreasschulze.de> <20210505091101.GA32158@macbook.x0.dk> Message-ID: <3874e0e8-899-8be6-9df-33effa478e32@nohats.ca> On Wed, 5 May 2021, Phil Regnauld wrote: > The DENIC version might be more up to date. Either way, I'll be working > with the current maintainer at integrating DENIC fixes and other outstanding > PRs, icluding improving support for newer algorithms. That would be great and I will fold those back into the fedora/epel package. > Alternatively, offers to take over maintenance will be seriously considered :) > If it's a tool enough organizations find useful, it could certainly be > transferred to a place like OARC (thinking out loud). That would also be great. I think it is valuable to have different tools written by different DNS people/vendors so we can validate the validators :) Paul From moritz.muller at sidn.nl Wed May 12 13:52:54 2021 From: moritz.muller at sidn.nl (=?utf-8?Q?Moritz_M=C3=BCller?=) Date: Wed, 12 May 2021 15:52:54 +0200 Subject: CDS/CDNSKEY deployment survey Message-ID: <8E7FD986-8F96-4840-895D-FF6AD1B0D6C1@sidn.nl> Hi all, I?m working at the .nl registry and am currently supervising a bachelor student at the University of Twente, the Netherlands. He is looking into the deployment of RFC 7344 and RFC 8078 (CDS/CDNSKEY). You could help him a lot if you could take the time to fill out his short survey below, especially if you are a TLD operator. Thanks a lot! ?????????? Hello, For my BSc Research Project at the Technical Computer Science study of the University of Twente in the Netherlands, I am performing research on the current state of DNSSEC automated provisioning support, as specified in RFC 7344 and RFC 8078. Part of this research focuses on the current state of support at TLD registries. To gather information on this, I have set up a short questionnaire, which only takes about 2-5 minutes to fill out, depending on the amount of detail you want to provide. Filling out this form would be greatly appreciated: https://forms.gle/KWoLdvJTPSWNPXwP6. The findings of this research will be made available to the public. Kind regards, Wilco van Beijnum University of Twente ?????????? Best, Moritz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From puneets at google.com Wed May 12 16:53:22 2021 From: puneets at google.com (Puneet Sood) Date: Wed, 12 May 2021 12:53:22 -0400 Subject: [dns-operations] Google public DNS sometimes forwards incomplete subset of NSEC RRs In-Reply-To: References: <20200901054817.GO44511@straasha.imrryr.org> <20200916203124.GA64864@straasha.imrryr.org> Message-ID: Viktor, dnsop community, If there additional missing NSEC|NSEC3 RR issues with Google Public DNS you are aware of, please respond here or file a ticket (https://developers.google.com/speed/public-dns/groups#issue_tracker). On Sat, Feb 6, 2021 at 1:17 AM Viktor Dukhovni wrote: > > > On Sep 16, 2020, at 6:31 PM, Viktor Dukhovni wrote: > > > > Now it is Google's turn. I still see an incomplete NSEC3 RRset from 8.8.8.8: > > > > $ hsdig -n8.8.8.8 -D -t tlsa _25._tcp.mx.runbox.com > > _25._tcp.mx.runbox.com. IN TLSA ? ; NoError AD=1 > > runbox.com. IN SOA dns61.copyleft.no. hostmaster at copyleft.no. 3000008499 14400 3600 1296000 3600 > > runbox.com. IN RRSIG SOA 13 2 86400 20200930104345 20200916091345 18202 runbox.com. > > *.runbox.com. IN NSEC _acme-challenge.runbox.com. A MX RRSIG NSEC > > *.runbox.com. IN RRSIG NSEC 13 2 3600 20200930104345 20200916091345 18202 runbox.com. > > I am seeing this issue again, intermittently from various Google > DNS servers. Here's an example from 8.8.4.4: > > _25._tcp.mx.runbox.com. IN TLSA ? ; NoError AD=1 > runbox.com. IN SOA dns61.copyleft.no. hostmaster at copyleft.no. 3000008714 14400 3600 1296000 3600 > runbox.com. IN RRSIG SOA 13 2 86400 20210219161924 20210205144924 12629 runbox.com. > *.runbox.com. IN NSEC _acme-challenge.runbox.com. A MX RRSIG NSEC > *.runbox.com. IN RRSIG NSEC 13 2 3600 20210219161924 20210205144924 12629 runbox.com. I can reproduce the issue internally. A fix should be coming in the near future. > > Or DNSViz (3 of the four public IPs): > > https://dnsviz.net/d/_25._tcp.mx.runbox.com/e/437682/dnssec/ > > -- > Viktor. > > > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations From ekgermann at gmail.com Mon May 17 18:34:37 2021 From: ekgermann at gmail.com (Eric Germann) Date: Mon, 17 May 2021 14:34:37 -0400 Subject: [dns-operations] DNSSEC and multiple signatures Message-ID: I have a question regarding multiple signings. I?ve seen some domains sign with multiple algorithms (8 and 13 specifically). How does a validating resolver choose which signature to use. First available? Stronger crypto? Both have to be valid through the chain? Random? Than --- Eric Germann ekgermann(at)semperen(dot)com || ekgermann(at)gmail(dot)com LinkedIn: https://www.linkedin.com/in/ericgermann Twitter: @ekgermann GPG Fingerprint: 89ED 36B3 515A 211B 6390 60A9 E30D 9B9B 3EBF F1A1 Telegram||Signal +1(dash)419(dash)513(dash)0712 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at wander.science Mon May 17 23:07:42 2021 From: mail at wander.science (=?UTF-8?Q?Matth=c3=a4us_Wander?=) Date: Tue, 18 May 2021 01:07:42 +0200 Subject: [dns-operations] DNSSEC and multiple signatures In-Reply-To: References: Message-ID: <96561a7f-b59d-bc88-0cf9-e279f2e385cc@wander.science> Eric Germann wrote on 2021-05-17 20:34: > I have a question regarding multiple signings.? I?ve seen some domains > sign with multiple algorithms (8 and 13 specifically). > > How does a validating resolver choose which signature to use.? First > available?? Stronger crypto?? Both have to be valid through the chain?? > Random? The resolver attempts validation of all signatures (for which it has algorithm support) until it finds one that validates correctly. One valid signature suffices. Regards, Matt From ietf-dane at dukhovni.org Tue May 18 00:10:06 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 17 May 2021 20:10:06 -0400 Subject: [dns-operations] DNSSEC and multiple signatures In-Reply-To: References: Message-ID: On Tue, May 18, 2021 at 01:07:42AM +0200, Matth?us Wander via dns-operations wrote: > > How does a validating resolver choose which signature to use.? First > > available?? Stronger crypto?? Both have to be valid through the chain?? > > Random? > > The resolver attempts validation of all signatures (for which it has > algorithm support) until it finds one that validates correctly. One > valid signature suffices. That's likely typical, but there may resolvers out there that will pick the strongest (in their estimation) supported algorithm, and require that one to work. Bottom line: make sure *all* your signatures are valid, if you sign with multiple algorithms... -- Viktor. From edward.lewis at icann.org Wed May 19 20:18:28 2021 From: edward.lewis at icann.org (Edward Lewis) Date: Wed, 19 May 2021 20:18:28 +0000 Subject: [dns-operations] [Ext] Re: DNSSEC and multiple signatures In-Reply-To: References: Message-ID: <798287C5-B32D-4909-A18D-0A900AD284E4@icann.org> On 5/17/21, 8:15 PM, "dns-operations on behalf of Viktor Dukhovni" wrote: >Bottom line: make sure *all* your signatures are valid, if you sign >with multiple algorithms... I disagree with that advice. Building a truly verifiable (following all the rules as well as cryptographic calculations) chain of trust is hard enough that having one chain is sufficient reason to accept a data set as authentic and complete. (Note though that an authentic and complete data set may not be the latest version or even correct.) But reading Viktor's statement over and over, perhaps I should clarify: When signing - "don't screw up", yes, do your utmost to: make sure *all* of your signatures are valid, (whether or not) if you sign with multiple algorithms. But when signing, data changes and you may publish a signature in one moment and a new data set (with a new signature) in the next moment (new zone serial number). When validating - the world looks different because of that. A validator ought to be satisfied with any single complete chain. A broken signature alongside a working signature might be a case of a software bug in a crypto-library or signature preparation. In a time when data sets are changing, it's possible that a wonky verifier might confuse an older signature with a newer set. (This is what was anticipated in the days of yore when the protocol was assembled.) And we anticipated this - if one wanted to DOS a data set that was DNSSEC signed, just add a garbage signature to the message. If the validator tossed the set at the sight of a failed chain, you'd accomplish your goal. Generating garbage to bring something down is much easier than forging a signature. Ok, not exactly the same vulnerability, but we really can't anticipate what an adversary might want to do, other than disrupt a service. There was a validator once (name withheld to protect the guilty, many will know the case) that failed data sets when it saw a set signed with one algorithm and had a valid chain, but then saw a second algorithm in the authoritative zone's DNSKEY set. Although a signer must generate signatures of all algorithms in a zone's DNSKEY set, this rule does not apply in validation. Why? Because the validator might be getting a copy of the data set emitted before the new key was published in the DNSKEY set. Validators can't assume that all the data sets for a zone (or even a name) are from the same zone serial number. Morale: DNSSEC makes the DNS more brittle (by eliminating protocol states that are questionable). Don't over tighten it. From edward.lewis at icann.org Wed May 19 20:18:28 2021 From: edward.lewis at icann.org (Edward Lewis) Date: Wed, 19 May 2021 20:18:28 +0000 Subject: [dns-operations] [Ext] Re: DNSSEC and multiple signatures In-Reply-To: References: Message-ID: <798287C5-B32D-4909-A18D-0A900AD284E4@icann.org> On 5/17/21, 8:15 PM, "dns-operations on behalf of Viktor Dukhovni" wrote: >Bottom line: make sure *all* your signatures are valid, if you sign >with multiple algorithms... I disagree with that advice. Building a truly verifiable (following all the rules as well as cryptographic calculations) chain of trust is hard enough that having one chain is sufficient reason to accept a data set as authentic and complete. (Note though that an authentic and complete data set may not be the latest version or even correct.) But reading Viktor's statement over and over, perhaps I should clarify: When signing - "don't screw up", yes, do your utmost to: make sure *all* of your signatures are valid, (whether or not) if you sign with multiple algorithms. But when signing, data changes and you may publish a signature in one moment and a new data set (with a new signature) in the next moment (new zone serial number). When validating - the world looks different because of that. A validator ought to be satisfied with any single complete chain. A broken signature alongside a working signature might be a case of a software bug in a crypto-library or signature preparation. In a time when data sets are changing, it's possible that a wonky verifier might confuse an older signature with a newer set. (This is what was anticipated in the days of yore when the protocol was assembled.) And we anticipated this - if one wanted to DOS a data set that was DNSSEC signed, just add a garbage signature to the message. If the validator tossed the set at the sight of a failed chain, you'd accomplish your goal. Generating garbage to bring something down is much easier than forging a signature. Ok, not exactly the same vulnerability, but we really can't anticipate what an adversary might want to do, other than disrupt a service. There was a validator once (name withheld to protect the guilty, many will know the case) that failed data sets when it saw a set signed with one algorithm and had a valid chain, but then saw a second algorithm in the authoritative zone's DNSKEY set. Although a signer must generate signatures of all algorithms in a zone's DNSKEY set, this rule does not apply in validation. Why? Because the validator might be getting a copy of the data set emitted before the new key was published in the DNSKEY set. Validators can't assume that all the data sets for a zone (or even a name) are from the same zone serial number. Morale: DNSSEC makes the DNS more brittle (by eliminating protocol states that are questionable). Don't over tighten it. From pirawat.w at ku.th Fri May 21 05:40:08 2021 From: pirawat.w at ku.th (Pirawat WATANAPONGSE) Date: Fri, 21 May 2021 12:40:08 +0700 Subject: What did I do wrong?: b.in-addr-servers.arpa refused to answer my query Message-ID: Dear OARC gurus, When I used DNSviz to check my 0.0.1.3.6.0.4.2.ip6.arpa reverse-zone, I got a PTR-type error on the zone itself which should not happen. [Evidence: https://dnsviz.net/d/0.0.1.3.6.0.4.2.ip6.arpa/dnssec/] Running dig on b.in-addr-servers.arpa which supposedly is one of the upstream-authoritative servers of my zone, I get a ?REFUSED? status back. I guess that's the reason DNSviz threw an error at me. [Command: dig +all +cmd +question +answer +authority +additional +comments +stats +multiline +noshort @b.in-addr-servers.arpa 0.0.1.3.6.0.4.2.ip6.arpa PTR] What did I do wrong? How can I fix it? Thanks in advance for all your help. Best Regards, Pirawat. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Fri May 21 06:00:26 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 21 May 2021 02:00:26 -0400 Subject: [dns-operations] What did I do wrong? In-Reply-To: References: Message-ID: On Fri, May 21, 2021 at 12:40:08PM +0700, Pirawat WATANAPONGSE via dns-operations wrote: > Running dig on b.in-addr-servers.arpa which supposedly is one of the > upstream-authoritative servers of my zone, I get a ?REFUSED? status back. Tne nameservers for ip6.arpa are not the same as the nameservers for in-addr.arpa. Your query should be directed to b.ip6-servers.arpa, and should include the "norecur" flag. $ dig -t ptr +norecur +question @b.ip6-servers.arpa 0.0.1.3.6.0.4.2.ip6.arpa ; <<>> DiG 9.16.13 <<>> -t ptr +norecur +question @b.ip6-servers.arpa 0.0.1.3.6.0.4.2.ip6.arpa ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49402 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;0.0.1.3.6.0.4.2.ip6.arpa. IN PTR ;; AUTHORITY SECTION: 0.4.2.ip6.arpa. 86400 IN NS ns2.apnic.net. 0.4.2.ip6.arpa. 86400 IN NS ns3.lacnic.net. 0.4.2.ip6.arpa. 86400 IN NS apnic.authdns.ripe.net. 0.4.2.ip6.arpa. 86400 IN NS rirns.arin.net. 0.4.2.ip6.arpa. 86400 IN NS apnic1.dnsnode.net. ;; Query time: 9 msec ;; SERVER: 199.253.182.182#53(199.253.182.182) ;; WHEN: Fri May 21 01:53:10 EDT 2021 ;; MSG SIZE rcvd: 192 Which reveals a delegation to apnic et. al. Trying there one sees a further delegation to ku.ac.th: $ dig -t ptr +norecur +question @ns2.apnic.net. 0.0.1.3.6.0.4.2.ip6.arpa ; <<>> DiG 9.16.13 <<>> -t ptr +norecur +question @ns2.apnic.net. 0.0.1.3.6.0.4.2.ip6.arpa ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31180 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 8d658667824256180100000060a74b3d7994ae1e39965fd2 (good) ;; QUESTION SECTION: ;0.0.1.3.6.0.4.2.ip6.arpa. IN PTR ;; AUTHORITY SECTION: 0.0.1.3.6.0.4.2.ip6.arpa. 86400 IN NS ns2.ku.ac.th. 0.0.1.3.6.0.4.2.ip6.arpa. 86400 IN NS ns.ku.ac.th. ;; Query time: 3 msec ;; SERVER: 203.119.95.53#53(203.119.95.53) ;; WHEN: Fri May 21 01:55:09 EDT 2021 ;; MSG SIZE rcvd: 124 Following that referral, we finally run into a serious issue, those nameservers don't appear to support PTR queries for IPv6 addresses: $ dig -t ptr +norecur +question @ns.ku.ac.th 0.0.1.3.6.0.4.2.ip6.arpa ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ; <<>> DiG 9.16.13 <<>> -t ptr +norecur +question @ns.ku.ac.th 0.0.1.3.6.0.4.2.ip6.arpa ; (2 servers found) ;; global options: +cmd ;; connection timed out; no servers could be reached $ dig -t ptr +norecur +question @ns2.ku.ac.th 0.0.1.3.6.0.4.2.ip6.arpa ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ;; ;; Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN ; <<>> DiG 9.16.13 <<>> -t ptr +norecur +question @ns2.ku.ac.th 0.0.1.3.6.0.4.2.ip6.arpa ; (2 servers found) ;; global options: +cmd ;; connection timed out; no servers could be reached -- Viktor. From ryan.m.stephenson2.civ at mail.mil Wed May 26 11:48:50 2021 From: ryan.m.stephenson2.civ at mail.mil (Stephenson, Ryan M CIV DISA IE (USA)) Date: Wed, 26 May 2021 11:48:50 +0000 Subject: DNSSEC issues with cicimar.ipn.mx In-Reply-To: References: Message-ID: Is there anyone on the mail list from cicimar.ipn.mx? There are some issues with DNSSEC. https://dnsviz.net/d/cicimar.ipn.mx/dnssec/ Ryan Stephenson Defense Information Systems Agency DoD NIC IE721 COM: 614-692-5284 | DSN: 312-850-5284 UE: ryan.m.stephenson2.civ at mail.mil CE: ryan.m.stephenson2.civ at mail.smil.mil iPhone: (614) 769-1921 From edward.lewis at icann.org Fri May 28 19:06:05 2021 From: edward.lewis at icann.org (Edward Lewis) Date: Fri, 28 May 2021 19:06:05 +0000 Subject: [dns-operations] The 10th Registration Operations Workshop (ROW#10) | June 8th, 2020 | 13:00 - 17:00 UTC Message-ID: The 10th Registration Operations Workshop (ROW#10) | June 8th, 2020 | 13:00 - 17:00 UTC ROW#10 will take place via Zoom Webinar platform on Tuesday, June 8th, 2021, 13:00 ? 17:00 UTC. Additional time zones may be checked here. Those interested in attending are required to register in order to receive the access information (meeting ID and password). For details regarding the agenda, check out Marc Blanchet?s [Viagenie] recent blog post or visit https://regiops.net. If you have any questions, please contact us at row at viagenie.ca. We would like to thank our ROW Series Sponsors ICANN and Verisign for their continued support. ----- Here are some special tips if this is your first time using Zoom or you wish to get more familiar with its web conferencing capabilities: ? Download the Zoom application to your computer or mobile phone. You can do it at https://zoom.us/download. You will also be prompted to download and install Zoom when you click the link to join. You can also run Zoom from your web browser by navigating to join.zoom.us and entering the meeting number and passcode. ? Want to try it out before June 8th? Join a test meeting at https://zoom.us/test anytime to familiarize yourself with Zoom. You can also access Zoom tutorials here: https://support.zoom.us/hc/en-us/articles/201362193-How-Do-I-Join-A-Meeting- ? As an attendee, you will be muted. For questions and comments, please use the Q&A feature. The session moderator will address them to the speakers on the mike as time permits. Questions that cannot be answered due to time constraints, will be answered directly in the Q&A window or by email. ? You do not have to use the Zoom web conferencing platform with video to participate. There is an option to call-in only. ? We will be recording this webinar, including the chat, and making it available on our website 48h after the session. ----- We look forward to seeing you online! ROW Program Committee Stay tuned for further updates! Follow @ROW_by_Viagenie ROW website: https://regiops.net Contact us: row at viagenie.ca ROW mailing list: regiops at googlegroups.com ROW series: co-sponsored by Verisign & ICANN, organized by Viagenie (cross-posting to multiple lists - sorry for any duplicates) -------------- next part -------------- An HTML attachment was scrubbed... URL: