[dns-operations] Organizing DNS-OARC's "DITL 2024" collection

[Apologies to those who have seen this on multiple lists.] OARC is beginning planning for the 2024 Day in the Life (DITL) collection. Community DNS operators who wish to participate in the collection, and have not already done so, should join the d...@lists.dns-oarc.net mailing list[0] in the

Re: [dns-operations] cmdns.dev.dns-oarc.net down?

On Tue, Sep 5, 2023 at 6:58 AM Christoph via dns-operations wrote: > > in case that is useful: dns.google was also unable to reach the > nameservers at the time. What Jerry is saying is that the CMDNS application consists (in part) of a custom DNS server. The application was down, hence no DNS

Re: [dns-operations] Why is DNS still hard to learn?

On Mon, Jul 31, 2023 at 12:42 PM Vladimír Čunát via dns-operations wrote: > > > > For reference, in May there was a (slightly heated) discussion about this > article on OARC's public chat: > https://chat.dns-oarc.net/community/pl/ccajpprxttnmzj5a8mh4hh1kua Same author, different article.

Re: [dns-operations] in-addr.arpa. "A" server "loopback network" misconfiguration

On Thu, Jun 22, 2023 at 10:44 AM Viktor Dukhovni wrote: > > > Which of the below would you suggest? > > SOA rname:ns...@iana.org > WHOIS Administrative: i...@iab.org > WHOIS Technical: tld-cont...@iana.org I would have started with the IANA addresses, since they

Re: [dns-operations] in-addr.arpa. "A" server "loopback network" misconfiguration

Have you tried contacting the IANA or the IAB? Those are the two organizations responsible for the technical and administrative for that zone... and I note that neither of them are copied on your email. Directly reaching out to either or both of them may be more productive than posting to

[dns-operations] MastoDNS opening up to DNS community registration

For several months, DNS-OARC has been operating a DNS community Mastodon instance at MastoDNS.net. Up until now it has only been open to OARC Member & Supporter organizations, but we would now like to invite the wider DNS community to join us. MastoDNS will join our mailing lists, Mattermost

[dns-operations] Upcoming DITL 2023 collection

OARC is beginning planning for the 2023 Day in the Life (DITL) collection. Community DNS operators who wish to participate in the collection, and have not already done so, should join the d...@lists.dns-oarc.net mailing list[0] in the next week or so. Announcements will be made in early February,

Re: [dns-operations] OARC chat server outage

OARC’s chat server is back up and accessible now. The hosting company thinks they’ve identified the issue, and has made changes to avoid it reoccurring. We expect this to be resolved, now. Thanks for your patience everyone. Matt Pounsett DNS-OARC Systems Engineering signature.asc

[dns-operations] OARC chat server outage

Those of you on the Mattermost server may have noticed that it is offline. It appears that some runaway logging filled up the disk and took out the back-end database. I’m working with the managed hosting company that runs the service to sort out why. While we can

[dns-operations] DNS-OARC 2022 Day In The Life announcement

OARC is beginning planning for the 2022 Day in the Life (DITL) collection. Community DNS operators who wish to participate in the collection, and have not already done so, should join the d...@lists.dns-oarc.net mailing list[0] in the next week or so. Announcements will be made in early February,

Re: [dns-operations] DNSviz and G-root: EDNS issue?

On Tue, 12 Oct 2021 at 11:24, Keith Mitchell wrote: > > This might be a known intermittent IPv6 routing issue with DNSviz, do > you see this problem for v4 and/or v6 ? That would show up as a non-answer over IPv6, rather than an apparent PMTU/EDNS problem.

Re: [dns-operations] slack.com bogus

On Thu, 30 Sept 2021 at 14:34, vom513 wrote: > > > So perhaps a dumb question - could Google and Cloudflare be hitting some kind > of “manual overrride” to not validate a given zone - i.e. human intervention > / look the other way ? Negative Trust Anchors, most probably. It's standard

[dns-operations] Planning the 2021 DITL collection

OARC is beginning planning for the 2021 Day in the Life (DITL) collection. Community DNS operators who wish to participate in the collection, and have not already done so, should join the d...@lists.dns-oarc.net mailing list[0] in the next few days. Announcements will be made on Friday, on

Re: [dns-operations] Support for ED25519/ED448 DS records by OpenSRS

On Sat, 20 Feb 2021 at 06:50, Simon Arlott via dns-operations < dns-operati...@dns-oarc.net> wrote: > > > Can you recommend another registrar that supports DNSSEC? > Gandi.NET appears to support .au, and they have a very nice API for delegation management (they also support CDS/CDNSKEY).

Re: [dns-operations] DNSViz please support DNSSEC algorithm Ed25519 (15)

> On Dec 30, 2020, at 06:42, Arsen STASIC wrote: > > Dear DNS-OARC, > > Could you please support DNSSEC algorithm Ed25519 (15)? > I think Casey Deccio has already added support for Ed25519. [0] Hi Arsen. First, it’s generally better to address mail to OARC to an OARC address — we usually

[dns-operations] Shutdown of OARC's ODVR service

For a little over ten years, OARC has been operating the Open DNSSEC Validating Resolver service (ODVR), which consists of one instance each of BIND and Unbound, open to the Internet. The service was originally intended as a way to allow people to test DNSSEC operations and software

Re: [dns-operations] New OARC Chat Platform

On Tue, 25 Aug 2020 at 13:09, Fred Morris wrote: > That's a basic question which should be asked about any technology or > service offering: why? what purpose is it intended to serve? By their > actions clearly some people agree and some people disagree with me. Since > it's a members-only

[dns-operations] New OARC Chat Platform

Hello everyone. DNS OARC is pleased to announce that our new community chat server is open for access, augmenting the mailing lists we operate. For many years, OARC has been operating a Jabber service which has been available to OARC Members. We are replacing that service with a more modern

Re: [dns-operations] 2020 Flag Day

> On Aug 3, 2020, at 11:34, jack tavares wrote: > > Hello - > I have just subscribed to this list and before asking a question that has > been asked before, > is there an archive of the list somewhere? > I did not see one when I subscribed and the confirmation message does not > point to

Re: [dns-operations] DNSViz Access to C-root

> On Jul 2, 2020, at 15:02, Alarig Le Lay wrote: > > > I’m also curious, from the NLNOG ring LG, HE doesn’t see C and Cogent > doesn’t see DNSViz: We have unfortunately not managed to magically solve the connectivity problem between HE and Cogent, so there is no expectation that

[dns-operations] DNSViz Access to C-root

We’re pleased to announce that, as of the beginning of June, OARC and Cogent have had in place a solution to the reachability problem between DNSViz and C-Root over IPv6. The lack of a v6 path between Hurricane Electric and Cogent has been a long-standing problem, and since OARC is

Re: [dns-operations] Test Zone Metalist

Thanks to everyone for all the info! That’s a ton of stuff I had no idea about. I’ll try to organize it all into a useful list to post online (on the OARC web site), so hopefully this should be searchable the next time someone’s interested in finding test data for just the right thing. I’ll

[dns-operations] Test Zone Metalist

On the suggestion of some community members, I’m considering setting up a list of known DNS test zones to be posted on OARC’s web site. The list will include zones designed to provide data to use as input to DNS software. Off the top of my head, and with five minutes of googling, I know of

Re: [dns-operations] DNSViz Service Restoration

> On Mar 12, 2020, at 07:04, Jim Popovitch via dns-operations > wrote: > > > From: Jim Popovitch > Subject: Re: [dns-operations] DNSViz Service Restoration > Date: March 12, 2020 at 07:04:23 EDT > To: dns-operations@lists.dns-oarc.net > > > On March 12, 2020 5:04:23 AM UTC, Casey Deccio

[dns-operations] DNSViz Service Restoration

Hi all! OARC is happy… no, ecstatic… to announce that the DNSViz historical functions have been restored! Users will now be seeing full functionality from the site at . A few weeks ago we made the decision to temporarily put aside the attempt to completely restore the

Re: [dns-operations] [Ext] Re: Is this DNS Flag Day 2020 including 'in-addr.arpa.' and 'ip6.arpa.' clean-up?

On Wed, 19 Feb 2020 at 11:43, Pirawat WATANAPONGSE wrote: > Well, let’s look at the real netblock, shall we? (‘cause I have nothing to > hide) > You can see for yourself at > https://dnsviz.net/d/108.158.in-addr.arpa/dnssec/ > > I don't really see any of these things as flag-day level problems.

Re: [dns-operations] [Ext] Re: help with a resolution

On Fri, 10 Jan 2020 at 08:08, Matthew Pounsett wrote: > > > On Thu, 9 Jan 2020 at 20:47, Tony Finch wrote: > >> I saw the Eurocrypt SHA-1 chosen-prefix attack last year but I didn't >> think about the consequences. As soon as I saw the SHAmbles announcement I >> r

Re: [dns-operations] [Ext] Re: help with a resolution

On Thu, 9 Jan 2020 at 20:47, Tony Finch wrote: > I saw the Eurocrypt SHA-1 chosen-prefix attack last year but I didn't > think about the consequences. As soon as I saw the SHAmbles announcement I > realised what it actually meant and that DNSSEC was in serious trouble. > > What are the

Re: [dns-operations] root? we don't need no stinkin' root!

On Wed, 11 Dec 2019 at 08:24, Jim Reid wrote: > > In principle, they could all change at once, In reality, they don’t. > > This absolutely does happen. I've been at the helm of several operator changes on TLDs that saw all the NS

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

On Thu, 10 Oct 2019 at 17:26, Jared Mauch wrote: > On Thu, Oct 10, 2019 at 01:56:11PM -0700, Randy Bush wrote: > > >> Neither Cogent or HE buy transit from anybody else > > > > i believe this statement to be false > > i know of at least 2 transit providers.. > Both providing v4 transit,

Re: [dns-operations] glitch on [ip6|in-addr].arpa?

On Wed, 9 Oct 2019 at 22:57, Viktor Dukhovni wrote: > On Wed, Oct 09, 2019 at 05:41:43PM -0400, Viktor Dukhovni wrote: > > > No, even small responses receive no answers from the IPv6 addresses > > of the C and F roots. Both of the below time out even though I'm > > not setting the "DO" bit: > >

[dns-operations] DNSViz Update: Final Stretch (we hope!)

Hi everyone. It’s been several weeks since my last update on the current status of the DNSViz historical data, and at least a couple of weeks since I last estimated we’d be up and running. Here’s a quick summary of what’s been happening, including some of the history for those who have missed

Re: [dns-operations] Fwd: Re: [Security] Glue or not glue?

On Jun 9, 2015, at 23:35 , Dave Warren da...@hireahit.com wrote: To me, the main problem isn't verifying the nameservers before delegation, but rather, the fact that an authoritative server cannot reliably get themselves removed once delegation is established. At most, an authoritative

Re: [dns-operations] [Security] Glue or not glue?

On Jun 10, 2015, at 16:02 , Mark E. Jeftovic mar...@easydns.com wrote: In the (very rare) case of my name servers receiving unwanted traffic in this way, I’ve treated it as an abuse issue. Report to abuse@ the organization that’s doing the delegation that they’re generating undated

Re: [dns-operations] Saga of HBONow DNSSEC Failure

On Mar 9, 2015, at 23:50 , Livingood, Jason jason_living...@cable.comcast.com wrote: So earlier today HBO announced a new HBONow streaming service (at an Apple event). The FQDN to order, which should have been DNSSEC-enabled, was order.hbonow.com. This unfortunately suffered from a rather

Re: [dns-operations] Root-servers returning TC=1 after 5 NXDOMAINS

On Feb 10, 2015, at 09:06 , Emil Natan shly...@gmail.com wrote: If this is an issue with the F-root only it would be easier to use hints file with the F excluded instead of managing local root zone and keeping it up to date. This is Response Rate Limiting in action… they’re not explicitly

Re: [dns-operations] cool idea regarding root zone inviolability

On Nov 28, 2014, at 02:07 , Paul Vixie p...@redbarn.org wrote: is there some reason why an updated sig(0) is not a solution to this? People move zone data around using mechanisms other than *XFR (scp, database replication, etc.). A signature on the complete zone, as part of the zone,

Re: [dns-operations] cool idea regarding root zone inviolability

On Nov 29, 2014, at 17:57 , Paul Vixie p...@redbarn.org wrote: here, i'm specifically thinking of zones so large that touching every byte of their content is a multiple-minutes cost. Those zones are relatively rare though, and reading a randomly-written mmaped file isn’t a common name

Re: [dns-operations] Workshop on DNS Future Root Service Architecture (2014 WDFRSA), Hong Kong, December 8-9, 2014

On Nov 14, 2014, at 04:14 , Paul Vixie p...@redbarn.org wrote: Registration is now open for the 2014 Workshop on DNS Future Root Service Architecture (2014 WDFRSA) Location: Hong Kong, HK Venue: The Mira Hotel (Kowloon district) Date: December 8-9, 2014 Hosted by: ISOC-HK

Re: [dns-operations] resolvers considered harmful

On Oct 22, 2014, at 23:03 , Mark Allman mall...@icir.org wrote: The paper quantifies this cost for .com. We find that something like 1% of the records change each week. So, while increasing the TTL from the current two days to one week certainly sacrifices some possible flexibility, in

Re: [dns-operations] resolvers considered harmful

On Oct 23, 2014, at 11:59 , Andrew Sullivan a...@anvilwalrusden.com wrote: Also, as I already noted, modelling this in a delegation-centric zone uses the wrong model. Moreover, the data sets are from a notably tiny shared-iterative-resolver community. It seems to me that understanding the

Re: [dns-operations] resolvers considered harmful

On Oct 23, 2014, at 12:28 , Stephane Bortzmeyer bortzme...@nic.fr wrote: On Wed, Oct 22, 2014 at 12:47:39PM -0400, Mark Allman mall...@icir.org wrote a message of 64 lines which said: Short paper / crazy idea for your amusement ... The biggest problem I have with this paper is of

Re: [dns-operations] resolvers considered harmful

On Oct 23, 2014, at 15:18 , Mark Allman mall...@icir.org wrote: How does this compare to resolvers with one or two (or four) orders of magnitude more clients behind them? Presumably pretty well. I only know of old results here, but Jung's IMW 2001 paper suggests that the cache hit rate

Re: [dns-operations] resolvers considered harmful

On Oct 23, 2014, at 18:23, Matthew Pounsett m...@conundrum.com wrote: The cache hit rate may level off, but the query rate to the caching recursive doesn’t. Sorry, that should have said the cache *miss* rate. It's an asymptote maxing out at the TTL, dependent on the population behind

Re: [dns-operations] resolvers considered harmful

On Oct 22, 2014, at 13:16 , Andrew Sullivan a...@anvilwalrusden.com wrote: On Wed, Oct 22, 2014 at 12:47:39PM -0400, Mark Allman wrote: leaving recursive resolution to the clients. We show that the two primary costs of this approach---loss of performance and an increase in system

[dns-operations] 2014 Fall DNS-OARC Workshop PGP Keysigning

I've heard a couple reports that attendees at the meeting this weekend did not receive an email I sent through Indico about the PGP keysigning at the meeting. Apologies for that.. I'm using this email to dns-operations to compensate. The keysigning party will be during the second half of

Re: [dns-operations] An simple observation

On Sep 24, 2014, at 21:27 , Davey Song songlinj...@gmail.com wrote: Hi everyone, I‘m recently doing a little survey on the penetration of IPv6 in DNS system and it's latent problems. I find that top websites like Google, Wikipedia,Yahoo already support IPv6 access, but its name servers

Re: [dns-operations] Zone with expired signatures?

On Jul 30, 2014, at 00:53 , Doug Barton do...@dougbarton.us wrote: I could have sworn that I remembered someone setting up zones with both expired and valid signatures so that people could test against them. But I cannot find any references. I can set that up myself of course, but I don't

[dns-operations] name.com admins?

Is there anyone on-list from name.com that can look into some strange behaviour from the name.com servers? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs

Re: [dns-operations] DDNS updates for 2.0.0.2.ip6.arpa to ns3.apnic.net

On Apr 24, 2014, at 10:28 , Chuck Anderson c...@wpi.edu wrote: Has anyone seen bunches of machines on their network attempting to do DDNS updates to ns3.apnic.net for addresses in the 6to4 2002::/16 block 2.0.0.2.ip6.arpa zone? Should I be concerned? ns3.apnic.net is the reverse DNS PTR for

Re: [dns-operations] NSCD for Linux/UNIX stub resolver failover?

On Apr 23, 2014, at 12:10 , Chuck Anderson c...@wpi.edu wrote: On Tue, Apr 22, 2014 at 11:27:02PM -0400, Robert Edmonds wrote: Chuck Anderson wrote: 2. Use a local DNS daemon on every server with forwarders configured to the network's nameservers, and fix resolv.conf to 127.0.0.1. I'll

Re: [dns-operations] DNSSEC at ICANN: still no check?

On Jan 21, 2014, at 06:13 , Chris Thompson c...@cam.ac.uk wrote: On Jan 20 2014, Matthew Pounsett wrote: It’s hard to see from outside since its all the same NS set, but I suspect red. and nic.red. are separate zones, but that there is no delegation from red. to nic.red. I’ve seen

Re: [dns-operations] DNSSEC at ICANN: still no check?

On Jan 20, 2014, at 11:37 ,  Roy Arends r...@dnss.ec wrote: The problem is indeed the absence of type NS in the type bit maps, as you (and Peter van Dijk) showed in your previous mail. It’s hard to see from outside since its all the same NS set, but I suspect red. and nic.red. are

Re: [dns-operations] Resolvers choosing low latency nameservers

On 2013/06/21, at 09:27, Matthäus Wander wrote: Hi, are there any studies or anecdotal evidence about how recursive resolvers select a query destination from a set of authoritative servers with known RTTs, and how often they re-probe the slower ones? Specifically, how many queries in

Re: [dns-operations] DNS Issue

On 2013/04/24, at 09:06, Samir Abidali wrote: I wonder if someone can guide me in the direction for troubleshooting my DNS issues. I work in the regional ISP, we have to DNS servers where it works fine for most of the Domain names but it cannot resolve some others, like dyn.com. I wasn't

Re: [dns-operations] RRL exposed: resolver issues with AAAA-only NS?

On 2013/01/10, at 16:53, Phil Pennock wrote: Anyone know of any resolvers that suffer horribly and die when presented with an NS host which is -only? From the perspective of a v4-only resolver, that would look like a lame delegation. Is the whole NS set v6-only, or just the one name

Re: [dns-operations] Fingerprinting stub resolvers

On 2013/01/07, at 06:32, gra...@graemef.net wrote: On 04.01.2013 16:05, Matthew Pounsett wrote: A friend of mine at an ISP asked me recently whether I had any suggestions for fingerprinting stub resolvers. They've got pcaps from the downstream side of their caching servers and are looking

[dns-operations] Fingerprinting stub resolvers

A friend of mine at an ISP asked me recently whether I had any suggestions for fingerprinting stub resolvers. They've got pcaps from the downstream side of their caching servers and are looking at trying to pull more interesting statistics than query counts out of them. I didn't have any

Re: [dns-operations] DNS ANY record queries - Reflection Attacks

On 2012/09/12, at 09:06, paul vixie wrote: On 9/12/2012 10:57 AM, Phil Regnauld wrote: I do wish we had similar knobs in NSD (I thought version 3 was going to offer that) - http://www.nlnetlabs.nl/downloads/NSD_DenicTechnical.pdf, but that's from 2009. i will pay my own air fare and

Re: [dns-operations] DNS ANY record queries - Reflection Attacks

On 2012/09/12, at 15:44, Eric Osterweil wrote: OK, this is beginning to become clearer... But I have to admit, this still seems worrisome to me. If you drop 50% of legit traffic (a generous assumption as it assumes a uniform distribution, which is not established by any of the analysis

[dns-operations] Rogers contact?

Does anyone have a DNS contact at Rogers? I think I've found a v6 connectivity (or communications) problem between the recursive servers for the 3G and probably also residential cable networks and my name servers at least.. probably others... but it's hard to tell from my vantage point. I'm

Re: [dns-operations] DNS benchmark platform @ OARC

On 2012/04/13, at 09:13, Ondřej Surý wrote: So we were thinking that DNS-OARC would be ideal platform to prepare methodology for measuring DNS servers performace and it could also do the tests as an independent laboratory. We've discussed something like this within the board a few times, but