On 10/9/19 8:53 AM, Xavier Beaudouin wrote:
I saw that DNS over TLS (not TCP) eg port 853/TCP is more and more used.
I expect that's due to newer Androids getting to more people? (i.e. it
seems unrelated to OP)
https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-
On 11/26/19 9:58 PM, Tony Finch wrote:
> Mirror zones (validated zone transfers) fall on the wrong side of the
> cost/benefit equation for me. But I might change my mind if there were
> better security for unauthenticated records (NS and glue)
These are why we only implemented the mechanism over H
Hello,
apex CNAME is inherently incompatible with forwarding, as I see the
standards *now*.
I wonder if such special-casing of some types like DNSKEY could solve
(almost) all issues with CNAME at apex. (additional candidates off the
top of my head: NS, SOA, DNAME?) I didn't think it through suff
On 2/4/20 9:57 PM, Vicky Shrestha wrote:
> We have identified the bug in a new version that was released to a
> subset of colos. We have rolled out a fix.
>
> how does it look now from your vantage point?
The problem got fixed from my vantage point.
I had also re-checked against fresh Knot Resolv
On 2/7/20 10:51 AM, James Stevens wrote:
>> - You would be surprised how slow UDP packet processing in kernel can
>> be ;-)
>
> Often UDP slowness is due to the fact that each packet requires a
> context-switch from kernel to user-space, and back for the reply.
>
> So the bottleneck on a DNS server
Hello.
For me personally, the old historical data isn't much interesting. What
I'm missing most is the feature of sending a link to a recent
measurement (and keeping the data for, say, a week at least).
Thanks for the service anyway :-)
--Vladimir
__
Hello.
On 2/26/20 11:51 PM, Brian Somers wrote:
> - Servers (nameservers or resolvers) do their best to reply as asked
>
> The client wants the data and can decide on what risk the chosen
> bufsize implies in their environment. Servers can apply practical
> limits to bufsize to avoid large
Hello.
On 3/27/20 6:44 AM, Stephane Bortzmeyer wrote:
> Some resolvers protest on .in. It seems they have a RSASHA256 key but
> no RSASHA256 signatures, thus violating RFC 4035, section 2.2 "There
> MUST be an RRSIG for each RRset using at least one DNSKEY of EACH
> ALGORITHM".
Note that in this
Hello.
On 3/29/20 1:23 PM, Meir Kraushar via dns-operations wrote:
> If any compatibility issues, client side problems, resolvers etc?..
If the DNAME should reside in a signed zone, you may expect some
resolver issues, though probably not too often (I'm unable to really
estimate how much). I kno
On 3/31/20 6:47 AM, Brian Somers wrote:
> One useful thing I could say (If you haven’t hit delete yet) is that I *HAVE*
> seen RRSIGs with compressed signers in the wild, so never assume that, just
> because RFCs say MUST NOT, you’ll never see these horrible things.
Sure, validators MUST NOT cra
On 3/31/20 6:29 AM, Tessa Plum wrote:
> When making a DNS query (giving the type is A) to an authorized
> nameserver to its IPv6 address, will the value in answer are also IPv6
> addresses? If the host doesn't have an IPv6 address, how will DNS
> server return?
No, A always means IPv4 address. E
On 4/16/20 10:04 PM, Viktor Dukhovni wrote:
> Any chance you're also fixing the (likely DNAME-related) issue that's
> breaking resolution of:
"Right now" I'm finishing the support for DNAMEs in Knot Resolver at
https://gitlab.labs.nic.cz/knot/knot-resolver/-/merge_requests/965
Perhaps Cloudflare
(I don't react to the SERVFAIL from CloudFlare auth.)
On 4/19/20 8:55 AM, Viktor Dukhovni wrote:
> the NSEC RR promises TLSA records, among a rather oddball mix of
> other rrtypes
I believe that's normal for CloudFlare authoritatives, and so far I've
noticed no real problems from that, apart from
On 4/19/20 6:49 PM, Viktor Dukhovni wrote:
>>> I believe that's normal for CloudFlare authoritatives, and so far I've
>>> noticed no real problems from that, apart from effects like less
>>> efficient caching. Description:
>>> https://blog.cloudflare.com/black-lies/#dnsshotgun
> It can't be "norma
On 4/20/20 12:24 PM, Raffaele Sommese wrote:
> So, why these records are in the .com authoritative server? Is it
> optimization for Cloudflare?
Let me add resolver point of view.
As noted, these records are not required but are in bailiwick of .com,
so it's reasonable to trust their value and spe
Hello.
On 8/25/20 5:12 PM, Warren Kumari wrote:
> unlike other OARC tools this isn't
> "use your existing tools like dig and a browsers", it's "go and
> install yet another app".
I seem to miss the point here. Mattermost client runs perfectly fine in
a web browser (on non-mobile at least). Same
On 9/1/20 9:58 AM, Stephane Bortzmeyer wrote:
> AFAIK, Cloudflare uses Knot Resolver. I tested with another Knot
> resolver and it works:
I think they originally started the service quite close Knot Resolver
code, but they've apparently diverged quite a bit since then (I don't
know). To be sure,
On 9/9/20 10:39 AM, Petr Špaček wrote:
> The reason is that the effective EDNS buffer size is the minimal value from
> (client, server) pair. [...]
Hopefully the auths deployed in practice (almost) always respect the
upper bound sent by client. Unfortunately it's harder to test that
against arbi
Hello.
On 2/8/20 8:33 AM, Viktor Dukhovni wrote:
> Unfortunately, I don't see a way to separately configure the *upstream*
> and *downstream* EDNS buffer sizes.
It's been long but for Knot Resolver we now merged that split, so since
the first post-flag-day release you can specify both values sepa
On 9/11/20 4:44 PM, Paul Hoffman wrote:
> If this is really just a vendor-driven flag day, please be clearer about that
> on the web page.
The GitHub repo and other places have been open for *everyone* to
participate in the discussions. That's how I understand the "we",
similarly to "we DNSOP".
On 9/11/20 9:14 PM, Randy Bush wrote:
>> The main issue with having the discussion on github, is that it is a
>> discussion on github, not on a major mailing list involving the
>> operators and folks doing independent implementations.
> for cabals which like a bubble, this is a feature, not a bug
On 9/11/20 8:29 PM, John Levine wrote:
> Are there any published numbers estimating how well the various DNSSEC
> algorithms are supported in DNS caches and client software?
Off the top of my head: https://dnsthought.nlnetlabs.nl/#ecdsa256
but 13 in particular feels quite deployed in zones - I kn
65 is the upcoming "HTTPS" RR, so perhaps testing future browser
features or something.
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
(The other one is in "private use" range and I don't recognize it off
the top of my head.)
___
d
On 10/30/20 5:29 AM, Paul Vixie wrote:
> systemd is pretty configurable. there should be some way to turn this
> DNS-like but not-actually-DNS listener off, and then either run a real
> DNS listener (unbound, bind9, powerdns, knot, etc) there.
Yes, systemd-resolved is an optional part of systemd,
Hello.
On 10/29/20 8:31 PM, Phil Pennock wrote:
> the alternatives for a roaming laptop are even buggier (in the
> resolver management, rather than in the actual resolver).
Can you expand a bit on what you mean by this? I think people here are
more likely to affect some of the alternatives rathe
Hello.
First of all, I do hope you won't rely on how implementations do this
(except aspects that are mandatory in standards-track RFCs). Note that
even the delegation-revalidation draft in its current state plans just
some SHOULDs and no hard obligations:
https://tools.ietf.org/html/draft-ietf-d
On 11/18/20 1:36 AM, Phil Pennock wrote:
> Double-check: in such a scenario, if the request is for the recursive to
> validate DNSSEC and this zone is not opt-out, then the recursive would
> HAVE to get the data from the child, because the parent won't have RRSIG
> records for the glue NS, right?
>
On 12/25/20 1:12 AM, Robert Edmonds wrote:
I'm also seeing intermittent SERVFAILs with www.cdc.gov.
Some of their answers are broken. We now had a discussion about it on:
https://gitlab.nic.cz/knot/knot-resolver/-/issues/662#note_188577
--Vladimir
On 1/5/21 5:52 AM, Paul Hoffman wrote:
I brought the issue to this mailing list, instead of to the UltraDNS folks,
because I am using tools that expect host names instead of domain names (in
this case, dig); now I have to write shims around them.
In case it helps you, kdig escapes punctuation
On 1/5/21 8:21 AM, Viktor Dukhovni wrote:
On Tue, Jan 05, 2021 at 08:07:16AM +0100, Vladimír Čunát wrote:
Off the top of my head, I don't even now how exactly is the escaping
specified in RFCs.
That's easy, any*non-digit* character can be escaped with a preceding
"\", or
Hello everyone!
On 1/18/21 7:57 AM, Viktor Dukhovni wrote:
The non-empty salt is pointless, but basically harmless.
Why should salt be pointless? Can you hint/link?
Quick link to original motivation:
https://tools.ietf.org/html/rfc5155#appendix-C.1
(Though it seems relatively weak to me...
On 1/18/21 7:55 PM, Viktor Dukhovni wrote:
The non-empty salt is pointless, but basically harmless.
[...]
Because:
1. Every zone is effectively already salted, because as you
note below the hash covers the FQDN.
2. Changing the salt takes some care, so "nobody" does it.
On 1/18/21 11:41 PM, Viktor Dukhovni wrote:
For the salt to makes sense, and warrant rotation, one would have to
operate a zone with enough records that some are hard to predict,
sensitive and yet published (and not visible in transparency logs,
PTR records, ...). This is very much a corner case
Hello.
On 2/8/21 3:00 PM, Anthony Lieuallen via dns-operations wrote:
Is this (NXDOMAIN status, but CNAME and RRSIG in the answer) valid,
per the spec
In case of a CNAME chain, the RCODE refers to the end of the chain (i.e.
past the last present CNAME). All CNAMEs in the ANSWER section are
On 2/28/21 3:24 AM, Paul Hoffman wrote:
On Feb 27, 2021, at 5:32 PM, Mark Andrews wrote:
It says that RRSIGs exist at that name.
Could you say more? I don't understand the context here.
For example, "dig @f.root-servers.net -4 nl rrsig" gives a reply with no Answer
section.
Explicit QTYPE=
On 2/28/21 8:47 PM, Paul Hoffman wrote:
[1]https://tools.ietf.org/html/rfc8482#section-7 [tools.ietf.org]
That RFC (a) doesn't update RFC 4025 and (b) is only about QTYPE of "ANY".
I meant just the informal future-work note focused on QTYPE=RRSIG (in
the linked section), to support my claim
On 2/28/21 10:11 AM, Bill Woodcock wrote:
We put in negative trust anchors where safe and necessary to keep things
working for actual users, because if we don’t, we get drowned by support calls.
My (naive?) hope is that large validating services could form some
agreement to start acting stric
On 3/2/21 2:23 PM, Peter van Dijk wrote:
My suggestion (seriously): prohibit NSEC and RRSIG queries. They are
ambiguous and nobody has any use for their output anyway. Not
supporting them can really simplify some implementations as well (I
submit RFC 8482 as exhibit A.)
+1 In the sense that I
On 3/11/21 9:21 AM, Matthijs Mekking wrote:
which apparently has a DS at the apex of the child zone, which is
somewhere between 'useless' and 'wrong'.
It is more wrong than useless: From RFC 4035:
All DS RRsets in a zone MUST be signed, and DS
RRsets MUST NOT appear at a zone's apex.
On 13. 04. 21 18:40, Viktor Dukhovni wrote:
- With NSEC you benefit from aggressive negative caching reducing
query load on your authoritative server.
Tiny detail: NSEC3 without opt-out also allows aggressive caching with
the same benefits but it's less common. (so NSEC does give
On 05/06/2021 13.11, A. Schulze wrote:
Is "being client centric" a candidate for a "dns-flag-day-2022"?
Consider .com like to intercept gmail.com. Changing the delegation in .com
would be enough. Really?
The parent has full control of its subtree anyway. They can even roll
the DNSSEC key of
It's not just a problem for NXDOMAIN. Their DNSKEY response is over
1250 bytes, so those who use a lower limit (e.g. 1232 recommended by
dnsflagday.net/2020) will have no access to that subtree at all.
--Vladimir
___
dns-operations mailing list
dns-o
On 18/08/2021 01.49, Paul Ebersman wrote:
DNS is a complicated, esoteric knowledge set. The reason apps,
middleware and various other boxes mucking with DNS in transit tend to
suck is exactly because the programmers on those boxes don't have this
expertise and make all sorts of bad assumptions ab
On 30/08/2021 17.02, Petr Špaček wrote:
[...] It is clear to this group of DNS experts, but I think we should
lend a helping hand to DNS consumers and at least explain why
consumers have to check everything.
Is anyone interesting in writing a short RFC on this topic?
That might serve as a g
On 05/09/2021 19.31, Andrew Sullivan wrote:
This is false in multiple ways. First, RRSIGs are in fact resource
records and it _is_ possible to query for them directly:
I would not advise using QTYPE=RRSIG. Mainly because you may get sigs
for some other versions of RR sets than those obtained
Hello.
On 08/09/2021 11.12, Ruben van Staveren via dns-operations wrote:
should we do more analysis of this phenomenon and even have a dns flag
day before even more resolvers and operators are going to implement
RFC8198? There might be an issue by deliberately exploiting this and
make websites
On 05/10/2021 18.01, Frederico A C Neves wrote:
I would like to start a discussion or to hear implenters and operators
of Full-service resolvers on what would be the best software
architecture or best current configuration practice to handle a
traffic pattern when a very popular name enters a sce
On 20/10/2021 20.01, Viktor Dukhovni wrote:
This is IIRC a well-known longstanding issue.
Yes, non-support of TCP certainly isn't new there:
https://dnsviz.net/d/glb.cdc.gov/Xp3Epw/dnssec/
___
dns-operations mailing list
dns-operations@lists.dns-oarc
On 25/11/2021 08.54, Juselius Juhani via dns-operations wrote:
-Is there anything we could do for the traffic
I'm sure it would lighten your load if you ensured that even negative
replies from your servers can fit into UDP comfortably, ideally under
1232 bytes [1]. Many big TLDs ta
On 17/01/2022 11.00, Matthew Richardson wrote:
Given that having a standby key is a standard (and probably good!)
practice, should Zonemaster perhaps classify this as less of a problem,
maybe as a "warning"?
I already opened
https://github.com/zonemaster/zonemaster/issues/1036
On 07/02/2022 19.27, Matthew Richardson wrote:
Knot Resolver returned NXDOMAIN
Are you sure that you used the latest version? (5.4.4, a month old)
Bug details: https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1237
--Vladimir
___
dns-operat
--- Begin Message ---
On 4/21/22 03:15, Mark Andrews wrote:
My main worry is this, correct, cache behaviour breaks DNSSEC validation
through a recursive
server.
Yes, same with Knot Resolver. When communicating with auths directly it
does work I think, but it never worked with forwarding when
--- Begin Message ---
On 23/05/2022 15.48, Thomas, Matthew via dns-operations wrote:
Configuration 1: Generate a synthetic NXDOMAIN response to all queries
with no SOA provided in the authority section.
I believe the protocol says not to cache such answers at all. Some
implementations chose
--- Begin Message ---
On 06/06/2022 16.57, Dave Lawrence wrote:
To be clear, I'm not saying they*should* do it. I'm just trying to
better understand the context.
If the root zone is unchanged, many names could be hidden before
reaching root servers - by DNSSEC aggressive caching and/or vario
--- Begin Message ---
On 06/07/2022 11.01, Thomas Mieslinger wrote:
Anyone else with trouble to reach the *.o365filtering.com DNS Servers?
I believe that's discussed here:
https://chat.dns-oarc.net/community/pl/m864xf3xrf8adqm8kx6sdku6bo
--- End Message ---
___
--- Begin Message ---
On 22/09/2022 16.12, BS Domain Technical Contact wrote:
Please provide an update regarding the same. Thanks.
I'm still getting NXDOMAIN. It's fairly easy for anyone to check by
running e.g.
dig @ns36.cdns.net com.bs.
--- End Message ---
___
--- Begin Message ---
On 27/03/2023 17.09, Viktor Dukhovni wrote:
On the fly signing with compact denial of existence is a bleeding-edge
behaviour, and one might expect that the software in question is not
ossified and operators might be proactive.
Cloudflare's blog post about this is from 2016
--- Begin Message ---
On 18/07/2023 23.53, Viktor Dukhovni wrote:
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
--- Begin Message ---
On 29/07/2023 23.20, Puneet Sood via dns-operations wrote:
The worst are the small number that return NXDOMAIN for the queries or timeout.
Those are clear protocol violation, as the names are case insensitive
from the very beginning (RFC 1034 + 1035), regardless of deploy
--- Begin Message ---
On 29/07/2023 13.52, Stephane Bortzmeyer wrote:
As usual, a good practical article by Julia Evans:
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
--- Begin Message ---
On 01/11/2023 17.18, Viktor Dukhovni wrote:
Should authoritative resolvers have knobs to perform internal checks on
the signed zones they serve and at least syslog loud warnings?
My understanding is that in this case the signer was producing loud
syslog warnings immediate
--- Begin Message ---
On 06/02/2024 17.06, Peter Thomassen wrote:
Then, how to define a false positive rate?
Look at all blocked queries, and do a post-hoc investigation?
How about popularity -- should one factor in that blocking *.ddns.net
is more severe than blocking *.blank.page? I.e., is i
--- Begin Message ---
On 02/04/2024 20.44, Christoph via dns-operations wrote:
Do you know any DoH client software that is actually deployed and used
in real world that does not support HTTP/2 yet?
I know that some MikroTik routers used to support 1.x only. (Knot
Resolver ever only supported
--- Begin Message ---
On 28/02/2025 01.00, Damian Menscher via dns-operations wrote:
Focusing on specific records, domains, DNS servers, or even the DNS
protocol itself will not solve your problem. There are a dozen
different protocols which are abused for UDP amplification.
UDP fragmentation
--- Begin Message ---
On 03/04/2025 15.18, Emmanuel Fusté wrote:
- DNS should never completely stop responding to one IP, just as it
should never arbitrary alter the value of an answer.
Ideally yes, but... here's a consideration: if you don't reply or make
some reply that looks like an error,
65 matches
Mail list logo
