Hi John,
If a query for a special use name, whether it's foo.onion or
7.8.9.10.in-addr.arpa, leaks to an authoritative server, NXDOMAIN is
the right answer.
not really. First of all, in-addr.arpa. zone is normal part of DNS tree
and various authoritative (depends for which zone) servers answe
On 26/11/2021 12.32, Petr Špaček wrote:
You are right right, I did not consider "crack names which do not
exist yet" scenario and focused only on dictionary reuse across zones.
Do you have specific proposals for draft text?
No, I don't have any ideas for improvements. The current salt secti
libor.peltan wrote on 2021-11-30 01:11:
...
I suggest to remove any specific errcode (NXDOMAIN, REFUSED) mentions
from such requirement. In the future, those errcodes and their names may
be altered. I quite like the Peter's original proposal, though any
wording can always be slightly impro
Peter van Dijk wrote:
> I don't think we should be prescribing extra code paths in
> authoritative servers in this document, and I think non-authoritative
> NXDOMAINs would be very confusing. In particular, resolvers would not
> believe them anyway.
>
> That all said, I can certainly see that othe
This blog post has been making the rounds. Since it is about a
sequence of DNS operational failures, it seems somewhat relevant here.
https://slack.engineering/what-happened-during-slacks-dnssec-rollout/
tl;dr first try was rolled back due to what turned out to be an unrelated
failure at some IS
Hi Paul,
for any non-root server, an RD=0 question for example.onion should be
answered with SERVFAIL. this is a condition signal, and the condition
is "since i'm hearing this query, someone thinks i'm holding a
delegation, and i'm not, so i might be lame for some zone, so the
server (me, th
A new Request for Comments is now available in online RFC libraries.
RFC 9157
Title: Revised IANA Considerations for DNSSEC
Author: P. Hoffman
Status: Standards Track
Stream: IETF
Date: November 2021
Mailbox:
I don’t see how any answer from an authoritative server other than REFUSED
really makes sense for a domain for which that server is not authoritative.
It hasn’t failed. It’s been asked a bogus question. It doesn’t make sense
for it to theorize that it might be misconfigured.
On Tue, Nov 30, 2021 a
Ted Lemon wrote on 2021-11-30 17:04:
I don’t see how any answer from an authoritative server other than
REFUSED really makes sense for a domain for which that server is not
authoritative. It hasn’t failed. It’s been asked a bogus question. It
doesn’t make sense for it to theorize that it migh
Authoritative servers should take NO SPECIAL BEHAVIOUR for .onion.
The default behaviour of an authoritative server is fine be it REFUSED,
NOTAUTH, NXDOMAIN (when they have a copy of the root zone) or a referral
to the root.
Recursive servers are a different kettle of fish.
Mark
> On 1 Dec 2021
> On 30 Nov 2021, at 1:38 pm, John Levine wrote:
>
> Can or should we offer advice on how to do this better, sort of like
> RFC 8901 but one level of DNS expertise down?
The main advice that comes to mind is to use a DNS hosting provider
with a proven (multi-year) record of doing DNSSEC reliably
>It is clear from the blog post that this is a fairly sophisticated
>group of ops people, who had a reasonable test plan, a bunch of test
>points set up in dnsviz and so forth. Neither of these bugs seem
>very exotic, and could have been caught by routine tests.
It not clear to whether or not the
Add tests to DNSVIZ to catch this sort of error. There is an open issue for
this.
--
Mark Andrews
> On 1 Dec 2021, at 05:38, John Levine wrote:
>
> This blog post has been making the rounds. Since it is about a
> sequence of DNS operational failures, it seems somewhat relevant here.
>
> ht
13 matches
Mail list logo
