> 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
dns-
On 18 Oct 2014, at 16:58, Warren Kumari 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
On 27 Jun 2015, at 14:26, Hosnieh Rafiee 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 never-ending screa
> 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 19 Jul 2018, at 19:30, Tim Wicinski wrote:
>
> For the time being, we would like to bypass the TLD server operator
> perspective. While we are in this phase of discussion, the chairs would
> like everyone to follow these guidelines:
>
> - Focus on *what* is needed.
This seems wrong
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 dif
> On 12 Mar 2019, at 15:49, Stephane Bortzmeyer wrote:
>
> the case of a commercial
> Internet access provider is clear in the other direction: a client is
> not an employee, and is entitled to a free, open and neutral Internet
> access.
Stephane, that’s simply not true. A client of an Interne
> 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 22 Jul 2019, at 21:52, Paul Vixie wrote:
>
> apparently ECS creates problems for privacy, but _how could we have
> suspected_?
IIRC the ECS privacy issues were recognised at the time. They lost out to the
argument that CDNs were already doing (or about to do) ECS and it would be
bette
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 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 t
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 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 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 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 l
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
https://www.ietf.org/mailman/list
> 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
dns-privacy@ietf.or
> 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 t
> 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 *ca
> 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 thos
> 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 v
> 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 tho
> 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: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 the
> 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
> res
> 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 fi
> 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 som
> 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 t
> 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 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 ignorin
> 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 available
> 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 ch
> 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 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
34 matches
Mail list logo
