Yeah, I have to agree with Ekr and Rich here. However, if the issues are so
widespread to make a deal breaker as some say, that will inhibit adoption.
After all, the IETF can't make people use ECH, and it's easy enough to
strip the ECH extension at the cost of interoperability. Obviously, the WG
th
Hi Martin and Mark,
I think you're off-base here, so much so that I can't tell if you're
serious. It's a cultural issue, not a technical one.
See: https://en.wikipedia.org/wiki/Alt.*_hierarchy
l don't want to read any of those Usenet groups, but they do exist. This is
just a way of framing such
On Sun, Sep 25, 2022 at 1:28 PM Paul Hoffman wrote:
> >
> > that part of the reluctance to deploy has been immaturity of tools, and
> lack of
> > skilled technical staff. At least the tooling has undergone significant
> > improvement recently, and further automation is in active development.
>
>
clever people out there who like to some pretty
> wild hacks, hence the “generally not used”.
>
>
>
> -glenn
>
>
>
> On 1/21/22, 1:33 PM, "Rob Sayre" wrote:
>
>
>
> On Fri, Jan 21, 2022 at 1:15 PM Deen, Glenn 40comcast@dmarc.ietf.org> w
On Fri, Jan 21, 2022 at 1:15 PM Deen, Glenn wrote:
>
>1. Draft Agenda:
>
> https://datatracker.ietf.org/meeting/interim-2022-add-01/materials/agenda-interim-2022-add-01-add-01-04
>
>
Hi Glenn,
The agenda says:
- "DNSSEC is generally not used for the non-global names in Do53 Split DNS
en
On Tue, Feb 18, 2020 at 8:17 AM Olli Vanhoja wrote:
>
> SVCB is active almost every day of the week in GitHub.
>
If someone wanted to follow this work, which GitHub repo is relevant?
I found this one: https://github.com/MikeBishop/dns-alt-svc
But I'm not sure that's the right one.
thanks,
Rob
On Fri, Jan 3, 2020 at 1:01 PM Paul Vixie wrote:
> On Friday, 3 January 2020 20:01:04 UTC Erik Kline wrote:
> > I think removing port number flexibility might unduly constrain some data
> > center use cases where service reachability might not have the more
> common
> > 443-only limitations.
>
>
Hello,
Was the source code behind this study published?
It seems like it shouldn't be too much effort. After all, the study is
already published, so the code can't be changed.
thanks,
Rob
On Thu, Jul 18, 2019 at 10:42 PM Kevin Borgolte wrote:
>
> > This paper looks interesting. Is the softwa
Perhaps the saddest thing about all of this is that I have to cc
www-archive.
that sucks,
Rob
On Tue, Aug 27, 2019 at 10:55 PM Rob Sayre wrote:
> >> On Tue, Aug 27, 2019 at 5:33 PM william manning <
>> chinese.apri...@gmail.com> wrote:
>> > because the DNS
>
> >> On Tue, Aug 27, 2019 at 5:33 PM william manning <
> chinese.apri...@gmail.com> wrote:
> > because the DNS systems have no idea what the application(s) will use
> the answer for.
> > remember that data (A & ) is the zone files is NOT the same as the
> address(es)
> > with which an interfc
On Sun, Aug 25, 2019 at 5:57 PM Martin Thomson wrote:
> > Abstract:
> >This document reserves a string (ALT) to be used as a TLD label in
> >non-DNS contexts. It also provides advice and guidance to developers
> >developing alternative namespaces.
>
> In discussion, the alternative n
On Fri, Aug 23, 2019 at 5:09 PM Erik Kline
wrote:
>
> +1 from me, fwiw.
>
Seems fine to me, as well.
thanks,
Rob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Fri, Aug 23, 2019 at 3:20 PM Joe Abley wrote:
>
> Anybody who was currently harbouring plans to apply for ALT in some future
> round of new gTLD applications would therefore presumably feel harmed by a
> decision to make it impossible for those plans to be executed.
>
That is a very clear exp
On Fri, Aug 23, 2019 at 2:40 PM Joe Abley wrote:
>
> I have never been very excited about your ALT proposal. However, I don't
> think it will do any harm beyond thwarting any secret plans anybody might
> have...
What exactly do you mean?
thanks,
Rob
On Fri, Aug 2, 2019 at 8:04 AM Tim Wicinski wrote:
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-sah-resolver-information/
>
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
>
I
On Thu, Aug 1, 2019 at 9:09 AM Tim Wicinski wrote:
> This starts a Call for Adoption for draft-hoffman-dns-terminology-ter
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology-ter/
>
> Please review this draft to see if you think it is suitable for ado
On Mon, Jul 22, 2019 at 5:38 PM Normen Kowalewski
wrote:
> Daer Stephane, Paul and DNSOP WG,
I think the draft is generally very helpful in navigating the acronyms and
abbreviations associated with this space.
It should be pointed out that "Do53: DNS over UDP or TCP as defined in
[RFC1035]...
On Fri, Jul 19, 2019 at 3:10 AM Kevin Borgolte wrote:
>
> > But, I think you should add the list and the reason for the range choice
> to the paper. For example, I can't tell what range you actually used from
> your description (although that might just be due to a hurried reply).
>
> Section 3.2
On Thu, Jul 18, 2019 at 10:42 PM Kevin Borgolte wrote:
> The list of websites is attached. It is extracted from the top 1,000 and
> 99,000 to 100,000 of a Tranco list.
>
Thanks for attaching the list. Having seen a fair a number of these, I
think it looks reasonable.
But, I think you should add
On Thu, Jul 18, 2019 at 9:27 PM Kevin Borgolte wrote:
> We‘d appreciate any feedback on our work. Please also feel free to reach
> out to us directly (in person or by email) if you have any insight or
> feedback you’d prefer not to post to the list.
>
This paper looks interesting. Is the softwar
On Wed, Jul 17, 2019 at 5:08 PM Paul Hoffman wrote:
> On Jul 17, 2019, at 4:57 PM, Rob Sayre wrote:
> > Is there a good definition of the term "policy ideas"?
>
> No, but you already knew that.
Yes, I did. But you still wrote it.
> Most specifications of policy e
On Wed, Jul 17, 2019 at 4:44 PM Paul Hoffman wrote:
> On Jul 17, 2019, at 4:33 PM, Tommy Jensen 40microsoft@dmarc.ietf.org> wrote:
> >
> > I appreciate the intent behind this draft to allow DNS-capable apps to
> detect if configured DNS resolvers need to be deferred to. However, I agree
> wi
thanks,
Rob
On Tue, Jul 16, 2019 at 10:32 AM Rob Sayre wrote:
>
>
> On Tue, Jul 16, 2019 at 10:20 AM Tommy Jensen
> wrote:
>
>> The link you shared indicates the problem is RC4, which was removed from
>> TLS in 1.3 for this very reason. This doesn’t demonstrate TLS 1.3
x27;s one part of it, but some of the other approaches described are
more general.
thanks,
Rob
>
> Thanks,
> Tommy
> --
> *From:* DNSOP on behalf of Rob Sayre <
> say...@gmail.com>
> *Sent:* Tuesday, July 16, 2019 8:46:42 AM
> *To
On Tue, Jul 16, 2019 at 6:41 AM Eric Rescorla wrote:
>
>
> The certs are public information, so having the certs isn't useful. Can
> you please be clearer about the attack you are describing?
>
Sure, here's an article about it:
<
https://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_bullru
On Mon, Jul 15, 2019 at 8:52 PM Andy Grover wrote:
> To speak more concretely, right now some existing filtering DNS
> providers have ways for users to know if things are working as desired.
> OpenDNS has internetbadguys.com for examplle, and other providers have
> similar. These are useful, but
On Mon, Jul 15, 2019 at 8:14 AM Paul Vixie wrote:
> On Monday, 15 July 2019 02:17:04 UTC Rob Sayre wrote:
> > On Sun, Jul 14, 2019 at 6:59 PM Paul Vixie wrote:
> > > ...
> >
> > I'm surprised that you seem to view DoH as a problem. I mean, everyone
> knows
On Mon, Jul 15, 2019 at 10:18 AM Peter Saint-Andre
wrote:
> On 7/15/19 10:54 AM, Andrew M. Hettinger wrote:
>
> > Arguably there's actually a decrease in security over DoT as, rather
> > then your network provider being the one who knows what DNS lookups
> > you're doing, now some third party wit
On Sun, Jul 14, 2019 at 6:59 PM Paul Vixie wrote:
> the the web community caught wind of it and threw a molatov cocktail into
> our
> movie theater -- DoH.
>
> changing DNS isn't quick or easy or cheap -- it's the trifecta of "fast,
> good,
> or cheap, choose two" and you have to say "i choose no
Thank you for the elegant response. BCP 61 describes this issue well, too.
https://tools.ietf.org/html/bcp61
DNS seems like it still operates in the clear, and that doesn't seem good.
thanks,
Rob
On Sun, Jul 14, 2019 at 6:34 PM Paul Vixie wrote:
> On Sunday, 14 July 2019 23:09:00
Paul Vixie wrote:
> dns content filtering can be triggered by response data also, and not
just by
> the dns request (which itself might not be the initial request.) in
common use
> by dns firewalls, for example those using DNS RPZ, policy might be
triggered
> by the iteration through an authoritati
31 matches
Mail list logo
