It appears that Paul Hoffman said:
>Is there widespread availability for "ACME certs" for authoritative DNS name
>servers that have no web server component reasonably available
>now? When I looked a few years ago, they weren't at all.
I have over 300 certs here all using DNS verification. I use
I think it's in pretty good shape but of course I have a few questions.
In 3.3, it says to match queries and responses "using the ID field and
port number". I get the ID field, but the port number? In a TCP
session? This language appears to be copied from 5966bis, where it
seems to have been co
In article you write:
>I support the adoption of this document, knowing that there is still a
>bunch of research that needs to be done before we can specify good
>profiles.
As I said at the microphone, I'd like to adopt it, and then stall it
until we have enough research data to narrow down the
In article <57202511-6de3-4bea-b65e-afbcaff40...@bellis.me.uk> you write:
>(I meant UKNOF, not UKNOT)
>
>https://www.youtube.com/watch?v=3tMGD6J04Jk
>
>Sara took a *lot* of off-mic discussion after that session, too.
I gather mandatory DNS blocks like this are common throughout Europe,
with target
and doesn't even consider the extent to
which WHOIS info is used (or at least was used when it was available)
to protect phishing and other attacks against individuals privacy
and security.
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Pl
Until we tame this horse, it's premature to
start choosing paint colors for the cart.
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
In article
you write:
>
>I appreciate the authors kicking off the effort with this draft that
>proposes phase 2 requirements.
As do I, but it still needs a lot of work.
One thing that would help me a lot is matching up the features with
what problem they're supposed to solve.
* Keeping specifi
In article
you write:
>> 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 load has nothing to do with it. Surely you're
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.
It is my strong impression that whatever problem you would solve with
DoT to the root can also be solved using a local copy of the root,
which has the practical
In article
you write:
>I think there will be both interest and deployment, sufficient to justify
>the effort.
I hope so, but some actual comments from large DNS operators would be welcome.
>root-servers.net be DNSSEC signed, but without a secure delegation. ...
Do any DNS resolvers use root-se
In article
you write:
>I may have misunderstood John, of course, but that's the point of what I
>understood him to be saying.
Pretty much.
The root is an unusual zone in that it is small and unlikely ever to
be huge, it is easy to AXFR without prior arrangement, and its
management is subject to
In article
you write:
>The ideas floated here about ADoT to the root are not, in my view, about
>privacy (directly). They're about using ADoT to protect the integrity of
>(currently) unsigned data in the root zone.
>
>An alternative solution is to get ADoT bootstrap info from the child zone,
>wh
In article
you write:
>Conversely, what made opportunistic style approaches viable for
>SMTP was that there was an existing protocol handshake that
>could be conveniently adopted to have upward negotiation (STARTTLS). ...
>In this case, I think the relevant question is whether there is some
>via
I thought it might be useful to make a list of possible ways to signal
that a server offers ADoT:
https://datatracker.ietf.org/doc/draft-levine-dprive-signal/
I'm sure there are others, feel free to send suggestions.
R's,
John
___
dns-privacy mailing
In article
you write:
>> Again, that would be russian roulette. If I get an NS RRset with 3
>> nameservers, and only one of these has a TLSA record, what should I
>> do ?
Dunno about you, but I'd make a note not to hire that provider to run my DNS.
People can set up any sort of DNS badly, and e
In article you write:
>> That's per-zone, though, whereas DoT support is per-server.
>
>Maybe that's ideal, but one would expect that a zone only rolls this
>out once all their nameservers support it.
Most of my zones have a secondary run by somebody else, whose software
is never in sync with min
In article <711d51d8-8786-6bdd-b95f-d968781b0...@huitema.net> you write:
>Note that port 853 is a convention. Servers could trivially run multiple
>services over port 443, and demux based on the ALPN. I suppose that if
>we see a lot blockage of port 853, servers will just do that -- run on
>port 44
In article <7f87e623-3d21-4061-816b-1b18faed3...@icann.org> you write:
>- It will cause confusion because there will be two ways to do DoT, so a
>client might have to test each way
>in order to know if the resolver supports DoT.
I have no objection to reserving an ALPN ID for DoT for use by priva
In article
you write:
>Well, the client could just use the zone name as the SNI, no? You can assign
>certificates with the same name but different keys to each of the
>nameservers.
That sounds quite painful for servers that serve hundreds or thousands of zones.
I am assuming these would be self
In article
you write:
>That leaks information to an attacker ONLY if the attacker has successfully
>caused the resolver to get the wrong NS name at the first step.
>
>There is a method for preventing that: if the delegating name server (e.g.
>TLD) supports DNS-over-TLS-to-Authority (DoTA), and th
In article
you write:
>Assuming this traffic is encrypted, which I am in favor of, the CPU load on
>the authoritative server will increase after an outage or network problem.
>
>Is this already factored in?
How is that diffferent from now? If a DNS server is offline and comes
back online, it wil
In article you write:
>I am against adoption for two reasons. The draft as it currently is,
>requires that domain name owners and nameserver hosting administrators
>synchronise their nameserver TLS keys.
Why wouldn't you publish multiple DS records for multiple nameserver
keys, like the draft say
In article you write:
>Please see
>
> https://tools.ietf.org/html/draft-pp-recursive-authoritative-opportunistic-01
>This isn't a WG document yet, but if the WG wants it, I think it could work
>well within the charter, and with the discussion of
>draft-ietf-dprive-phase2-requirements.
I'm ha
It appears that Brian Haberman said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Hi all,
> In the interest of moving work forward, the chairs would like to
>solicit reviews for
>https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-02
>
>We are especially interested in implementer and operator views
24 matches
Mail list logo
