On Tue, Apr 09, 2024 at 01:09:20PM -0500, David Zych wrote:
> Does anyone happen to know the folks responsible for ns1.usda.gov. and
> ns2.usda.gov.?
No, but you could also try the SOA "rname", with the first label as
email address local part:
ag.gov. IN SOA ns1.usda.gov.
On Wed, Mar 27, 2024 at 07:17:01PM +, Matthew Richardson via dns-operations
wrote:
> Viktor Dukhovni wrote:-
>
> >I do hope that, as a community, we'll continue to steadily streamline
> >acceptable NSEC3 parameters (per RFC9276) down to 0 additional
> >iteratio
On Mon, Mar 25, 2024 at 09:27:06AM +0100, Haya Shulman wrote:
> Our evaluations demonstrate that the two attack vectors are fundamentally
> different from the perspective of their practical impact: KeyTrap
> introduces a realistic immediate threat for exploitation by hackers. In
> contrast, with
On Tue, Feb 13, 2024 at 02:12:07PM -0500, Mark E. Jeftovic wrote:
> Would anybody know how often the .FI registry updates?
>
> Is it realtime? Once-per-hour?
>
> asking for a friend... thx
The signature inception times of 40 random DS records under .fi suggest
signing happens every 20 minutess
On Thu, Feb 08, 2024 at 12:24:08PM +, Edward Lewis wrote:
> Between non-unique key tags and the possibility of hash collisions,
> it's possible two DS resource records could share either a key tag or
> a hash representing different keys. From this, I wish we hadn't
> defined the key tag
On Thu, Jan 18, 2024 at 09:51:45PM +, Renee Burton via dns-operations wrote:
> Can anyone on the list connect me with Digicert DNS? I can’t figure
> out who this really is although they are big name servers.
If this is the real DigiCert, then perhaps the "digicert.com" SOA rname
might work?
On Fri, Jan 12, 2024 at 02:40:22PM -0800, Wes Hardaker wrote:
> Viktor Dukhovni writes:
>
> > > Relevant text from RFC 9471 abstract: If message size constraints
> > > prevent the inclusion of all glue records for in-domain name servers,
> > > the server
On Fri, Jan 12, 2024 at 02:25:15PM -0500, Puneet Sood via dns-operations wrote:
> Note: query does not use EDNS0; response does not set TC bit and has no glue.
> ; <<>> DiG 9.10.6 <<>> @m.root-servers.net
>
On Mon, Dec 18, 2023 at 06:48:30PM +, Weinberg, Matt wrote:
> The latest patched versions of macOS Ventura (13.6.3) and Sonoma
> (14.1.2) both include an old version of the dig client:
>
> % dig -v
> DiG 9.10.6
>
> I only noticed the issue when I attempted to retrieve the ZONEMD
> record of
On Wed, Dec 06, 2023 at 08:36:22PM +, Wessels, Duane via dns-operations
wrote:
> I’m happy to announce that the second phase of ZONEMD deployment for the root
> zone is now complete. As of serial 2023120602, the hash algorithm field is
> set to 1:
>
> ;; ANSWER SECTION:
> . 86400 IN
On Fri, Nov 03, 2023 at 11:09:02AM +0100, Vladimír Čunát via dns-operations
wrote:
> On 01/11/2023 17.18, Viktor Dukhovni wrote:
> > Should authoritative [nameservers] have knobs to perform internal checks on
> > the signed zones they serve and at least syslog loud wa
On Thu, Nov 02, 2023 at 09:34:17AM +0100, Stephane Bortzmeyer wrote:
> > Specifically, in the case of signed zones, monitoring MUST also include
> > regular checks of the remaining expiration time of at least the core
> > zone apex records (DNSKEY, SOA and NS), and ideally the whole zone, both
>
On Wed, Nov 01, 2023 at 04:49:01PM +0100, Mark Andrews wrote:
> It shouldn’t take any time as the bogus records shouldn’t have been cached.
>
Right, unlike mismatched parent-side DS RRs, RRSIG expiration heals
fairly promptly once the zone is resigned at the origin.
I am repeatedly surprised
On Thu, Oct 19, 2023 at 02:02:22PM +, Carr, Brett via dns-operations wrote:
> From: "Carr, Brett"
> Date: Thu, 19 Oct 2023 14:02:22 +
> Subject: xn--mgbai9azgqp6j broken
> To: "dns-operati...@dns-oarc.net"
>
> This may have been mentioned before as I think it has been broken for
>
On Wed, Oct 11, 2023 at 07:32:28PM +0400, Misak Khachatryan wrote:
> I'm maintaining a rather big DNS zone - around 2.5 Megabytes in ASCII
> format, more than 40k records overall.
40k records is neither small, nor unusually large. This should work
without issues.
> Authoritative server
On Sat, Oct 07, 2023 at 01:38:10PM -0400, Viktor Dukhovni wrote:
> So, it looks like "unbound" is not fond of empty NODATA replies with no
> SOA. It is I think reasonable to ask Microsoft to address the "no SOA"
> NODATA response.
This was addressed upstre
On Sat, Oct 07, 2023 at 09:12:31AM -0700, jack tavares wrote:
> Interesting, it works fine with dig, but I get the same error the
> author does when I use "host"
>
> I used to know the significant differences between "host" and "dig" but I
> have
> not used "host" in so long, I have forgotten
On Fri, Oct 06, 2023 at 01:36:26PM -0700, Craig Leres wrote:
> > So long as you don't try to look up TLSA records, or insist on using
> > EDNS(0), even after a FORMERR response, you should be fine.
>
> I've had edns0 in resolv.conf for a really long time but even if I comment
> that out I'm
On Fri, Oct 06, 2023 at 11:08:39AM -0700, Craig Leres wrote:
> I routinely find messages stuck in my sendmail queue with the error,
> "Deferred: Name server: outlook-com.olc.protection.outlook.com". This system
> uses unbound (with DNSSEC validation enabled -- perhaps not relevant) and
> the only
On Wed, Oct 04, 2023 at 04:46:42PM +0200, Martin Wismer wrote:
> we could get answer from all of the dhl.com NS RR TXT. It's a big
> Answer, biger than 2200 Byte. May be they have rate-limit's on it.
That's not the issue. The OP also reported that answers arrive when no
EDNS options are used
On Wed, Oct 04, 2023 at 03:10:13PM +0200, Borja Marcos via dns-operations wrote:
> dhl.com/TXT: No response was received from the server over UDP (tried
> 7 times) until the NSID EDNS option was removed (however, this server
> appeared to respond legitimately to other queries with the NSID EDNS
>
On Tue, Oct 03, 2023 at 02:10:50PM +0100, Ben Cox via dns-operations wrote:
> I would suspect this is caused by NO_DELAY being enabled (as it
> should) and some code writing out the dns response buffer in two
> parts. That server in the pcap appears to be running unbound 1.4.22:
I assume you
On Tue, Sep 19, 2023 at 11:00:34PM +0100, Joe Abley wrote:
> Apart from mail and some degree of debugging courtesy, what
> operational reasons exist to put effort into reverse DNS in 2023? Are
> there any? Or is the whole reverse tree just a weird anachronism?
Perhaps "apart from mail", it
On Mon, Sep 04, 2023 at 02:28:23PM -0400, Lee wrote:
> dig txt +short o-o.myaddr.l.google.com
> gives me the ipv6 address of the resolver
When the resolver happens to use IPv6. The output is not by itself
IPv6-specific.
> dig txt +short o-o.myaddr.l.google.com @ns{1,2,3,4}.google.com
>
On Mon, Aug 21, 2023 at 02:56:58PM +, Jacques Latour via dns-operations
wrote:
> We're getting an error when doing this CDS query over TCP? Just me?
> Seems like a Google bug?
>
> $ dig ewmc.ca cds @ns-cloud-c4.googledomains.com. +tcp
> netmgr/tcpdns.c:302: fatal error:
On Mon, Jul 24, 2023 at 09:13:30AM +, Manal Ismail wrote:
> We are in the middle of updating the records .. The update is
> currently pending one approval .. Once done, today, all problems will
> hopefully be fixed ..
Congratulations, looks much better now:
Google Public DNS (also "dns.google", or, colloquially, "Quad8") now
includes EDEs in most error responses. For details see:
https://developers.google.com/speed/public-dns/docs/troubleshooting/domains#edes
--
Viktor.
___
dns-operations
On Thu, Jul 20, 2023 at 07:25:17AM -0400, Hugo Salgado wrote:
> They are aware and working on this. Thanks!
The final working state is still somewhat suboptimal:
- The KSKs are 4096 bit RSA. This is pointless, the DS RRset from
the root is signed with a 2048-bit RSA key. The additional bits
On Tue, Jul 18, 2023 at 10:25:01PM +0200, Ondřej Surý wrote:
> It’s exactly like the serve-stale. The inception of the protocol
> change is driven by this isolated incident. That’s not a proper
> design, that’s slapping more bandaids on the camel.
I don't even see a "protocol change" here. A
On Tue, Jul 18, 2023 at 12:51:39PM -0700, Gavin McCullagh wrote:
> We definitely saw Unbound returning SERVFAIL for unsigned com domains
> though.
Failures for even for some "unsigned" domains were to be expected if
retries were either not happening or the retry count was at times
exceeded.
The
On Tue, Jul 18, 2023 at 07:38:51PM +, Matt Nordhoff via dns-operations
wrote:
> ³ Actually the xn--wgbh1c TLD is broken right now but I haven't told anyone.
Well, at least that IDN ccTLD (Egypt, "dotmasr") is broken for all
servers.
Nice to see a rollover in progress to algorithm 13, but
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 really don’t want yet another
> “serve-stale” in the resolvers. I
On Thu, Jul 13, 2023 at 12:16:37PM -0700, Gavin McCullagh wrote:
> When faced with ~4x obviously bogus, broken nameservers (the stale pop) and
> ~9x fresh working nameservers with valid signatures, the DNSSEC RFCs appear
> to specify (and Unbound appears to implement) that resolvers must accept
>
On Tue, Jul 11, 2023 at 10:51:47PM -0400, Viktor Dukhovni wrote:
> In .COM CZDS zone file snapshot of .COM from ~midnight UTC 2023-07-11
> the range of non-apex RRSIG inception times was:
>
> 20230707025004 – 20230710225021
>
> With corresponding expiration times:
>
On Tue, Jul 11, 2023 at 05:24:57PM -0700, Gavin McCullagh wrote:
> > Consequently, some users unlucky enough to have switched providers or
> > moved to new NS hosts at the same a provider after the site was cut off
> > from updates also observed some issues, whether or not DNSSEC happened
> > to
On Tue, Jul 11, 2023 at 10:24:21PM +, Wessels, Duane wrote:
> Last week, during a migration of one of our DNS resolution sites in
> Singapore, from one provider to another, we unexpectedly lost
> management access and the ability to deliver changes and DNS updates
> to the site. Following our
On Sat, Jul 08, 2023 at 12:36:12PM -0700, David Conrad wrote:
> Instead, we recommended dig as (a) it provides all sorts of options
> that help with pretty much every form of diagnostic you can imagine
> and (b) it doesn’t try to “help”. We obviously didn’t succeed and
> it’s far too late now
On Fri, Jul 07, 2023 at 08:09:39PM +0200, Petr Menšík wrote:
> I have tested recently how Windows 11 behaves when resolving single
> label queries.
>
> I have expected it might try to use LLMNR. But I did not expect it would
> do so also when trying nslookup, a tool which should be DNS only
On Fri, Jun 23, 2023 at 07:42:47AM +1000, Mark Andrews wrote:
> There should be an insecure delegation for 127.in-addr.arpa. in the
> in-addr.arpa zone. IANA have instructions from the IETF to do this in
> RFC 6303.
>
> There has been a ticket open for years with IANA to correct the
> missing
On Thu, Jun 22, 2023 at 10:30:33AM -0400, Matthew Pounsett wrote:
> 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
The nameservers for in-addr.arpa are:
in-addr.arpa. NS a.in-addr-servers.arpa.
in-addr.arpa. NS b.in-addr-servers.arpa.
in-addr.arpa. NS c.in-addr-servers.arpa.
in-addr.arpa. NS d.in-addr-servers.arpa.
in-addr.arpa.
On Tue, Jun 20, 2023 at 02:44:34PM +0200, Stephane Bortzmeyer wrote:
> On Tue, Jun 20, 2023 at 01:36:10PM +0200,
> CORE DNS Support Team wrote
> a message of 43 lines which said:
>
> > since anycast9 is only responsible for scot and not for gov.scot, I
> > believe the desired answer is a
On Tue, Jun 20, 2023 at 01:36:10PM +0200, CORE DNS Support Team wrote:
> > The gov.scot zone is unsigned, with "service.gov.scot" as a subdomain,
> > but "DS" queries for "service.gov.scot" incorrectly elicit NXDOMAIN,
> > rather than NODATA responses from the "scot" auth servers.
> >
> > $
The gov.scot zone is unsigned, with "service.gov.scot" as a subdomain,
but "DS" queries for "service.gov.scot" incorrectly elicit NXDOMAIN,
rather than NODATA responses from the "scot" auth servers.
$ dig -t ds service.gov.scot @anycast9.irondns.net +norecur +nocmd +noall
+nostats +comment
The .GL TLD returns bogus NXDOMAIN responses to DS queries for:
com.gl. IN DS ? ; NXDomain https://dnsviz.net/d/com.gl/ZJEMOQ/dnssec/
gl. IN SOA a.nuuk.nic.gl. gl-ad...@tele.gl. 2022119284 900 1800 6048000 3600
gl. IN RRSIG SOA 8 1 900 2023070505 2023061805 39306 gl. [...]
On Sun, Jun 18, 2023 at 06:12:27AM +, Geoff Huston wrote:
> >> The BCP algorithm is ECDSAP256SHA256(13). This is both more secure and
> >> more compact than RSA. It is in wide use:
> >>
> >>https://stats.dnssec-tools.org/
> >>https://stats.dnssec-tools.org/#/?dnssec_param_tab=0
>
On Thu, Jun 15, 2023 at 01:05:50PM -0700, Fred Morris wrote:
> I'm using DNS to retrieve some distributed telemetry data from multiple
> servers. To facilitate this I have an FQDN which resolves to a set of
> PTR records. If there's a generally accepted better option, let me know.
>
> If you
On Mon, Jun 12, 2023 at 10:41:12AM -0400, Viktor Dukhovni wrote:
> On Mon, Jun 12, 2023 at 10:37:22AM -0300, daniel majela wrote:
>
> > What is the best algorithm for ksk and zsk?
>
> The BCP algorithm is ECDSAP256SHA256(13). This is both more secure and
> more compact tha
On Mon, Jun 12, 2023 at 10:37:22AM -0300, daniel majela wrote:
> What is the best algorithm for ksk and zsk?
The BCP algorithm is ECDSAP256SHA256(13). This is both more secure and
more compact than RSA. It is in wide use:
https://stats.dnssec-tools.org/
On Sat, Jun 10, 2023 at 05:52:27AM -0400, Dan McCombs via dns-operations wrote:
> > dig -b 64.227.108.32 +short +subnet=64.227.108.32/32 \
> > @ns-1339.awsdns-39.org doitb-synthetic.atlassian.net
FWIW, though it seems to not matter with the server in question, note
that a scope prefix length
On Tue, Jun 06, 2023 at 11:00:29AM -0600, Andy Smith via dns-operations wrote:
> We (PagerDuty) are in the process of enabling DNSSEC signing across
> our domains, and today (June 6th) we’re planning to enable it for
> pagerduty.com and associated subdomains (e.g. eu.pagerduty.com). Given
> the
On Sun, Jun 04, 2023 at 08:44:19AM +0100, Matthew Richardson via dns-operations
wrote:
> Without wishing to ask a really stupid question, is there any reason
> why root-servers.net is not DNSSEC signed?
>
> Would signing it provide any additional security?
For the glue records to be
> On 11 Apr 2023, at 9:57 am, Edward Lewis wrote:
>
> Sure, the cost of replacing NSEC and NSEC3 would be another resource record
> type code roll
> (such as 5->8, RSA-SHA1 vs RSA-SHA1-NSEC3). But a new on-the-fly denial of
> existence might
> prove to be worth it in operations.
No such
On Wed, Mar 29, 2023 at 08:57:51AM -0400, jmur...@pdknox.org wrote:
> * Viktor Dukhovni [230328 00:05]:
> > The queries for "_.extglb.tn.gov. IN A ?" in your PCAP are a novelty to
> > me. Are these some form of query minimisation, or some sort of sanity
> >
[ Redirecting to dns-operations, I don't believe this is an IETF dnsop WG topic
]
On Mon, Mar 27, 2023 at 12:13:58PM -0400, jmur...@pdknox.org wrote:
> www.tn.gov. CNAME www.extglb.tn.gov.
> extglb.tn.gov.NS sdcgtm02.tn.gov.
> extglb.tn.gov.NS
On Mon, Mar 27, 2023 at 06:57:13PM -0600, Paul Ebersman wrote:
> viktor> Do the CPU and packet size reductions justify the additional
> viktor> protocol complexity?
>
> As IPv6 slowly creeps up in usage amongst folks not well versed in PMTUD
> and such (particularly more and more smaller
On Tue, Mar 28, 2023 at 06:01:40AM +0900, Shumon Huque wrote:
> I've spoken to both NS1 and Route53, and both are amenable to adjusting
> their implementations to support the changes specified in
> draft-huque-dnsop-compact-lies. So, we hope that the end result will be
> that all known
On Mon, Mar 27, 2023 at 06:30:02PM +0200, Emmanuel Fusté wrote:
> > Do you have a list of operators that currently return just "RRSIG NSEC"
> > for ENTs? Do you [know] what software they are running?
>
> I double check: route53/AWS currently return just "RRSIG NSEC"for ENTs.
Anyone else?
>
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
> >
> > which is an ENT per:
> >
> >
> >
On Mon, Mar 27, 2023 at 03:27:34PM +0200, Emmanuel Fusté wrote:
> If Cloudflare switch to this draft for the ENT case too, it will became
> as worse as Route53 and only NS1 will give distinguishable real NXDOMAIN.
> Or ALL compact lies response implementer should switch to this new draft
> and
On Wed, Mar 01, 2023 at 03:57:26PM +0100, Florian Streibelt wrote:
> I am trying to reach out to the DNS operators of dns.com as the email
> from the SOA yielded no response.
Try one of:
Email address: supp...@dns.com
Website: https://www.dns.com/contact-us/
Phone number:
On Thu, Jan 26, 2023 at 08:33:21PM +0100, Stephane Bortzmeyer wrote:
> I'm looking for zones in the wild that are signed using the technique
> of white lies (RFC 4470).
>
> [Not the black lies used by Cloudflare.]
Three sample zones:
herokudns.com. IN SOA dns1.p05.nsone.net.
On Fri, Jan 20, 2023 at 09:22:34PM -0300, Rubens Kuhl via dns-operations wrote:
> I am considering a DNSSEC transition in the following scenario:
>
> - Org 1 operates both the parent domain, with a delegation-only
> server, and the child domain, with a set of authoritative servers. A
> zone
On Mon, Jan 09, 2023 at 01:55:29PM +, Roy Arends wrote:
> I’ve often seen this behaviour.
>
> One confirmed explanation was (but there may be more/other) that this
> is the result of a stateful firewall. While the rules are pushed,
> traffic through it is buffereduntil the last rule is
On Wed, Dec 21, 2022 at 06:27:29PM -0800, Andreas Ott wrote:
> What are my best options to find out who is behind all this traffic when it
> comes from anonymous sources?
Probably not worth your time, but you could ask the cloud provider abuse
teams to look into this for you.
> For how long
On Wed, Nov 23, 2022 at 12:44:46PM +, Michele Neylon - Blacknight via
dns-operations wrote:
> Many many moons ago we setup the PTR records for our network using a
> template that clearly flagged that the IPs were static and used for
> hosting.
>
> Fast forward to 2022 and we now offer
The nameservers for both `protection.outlook.com` and
`olc.protection.outlook.com` are:
ns[12]-gtm.glbdns.o365filtering.com
They return uncacheable NODATA responses with no SOA [RFC2308 Sec. 5]. Any
IPv6 client that asks for the records of various "olc" hosts will
therefore elicit
On Wed, Oct 19, 2022 at 06:58:21AM +1100, Mark Andrews wrote:
> Not for DS as it is part of the parent zone.
But is not an "apex" DS query, the parent zone (if "igt" were delegated)
would surely be fiscal.treasury.gov.
> > $ dig +dnssec @ns1.treasury.gov igt.fiscal.treasury.gov ds | awk '$4
> >> https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/
> >
> > DNSViz struggles to display this properly, because the same underlying
> > nameservers serve both the parent and child zone, and instead of
> > referrals serves authoritative data from the child. However, the
> > parent
On Tue, Oct 18, 2022 at 05:56:25PM +1100, Mark Andrews wrote:
> > However, resolvers generally don't send explicit DS queries. Instead,
> > when the parent zone is signed, they set the DO bit and expect any
> > referrals to either include the signed DS records, or authenticated
> > denial of
On Tue, Oct 18, 2022 at 02:02:48AM -0400, Viktor Dukhovni wrote:
> However, resolvers generally don't send explicit DS queries. Instead,
> when the parent zone is signed, they set the DO bit and expect any
> referrals to either include the signed DS records, or authenticated
On Mon, Oct 17, 2022 at 09:52:43PM -0700, cjc+dns-o...@pumpky.net wrote:
> Having some problems resolving qa.ws.igt.fiscal.treasury.gov. There is
> pretty clearly a problem,
>
> https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/
DNSViz struggles to display this properly, because the
On Tue, Sep 27, 2022 at 09:45:26PM +0200, Stephane Bortzmeyer wrote:
> This specific problem disappeared but there are other funny things in
> the zone. For instance, the three authoritative name servers for .bs
> claim that com.bs has three name servers, but they are the same.
>
> % dig
On Fri, Sep 23, 2022 at 07:48:50PM +0200, Bill Woodcock wrote:
> > On Sep 23, 2022, at 7:27 PM, Jacques Latour wrote:
> > Just looking quickly, if you look back in dnsviz on Sept 15, I think a KSK
> > roll over didn't go as plan...
>
> That was not the root cause. I’m sure they’ll discuss it
The .COM.BS is an empty non-terminal with various child domains
registered beneath. The "ns36.cdns.net" nameserver for .BS responds
with NXDOMAIN to "com.bs" qname-minimised queries.
This in turn can and does sometimes lead to NXDOMAIN inference for the
child domains.
This nameserver needs to
The nameservers in question attempt to deny the existence of TLSA
records at "_25._tcp.mx2.beheerd.nl" with a "black lies" response
whose type bitmap includes "CNAME", but in that case the correct
response would be to return the CNAME, and the NODATA response is
bogus:
$ dig +nsid +nocmd
On Tue, Aug 30, 2022 at 07:42:30PM +0200, Anand Buddhdev wrote:
> On 30/08/2022 18:42, Randy Bush wrote:
>
> Hi Randy, Viktor,
>
> > another day of no response from afrinic, and i guess i should ask the
> > iana to remove them from the NS RRset for GN and LR.
> >
> > anyone have a way to get
On Sat, Aug 27, 2022 at 04:00:01PM -0400, John Levine wrote:
> It appears that Viktor Dukhovni said:
> >But also some that appear to just mirror other ccTLDs without an obvious
> >connection to a category of child domains (com, edu, gov, net, org, ...):
> >
> >ai
> Nearly all of the TLDs have second level suffixes (like gov.in, co.in
> and various others) which are used as special names, and zones are
> further delegated from these suffixes.
Speaking of ccTLD second level public suffixes, for .in I've just
noticed not only some "expected" suffixes like:
On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote:
> this...
>
> Meir Kraushar via dns-operations wrote on 2022-08-27 02:56:
> > 2) The need to maintain a list dedicated to browser issues is out of our
> > scope. I'm sure there are good reasons to have it, like you said, there
> > is
On Sat, Aug 27, 2022 at 03:17:18AM +0300, Meir Kraushar wrote:
> You also suggested to not opt-out? What would be the reason for that?
Attackers can no longer fabricate the existence or non-existence of
unsigned delegations whose hashes fall between those of the signed ones.
Of course all
On Fri, Aug 26, 2022 at 09:20:00PM +0300, Meir Kraushar wrote:
> Yes the problem is that browsers not aware of a TLD, in this case SAFARI
> unaware of xn--4dbrk0ce, do not treat it as a domain. It won't resolve
> the given name and go to the address. Instead, it will pass the value to
> the
On Mon, Aug 22, 2022 at 04:18:36PM +0200, Haya Shulman wrote:
> [ Further ad-hominem off-topic to this list removed ]
Please refrain from further efforts in that direction.
> in our project we evaluated two ways to downgrade DNSSEC, by disabling
> validation and by downgrading to a weaker
On Mon, Aug 15, 2022 at 07:43:42AM +,
jean-pierre.seif...@external.telekom.de wrote:
> I would like to correct the claims of Peter Thomassen.
[ No factual corrections followed, just ad-hominem. ]
> So, please take what Peter writes with a grain of Salt.
I don't believe such "corrections"
On Sat, Aug 13, 2022 at 03:07:22PM -0400, Peter Thomassen wrote:
> On 8/11/22 17:56, Phillip Hallam-Baker wrote:
> > NSEC record specifies what is signed but not the algorithm used to
> > sign. DNSSEC allows multiple signature and digest algorithms on the
> > same zone. If a zone does this,
On Thu, Aug 11, 2022 at 07:31:04PM -0700, Phillip Hallam-Baker wrote:
> Looks like the 'downgrade attack' is actually a consequence of the fact
> that support for multiple algorithms means that you end up with the
> security of the weakest. So not really an 'attack' but a consequence of the
>
On Thu, Aug 11, 2022 at 06:41:23PM -0400, Donald Eastlake wrote:
> So say a zone is signed by the zone owner with both BK and a strong
> algorithm denoted STRONG. As long as a resolver only trusts STRONG
> signatures I don't see how the status of what NSECs say is signed can cause
> forged data
On Thu, Aug 11, 2022 at 09:56:31PM +, Phillip Hallam-Baker wrote:
> Looks to me like there is a serious problem here.
There is not a problem with the specification. DNSSEC algorithm agility
works when implemented correctly. Now that DNSSEC adoption is finally
becoming noticeable (though at
On Thu, Aug 11, 2022 at 04:58:46PM -0600, Paul wrote:
> Should we revive the 0x20 draft?
Seems reasonable to me.
--
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
As seen at:
https://dnssec-stats.ant.isi.edu/~viktor/dnsviz/worldnic.com.html
over 400 "small" signed zones (zone apex only in the NSEC chain) return
incorrect "NODATA" RCODEs for "_25._tcp.. TLSA ?". The
provided NSEC records instead prove "NXDOMAIN". This breaks email to
these domains
On Fri, Jul 29, 2022 at 05:04:28PM -0400, Puneet Sood via dns-operations wrote:
> $ dig m.email.sonyentertainmentnetwork.com. TXT
> @e.ns.email.sonyentertainmentnetwork.com
> ;; Warning: Message parser reports malformed message packet.
> ;; Truncated, retrying in TCP mode.
Indeed this response
On Wed, Jul 06, 2022 at 11:42:14AM +0200, Daniel Baumann wrote:
> ns{1,2}-proddns.glbdns.o365filtering.com resolv to the same IP, do
> not support EDNS and don't answer on TCP queries.
Well, FWIW, the same two IPs.
On Wed, Jul 06, 2022 at 11:37:38AM +0200, Stephane Bortzmeyer wrote:
> The
On Wed, Jun 15, 2022 at 07:13:30PM -0400, Phillip Hallam-Baker wrote:
> I am of course fully aware of the commercial and technical issues that make
> it very difficult for the incumbents to address this problem. But that
> doesn't change the fact that a system designed to meet the needs of
>
On Wed, Jun 15, 2022 at 10:03:30PM +0100, John Levine wrote:
> It appears that Viktor Dukhovni said:
> >Single label names passed to getaddrinfo(3) should not result in single
> >label "A" or "" DNS queries.
>
> If only. See RFC 7085. I've been
On Wed, Jun 15, 2022 at 09:09:50PM +, Paul Hoffman wrote:
> > The IETF tends to be very conservative in leave lots of lattitude in its
> > specifications for various potential corner cases. The caution is often
> > times warranted, and yet in the same 3 decades or so nothing has changed
> >
On Wed, Jun 15, 2022 at 04:24:01PM -0400, Dave Lawrence via dns-operations
wrote:
> I'm aware "SSAC also recommends that the use of DNS resource records
> such as A, , and MX in the apex of a TopLevel Domain (TLD) be
> contractually prohibited where appropriate and strongly discouraged in
>
On Wed, Jun 15, 2022 at 01:33:51PM -0400, Dave Lawrence wrote:
> Viktor Dukhovni writes:
> > Single label names passed to getaddrinfo(3) should not result in single
> > label "A" or "" DNS queries.
>
> http://ai./
Well aware of it, and that's wh
On Wed, Jun 15, 2022 at 02:31:37PM +0200, Petr Menšík wrote:
> >> - how should single label names be handled?
> >
> > Local policy.
>
> I have made some tests. nss plugins in glibc do not allow trying single
> label applied with search domain in dns. Then try other plugins like
> llmnr. Then as
On Fri, Jun 10, 2022 at 09:16:11PM +0200, Petr Menšík wrote:
> - first is libc interface getaddrinfo() provided by nss plugins. Names
> can be resolved also by different protocols than just DNS. A good
> examples might be MDNS (RFC 6762), LLMNR (RFC 4795) or Samba
> (nmblookup). Standardized
On Mon, Jun 06, 2022 at 10:57:01AM -0400, Dave Lawrence wrote:
> I seem to be exceptionally derpy right now, but I'm realizing I can't
> articulate why it can't be done with the standard NXDOMAINs that the
> roots have been issuing all along.
If the "it" is collection of extant use of a suffix,
1 - 100 of 401 matches
Mail list logo
