A related observation: according the ICANN webinar on this topic from a
couple of weeks ago, all new gTLDs delegated on or after August 18th were
supposed to deploy these kinds of controlled interruption wildcard records.
The slides are here:
On Wed, Sep 24, 2014 at 9:27 PM, 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
On Mon, Sep 29, 2014 at 3:15 PM, Shumon Huque shu...@gmail.com wrote:
You might be interested in NIST's larger measurement of over 2000 US
companies also. They show 77 of 2150 IPv6 reachable DNS domains (only 3.6%).
http://fedv6-deployment.antd.nist.gov/cgi-bin/generate-com
A quick
;; Query time: 1 msec
;; SERVER: 2610:a1:1076::c3#53(2610:a1:1076::c3)
;; WHEN: Wed May 27 15:51:27 EDT 2015
;; MSG SIZE rcvd: 108
--
Shumon Huque
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman
On Wed, May 27, 2015 at 3:59 PM, Shumon Huque shu...@gmail.com wrote:
Here's a transcript of my attempt to query all the NS addresses at
accountant for TLSA records (from one location, a datacenter in New
Jersey). Quick summary: no response/timeout from all the IPv4 addresses,
correct
gramme Committee to make objective assessments
of submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
If you have questions or concerns you can contact the Programme
Committee via submissi...@dns-oarc.net
Shumon
will probably incorrectly flag
those servers as unavailable. For such services, perhaps it would be better
if they were not single-homed to either Cogent or HE.
(To be clear, I'm happy that DNSviz is housed at OARC. So, I guess I might
be suggesting that the community might consider how to fund a
ncerns you can contact the Programme
Committee via submissi...@dns-oarc.net
Shumon Huque, for the DNS-OARC Programme Committee
OARC depends on sponsorship to fund its workshops and associated
social events. Please contact spon...@dns-oarc.net if your organization
is interested in becoming a sponsor
Didn't we discuss this recently?
I assume this is the Cogent<->Hurricane Electric IPv6 peering issue. See
the long thread that starts here (short summary: dnsviz is singly homed to
HE so can't reach Cogent IPv6 servers):
he quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via
Shumon Huque, for the DNS-OARC Programme Committee
OARC depends on s
On Fri, Apr 3, 2020 at 4:54 PM Viktor Dukhovni
wrote:
>
> The AD=1 replies from Google and Verisign are not "wrong". They just
> reflect the fact that any ancestor zone is in principle free to bypass
> delegation and return "unexpected" signed answers for a child domain,
> legitimately or
On Fri, Apr 3, 2020 at 7:35 AM Matthew Richardson
wrote:
> I am observing responses from particular authoratitive servers for
> non-existant domains, which is puzzling me. I thought I understood this
> topic, but am now having doubts...
>
> Consider two (real) non-existant records (which are
and I
have been working on, to cause resolvers to deterministically prefer the
child NS set, while avoiding the problem you mention in the last paragraph:
https://tools.ietf.org/html/draft-huque-dnsop-ns-revalidation-01
I realize some implementers (Petr Spacek?) do not agree, but on balance we
think t
On Fri, Apr 3, 2020 at 8:20 AM Stephane Bortzmeyer
wrote:
> On Fri, Apr 03, 2020 at 07:48:16AM -0400,
> Shumon Huque wrote
> a message of 98 lines which said:
>
> > The second one, doesnotexist.monitor.itconsult.net., does not appear
> to be
> >
over signed authoritative data, and whether or not we should redesign
the DNS delegation mechanism to fix that. The security of DNSSEC does
not currently rely on signed nameserver records, but why not try to catch
spoofed delegation data as early as possible,
On Fri, Apr 3, 2020 at 1:55 PM Puneet Sood wrote:
> On Fri, Apr 3, 2020 at 1:53 PM Paul Hoffman
> wrote:
> >
> > Shouldn't this part of the thread (proposed changes base on an Internet
> Draft) be in the DNSOP WG in the IETF? Said another way, if you don't move
> it there soon, when the topic
On Thu, Apr 23, 2020 at 2:25 AM Viktor Dukhovni
wrote:
> On Mon, Apr 20, 2020 at 11:55:38AM +0100, Christian Elmerot wrote:
>
> > On 2020-04-19 07:55, Viktor Dukhovni wrote:
> > > The CloudFlare auth servers return ServFail for the TLSA lookup of:
> > >
> > >
On Mon, May 4, 2020 at 3:41 PM Martin Wismer
wrote:
> Hello, Bonjour,
>
> I noticed, that the DNSSEC signed Domains under top-Level Domain fr.
> failed since about 4 hours.
>
> Example Domains:
> m6replay.fr.
> climato-realistes.fr.
> langue-au-chat.fr
> sully-group.fr
>
> Could anybody please
On Mon, May 11, 2020 at 1:48 PM Robert Evans via dns-operations <
dns-operati...@dns-oarc.net> wrote:
> From: Robert Evans
> On Fri, Apr 17, 2020 at 1:23 PM Robert Evans wrote:
>
>> [...]
>>
>> Not sure the motivation for why the server does that, but I agree it
>> should be NOERROR or NXDOMAIN
On Mon, Mar 9, 2020 at 2:41 PM Paul Vixie wrote:
> On Monday, 9 March 2020 14:44:09 UTC Shumon Huque wrote:
> > ** We have extended the submissions deadline for the 33rd DNS-OARC
> > ** workshop to March 19th 2020 (midnight CEST).
> >
> > The 33rd DNS-OA
On Tue, Sep 1, 2020 at 4:24 AM Viktor Dukhovni
wrote:
> On Tue, Sep 01, 2020 at 01:48:17AM -0400, Viktor Dukhovni wrote:
> >
> > @ 1.1.1.1 _25._tcp.mx.runbox.com. IN TLSA ? ; +cd +dnssec
> [...]
>
> So I'm at a loss to explain what's happening... Haven't seen any
> anomalous replies yet
On Mon, Oct 5, 2020 at 11:22 PM Mark Andrews wrote:
> > On 6 Oct 2020, at 13:18, Paul Vixie wrote:
> >
> > ssh gets hinky when i connect from a server whose PTR is "servfail"
> (dnssec "bogus")
> >
> > • 5.0.1.0.0.2.ip6.arpa to 9.5.5.0.1.0.0.2.ip6.arpa: No valid
> RRSIGs made by a key
test zones of the form "dNaNnN.rootcanary.net", where:
dN: DS digest algorithm number
aN: algorithm number
nN: NSEC version (1 or 3)
So, the zone "d2a15n3.rootcanary.net" has a DS record with hash algorithm 2
(SHA256), is sig
On Tue, Jan 19, 2021 at 8:44 AM Viktor Dukhovni
wrote:
>
> Sorry for leaving this vague. Changing the salt requires rebuilding the
> entire NSEC3 chain, and so is difficult to combine with incremental zone
> signing (such as BIND's "auto-dnssec maintain"). If you're doing
> periodic whole zone
Hannes,
This is a NODATA response for an empty non-terminal, so no wildcard
non-existence
proof is needed.
The following NSEC record demonstrates that "a.se" is an empty non-terminal:
_nicname._tcp.se. 6694IN NSECacem.a.se. SRV RRSIG NSEC
Shumon.
On Tue, Jan 11, 2022 at
On Mon, Jan 17, 2022 at 9:04 AM Ulrich Wisser via dns-operations <
dns-operati...@dns-oarc.net> wrote:
>
> -- Forwarded message --
> From: Ulrich Wisser
> To: Mark Andrews
> Cc: Shreyas Zare , Greg Choules via
> dns-operations
> Bcc:
> Date: Mon, 17 Jan 2022 15:01:36 +0100
>
On Fri, Jan 27, 2023 at 3:39 AM Stephane Bortzmeyer
wrote:
> On Fri, Jan 27, 2023 at 12:19:18AM -0500,
> Viktor Dukhovni wrote
> a message of 30 lines which said:
>
> > Three sample zones:
>
> They all seem to use black lies, not white lies.
>
I took a quick look:
* herokudns.com is
On Fri, Jan 27, 2023 at 11:16 AM Paul Ebersman <
list-dns-operati...@dragon.net> wrote:
> shuque> UltraDNS (Neustar Security Services) is known to use NSEC White
> shuque> Lies. I have a test zone there,
>
> shuque> which you can examine: "[[ultratest.huque.com]]".
>
> My recollection is that the
On Tue, Mar 28, 2023 at 12:16 AM Viktor Dukhovni
wrote:
> On Mon, Mar 27, 2023 at 04:28:30PM +0200, Emmanuel Fusté wrote:
>
> > > definitely does not exist. The issue I take it that the
> > > sentinel-free:
> > >
> > > nxdomain.example. IN NSEC \0.nxdomain.example. RRSIG NSEC
> > >
> > >
On Tue, Mar 28, 2023 at 6:19 AM Viktor Dukhovni
wrote:
>
> A possibly inconvenient question, just to make sure we're not ignoring
> the obvious sceptical position:
>
> * How compelling are compact lies?
>
> The reason to ask is that both the original and now modified protocols
> involve
On Tue, Jul 18, 2023 at 3:29 PM Viktor Dukhovni
wrote:
> On Tue, Jul 18, 2023 at 08:54:04PM +0200, Ondřej Surý wrote:
>
> > With my implementor’s hat on, I think this is wrong approach. It
> > (again) adds a complexity to the resolvers and yet again based
> > (mostly) on isolated incident. I
On Wed, Jul 19, 2023 at 3:28 AM Shane Kerr
wrote:
> Shumon and all,
>
> On 18/07/2023 21.41, Shumon Huque wrote:
> > On Tue, Jul 18, 2023 at 3:29 PM Viktor Dukhovni > <mailto:ietf-d...@dukhovni.org>> wrote:
> >
> > Yes, I agree. A resolver can't really t
On Mon, Apr 1, 2024 at 10:37 AM Rithvik Vibhu
wrote:
> Hi,
>
> I'm looking for a good way to validate DNSSEC for a chain of records,
> offline. I mean: given a list of records including all RRSIGs, NSECs,
> etc.), verify that all the signatures match and the whole trust chain leads
> to a trust
33 matches
Mail list logo
