> On 4 Sep 2023, at 12:32, Florian Obser via Datatracker via dnsdir
> wrote:
>
> -12 does not address the issues that were introduced in version -11.
> The status of my review does not change.
Many thanks Florian.
___
dns-privacy mailing list
> On 11 Nov 2021, at 15:28, Christian Huitema wrote:
>
> It is not uncommon to see upgrades being rolled out at different times to
> different servers in the farm. Opportunistic strategies and probing
> strategies have to deal with that.
This can be complex. Lots of busy domain names (like
> On 1 Apr 2021, at 14:04, Stephane Bortzmeyer wrote:
>
> RFC 793 is 39 years old. Let's drop TCP and move to QUIC (the RFCs are
> in the RCF-EDITOR state).
>
> And I'm too charitable to mention the age of DNS RFCs
You should be above whatabootery* Stephane.
>> Some other risks have changed
> On 31 Mar 2021, at 14:05, Stephane Bortzmeyer wrote:
>
> RFC 7626 (the threat model and problem analysis
> that some people claim is missing) is clear (section 2.5.2 for
> instance).
Stephane, RFC7626 is 6 years old. It predates the DoH and DoT (and soon DoQ)
specs. Some other risks have
> On 31 Mar 2021, at 13:58, Stephen Farrell wrote:
>
>> And is TLS the *only* game in town?
> When encrypting DNS based on some standard protocol? It is
I know that Stephen. The point I was trying (and apparently failing) to make
was there are other privacy-friendly tools/protocols
> On 31 Mar 2021, at 13:33, Brian Haberman wrote:
>
> I was wondering the same thing. 8806 would definitely preclude the need
> to support encryption at the root.
This is one of the things that puzzles me about the current discussion. The WG
seems to be pushing TLS-based solutions and
> On 31 Mar 2021, at 01:08, Erik Kline wrote:
>
> "Root Server Operators do not feel comfortable being the early adopters
> of authoritative DNS encryption and would like to first see increased
> deployment in other parts of the DNS hierarchy."
>
> Seems fair to me, for the time being.
> On 24 Mar 2021, at 14:10, Bill Woodcock wrote:
>
> How many mqps are necessary to have a voice in your vision of
> multistakeholderism?
I don’t know.
I think/hope we have the same vision of multistakeholderism. If not, that’s a
conversation for another time and place.
> Or, viewed from
> On 24 Mar 2021, at 13:34, Bill Woodcock wrote:
>
> I’m still looking for those reasons. Could you enumerate them again?
No. You can re-read my earlier mail which enumerated those reasons. If you want
to discuss specifics, I’m happy to do so. Though the issue of SVCB records in
TLDs is
> On 23 Mar 2021, at 22:32, Paul Wouters wrote:
>
> So what is it that you are exactly objecting to? The syntax or the capability?
The capability - mostly. TLDs should not be publishing SVCB records for the
reasons I outlined before.
I’m not too keen on using SVCB records apart from stubs
> On 23 Mar 2021, at 21:20, Ben Schwartz
> wrote:
>
> I think there's a miscommunication here. The proposals here are about how a
> TLD operator can tell a **recursive resolver** what encrypted DNS server to
> use, exactly like an NS record. This is not suggesting any change to stub
>
> On 23 Mar 2021, at 14:56, Paul Wouters wrote:
>
> The point of putting them into a TLD would be to be able to build up a
> secure private connection to the TLD nameserver, before issuing a target
> domain query within the TLD.
These things can be done without needing SVCB records. Though
> On 23 Mar 2021, at 14:54, Bill Woodcock wrote:
>
> There are a million clever and useful things that you could do, if it were
> possible. Which are particularly valuable for brand TLDs, for instance.
IMO, the IETF shouldn’t get into developing protocols just for the benefit of
here today,
> On 23 Mar 2021, at 14:16, Brian Haberman wrote:
>
> Is there an issue with putting SVCB info in the TLD zones?
Yes - for gTLDs. Almost all of them have contracts with ICANN. Adding SVCB
records to ccTLDs is easier (in principle) since few (any?) of them have
contracts with ICANN. Since
> On 18 Mar 2021, at 16:21, Eric Orth
> wrote:
>
> I disagree with your assumption that clients/users are only concerned about
> particular resolvers.
Eric, I didn’t make any assumptions about that at all. It was Tommy who said
ODNS would benefit those who were concerned about leakage to
> On 18 Mar 2021, at 15:42, Tommy Pauly
> wrote:
>
> Instead, cases where clients are particularly concerned about revealing
> client IP and identity to very large public resolvers benefit more from this.
There’s a much easier and far quicker solution for that problem. Clients who
have
> On 8 Feb 2021, at 17:11, Paul Hoffman wrote:
>
> Without a fleshwd-out proposal for a fully-authenticated protocol to compare
> to, saying that this WG should not try to fulfill its charter to help encrypt
> recursive to authoritative traffic just seems wrong.
Paul, just because the WG
> On 8 Apr 2020, at 17:55, Paul Hoffman wrote:
>
> This draft is better than earlier versions, but still is missing something
> that seems crucial: detailed comparison between the protocol described here,
> DoT, and DoH. The suggestion in the text that the comparison would be added
> after
> On 8 Apr 2020, at 17:41, Tim Wicinski wrote:
>
> This starts a Call for Adoption for draft-huitema-dprive-dnsoquic
I support adoption of this ID and am willing to review and maybe contribute
text.
___
dns-privacy mailing list
Could the people on this thread *please* trim their postings? It's hard to
track the discussion when every email contains a jumbled set of a gazillion
postings. Thanks.
___
dns-privacy mailing list
dns-privacy@ietf.org
> On 30 Oct 2019, at 06:37, Watson Ladd wrote:
>
> The root zone is data: whether one distributes it via DoT, DoH, IPv6, or
> carrier pigeon is irrelevant to the policies that goven what's in it.
I agree. But that's orthogonal to what I thought we were discussing.
There are gazillions of
> On 31 Oct 2019, at 01:21, John Levine wrote:
>
> In article
> you
> write:
>> Encryption at the root is very possible.
>
> Indeed, but that's not the same question as whether it's a good idea.
+1
>
> ...
> Let's put this in the pile of things to think about later.
+1 to that too.
> On 30 Oct 2019, at 18:40, Livingood, Jason
> wrote:
>
> I agree that this is not a technical issue of scaling the root; that quantity
> of queries per day and second is not a big problem. Rather, as you note, it
> is a layer-9 issue. But I don't think we should constrain our requirements
On 30 Oct 2019, at 03:48, Jim Reid wrote:
>
>
> NB Offlist
Sigh.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On 30 Oct 2019, at 01:32, Eric Rescorla wrote::
> Do we have estimates of the load level here as compared to (say) Quad9 or
> 1.1.1.1?
NB Offlist
Take a look at how long it took for the root server operators (RSOs) to make
their infrastructure DNSSEC-capable. Each of them understandably took
On 30 Oct 2019, at 01:32, Eric Rescorla wrote:
>
>> Yes, it's hard, but I think it's worthwhile, because the prospect of getting
>> the root to offer ADoT seems very distant to me.
>>
> Why? Do we have estimates of the load level here as compared to (say) Quad9
> or 1.1.1.1?
The root server
> On 12 Mar 2019, at 16:01, Stephane Bortzmeyer wrote:
>
> I still do not understand why people have a problem with DoH whch did
> not already exist before with my-own-name-resolution-protocol-over-HTTPS.
It’s a question of scale/ubiquity. These “alterate” resolution tricks have up
until now
On 19 Jul 2018, at 21:17, Tim Wicinski wrote:
>
> For example, Verisign has .com which is quite large. My Employer has domains
> at the SLD issue that 'currently' has > 100MM records.
>
> Are the difference serving records vs serving delegations?
I doubt response sizes will be markedly
> On 18 Jul 2018, at 19:25, Barry Raveendran Greene wrote:
>
> I support the adoption of this work into the WG.
+1
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
On 27 Jun 2015, at 14:26, Hosnieh Rafiee i...@rozanak.com wrote:
but exposing such critical information to public is against privacy rights
So get your local law enforcement and/or legislature to intervene. Please take
your complaints there.
If you want to join in the latest battle in this
On 18 Oct 2014, at 16:58, Warren Kumari war...@kumari.net wrote:
A: keep the list name as dns-privacy@
+1
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
31 matches
Mail list logo
