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