>From the browser engineer perspective:
- I agree that a registry of some sort is needed. I don't necessarily
envision that the registry would contain public resolver URLs (or at least
not exclusively resolver URLs) but rather entities like public legal
databases or transparency reports. Because t
Moin!
On 7 Nov 2024, at 15:19, Ben Schwartz wrote:
> I think this proposal is promising, but I agree with Stephane that the
> registry of participating resolvers is unappealing. However, I believe it is
> also unnecessary. Instead, the EXTRA-TEXT can simply convey an "https://";
> URL for th
On Thu, Nov 07, 2024 at 11:34:36AM +,
Petr Špaček wrote
a message of 10 lines which said:
> Can be something done about it?
>
> Given enough imagination, can we invent something like DNS traceroute?
There have been some attempts. This one is good:
https://github.com/farrokhi/dnsdiag/
It appears that Shane Kerr said:
Since I noticed the ZONEVERSION RFC 9660, I was thinking that this
could be extended to include a version at the database.
>> I think this is prime example of a Private Use value. It would be
>> specific to SIDN implementation and does not need any code
I just saw your presentation in DNSOP and read your draft, and I have a
couple of comments.
1. You refer to "navigational integration" as information about the
application environment that is stored in the DNS zone. However, the WALLET
RRTYPE (see
https://www.iana.org/assignments/dns-parameters/WA
Ralf,
The "same-domain" requirement here serves two main purposes:
1. Prevent DDoS attacks. A malicious DNS server could cause a large number of
clients to fetch incident reports from an arbitrary victim server. (c.f. Great
Cannon [A])
2. Block reports that transited a naive forwarder. Thes
On Thu, 7 Nov 2024, Stefan Ubbink wrote:
You have to know what kind of version numbers the database uses to
know what the value means. I agree this is a private extension.
I would argue that you wouldn't need to know what the value means, if
it is a number and it always changes in a predictabl
On Thu, 7 Nov 2024 17:42:04 +
Petr Špaček wrote:
> This is a very high-level description of the problem space. Let's
> discuss! Preferably in person for initial high bandwidth discussion
> and then we can continue on the mailing list once the initial round
> of arguing is finished.
A very l
On 7 Nov 2024 18:36:34 +
"John Levine" wrote:
> It appears that Shane Kerr said:
> Since I noticed the ZONEVERSION RFC 9660, I was thinking that
> this could be extended to include a version at the database.
> >> I think this is prime example of a Private Use value. It would be
I don’t think you intended this - but for DNSSEC validation, the set has to be
sorted so don’t MUST NOT that … but I get that this is just a matter of wording
in a suggestion. Perhaps, “shuffle on send/reply” is what is desired, what a
protocol element does internally is up to its maker.
The r
On 07. 11. 24 17:01, Stephane Bortzmeyer wrote:
On Thu, Nov 07, 2024 at 11:34:36AM +,
Petr Špaček wrote
a message of 10 lines which said:
Can be something done about it?
Given enough imagination, can we invent something like DNS traceroute?
There have been some attempts. This one is
> On 8 Nov 2024, at 6:47 AM, John Kristoff wrote:
>
> On Thu, 7 Nov 2024 17:42:04 +
> Petr Špaček wrote:
>
>> This is a very high-level description of the problem space. Let's
>> discuss! Preferably in person for initial high bandwidth discussion
>> and then we can continue on the mailin
> On 7 Nov 2024, at 19:47, John Kristoff wrote:
>
> On Thu, 7 Nov 2024 17:42:04 +
> Petr Špaček wrote:
>
>> This is a very high-level description of the problem space. Let's
>> discuss! Preferably in person for initial high bandwidth discussion
>> and then we can continue on the mailing l
Petr,
On 07/11/2024 11.23, Petr Špaček wrote:
On 06. 11. 24 9:09, Stephane Bortzmeyer wrote:
On Wed, Nov 06, 2024 at 09:13:26AM +0100,
Stefan Ubbink wrote
a message of 69 lines which said:
Since I noticed the ZONEVERSION RFC 9660, I was thinking that this
could be extended to include a v
On 05. 11. 24 11:56, Shane Kerr wrote:
I wrote a quick draft to specify that answers returned should be
returned in a random order:
https://datatracker.ietf.org/doc/draft-kerr-everybodys-shuffling/
This comes out of recent experience we had where a customer saw
significant bias in how their s
On 06. 11. 24 9:09, Stephane Bortzmeyer wrote:
On Wed, Nov 06, 2024 at 09:13:26AM +0100,
Stefan Ubbink wrote
a message of 69 lines which said:
Since I noticed the ZONEVERSION RFC 9660, I was thinking that this
could be extended to include a version at the database.
Yes, good idea. It wil
Hi!
Have you ever debugged DNS forwarding topology with no clear idea where
the packets go and why?
Can be something done about it?
Given enough imagination, can we invent something like DNS traceroute?
If you are interested in this topic catch me after dnsop session today
and we can discus
I would support a draft that says "every authoritative, recursive, forwarder,
stub, and application SHOULD shuffle the RRset, and MUST NOT sort it". Yes, it
would suffice that any one of them complies with this recommendation, but the
more components comply, the lower the risk of a biased overa
On 7 Nov 2024, at 15:11, Ben Schwartz wrote:
> Each registry entry implicitly normalizes this filtering rationale as a
> behavior deemed acceptable by the IETF.
The point of these code points is to provide an opportunity to describe things
that happen in the real world to the benefit of end us
I requested a stricter registration policy because of the "suberror" registry,
which includes codes indicating blocking due to "Malware", "Phishing", "Spam",
and "Spyware". These are far from the only reasons that DNS servers refuse to
answer queries. Other common reasons include "Pornography"
Mark, Stephane, and I have had several discussions about greasing this
week, and I thought I'd share some of this on the list, while folks are
paying more attention to IETF121.
The greasing draft currently only talks about greasing initiated by the
resolver or querier. During the hackathon, we hav
I think this proposal is promising, but I agree with Stephane that the registry
of participating resolvers is unappealing. However, I believe it is also
unnecessary. Instead, the EXTRA-TEXT can simply convey an "https://"; URL for
the Incident Description. The client can enforce that this URL
Mark wasn't able to make it to IETF/hackathon in person this time, but I'm
sharing the results of his preliminary greasing experiments, which I think
the group should find useful. Operators of the identified auth servers may
want to take note (perhaps this should be shared on the dns-operations lis
23 matches
Mail list logo
