Re: [DNSOP] [Last-Call] [Ext] Opsdir last call review of draft-ietf-dnsop-dnssec-bcp-03
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. > > I would rather not speculate on the reasons for the low rate of adoption, > particularly because the reasons might change with the adoption rate > remaining low. > I agree that avoiding speculation is best, but the document uses the passive voice in a few places where it shouldn't. > "The DNSSEC set of protocols is widely considered..." and > "Some observers note..." I would classify myself as one of those observers, but these sentences should be rephrased to be more direct. I have no objections to the technical content of the document. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Last-Call] Last Call: (The ALT Special Use Top Level Domain) to Proposed Standard
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 things in direction-switching URLs, rather than the coherent Usenet naming system. I think it's fine, and I don't care. thanks, Rob On Mon, Mar 13, 2023 at 3:59 PM Martin Thomson wrote: > On Tue, Mar 14, 2023, at 09:44, Mark Nottingham wrote: > > I do wonder whether 'alt' is appropriate -- 'alternative' begs the > > question of 'alternative to what?' and the answer is a technical detail > > that most Internet users are blissfully unaware of. It seems to me that > > it'd be better to choose something meaningful to users. > > I still don't know why ".arc" never got off the ground. An expansion of > "alternative resolution context" addresses the DNS-centric perspective; the > word implies OIDs, which interesting properties; and, who can resist the > homonym, especially when there is Ark B [1]. > > [1] https://hitchhikers.fandom.com/wiki/Golgafrinchan_Ark_Fleet_Ship_B > > -- > last-call mailing list > last-c...@ietf.org > https://www.ietf.org/mailman/listinfo/last-call > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-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 authoritative name server address, or an > authoritative name server name, or by the response (answer) address, or even > by the stub client's IP address. Was DNS intentionally designed to be insecure? thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00
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 UTC Rob Sayre wrote: > > Paul Vixie wrote: > > > ... > > > > Was DNS intentionally designed to be insecure? > > no. nor ip itself, or ncp which preceded it, or tcp, or udp, or icmp, or > smtp, > ot http. it was insecure because it evolved in a safe, germ free academic > bubble. absolutely none of it was designed with billions of people in > mind, or > the full cross section of humanity which would include criminals and > national > intelligence services. the world of the internet in 2019 would have been > seen > as a total freak show by the community who deployed dns in the 1980's. > > nothing that can be abused won't be. you may or may not believe this; it's > considered controversial, and there are arguments being had about it today. > > but noone considered that now-controversial near-truism at all when the > core > internet protocols were first designed and implemented. the idea of abuse > was > considered novel in the 1990's when commercialization and privatization > brought abuse into the internet world and burst the academic bubble. a lot > of > old timers blamed AOL and MSN and even Usenet for the problems, but in > actuality, it's what humans _always_ do at scale. putting the full > spectrum of > human culture atop a technology platform designed for academic and > professional culture should have been understood to be a recipe for > disaster. > > -- > Paul > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00
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 none of the above." > I'm surprised that you seem to view DoH as a problem. I mean, everyone knows that TLS and IPSEC are compromised by determined attackers, but I didn't know it was a continued sore spot. If you have more to say, I would like to hear it. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [External] Re: Fwd: [Add] new draft: draft-grover-add-policy-detection-00
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 with whom you have no relationship. > > You, as a lone user, have zero leverage with your network provider. > It doesn't look like Mozilla has much leverage here. I can just pay $10 or something for a VPN. > Firefox or Chome or Safari (etc.), as the user agent for millions of > people, can exercise more leverage and also enter into contractual > agreements with trusted recursive resolvers. That seems like a promising > avenue to explore. > Is it promising? > > > Let's be clear, "some third party" is pronounced "Cloudflare." This > > isn't to bash on Cloudflare, but everyone's DNS traffic going to ONE > > company? > > Mozilla's intent is to deploy a set of trusted recursive resolvers, as > Ekr explained back in March on the DoH list: > And also to supply a domain name that disables everything? That's what the draft does, right? thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00
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 > > that TLS and IPSEC are compromised by determined attackers, ... > > if you know a way that modern TLS 1.3 can be compromised by MiTM I think some parties just ask for the certs, if they can't acquire them due to negligence. > , i'd like to > know more. a lot of us are moving from MiTM to explicit outbound proxy > with an > internally trusted key in order to fulfill our corporate or regulatory > obligations. > > > but I didn't know > > it was a continued sore spot. If you have more to say, I would like to > hear > > it. > > the introduction of the DoH RFC explains that this protocol is designed to > prevent interference by on-path actors in dns operations. i am a > committed, > determined on-path interferer, both for parental controls at home and > corporate controls at $dayjob. > This response is disappointing to me, but I have to congratulate its directness. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [External] Re: Fwd: [Add] new draft: draft-grover-add-policy-detection-00
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 would be more broadly useful if they > weren't provider-specific. That's basically all this draft is proposing > -- defining one canary domain to check instead of one for each provider. > Isn't the issue that encrypted DNS might be served by popular providers? So, if DNS and lots of the web are served by Azure or AWS or GCP, a functioning DoH protocol would make it hard to implement naive filtering. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00
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_bullrun_analysis/ > Do you have any thoughts on that? thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00
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 is > vulnerable; it demonstrates why adopting TLS 1.3 is so important. > Yeah, that'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:* Eric Rescorla > *Cc:* dnsop WG ; Paul Vixie > *Subject:* Re: [DNSOP] Fwd: [Add] new draft: > draft-grover-add-policy-detection-00 > > 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_bullrun_analysis/ > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.theregister.co.uk%2F2013%2F09%2F06%2Fnsa_cryptobreaking_bullrun_analysis%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C496a0b49339349ac921308d70a04e0de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63698386522988&sdata=SbICd7%2FtkDlhh1zyusjw75CRgg6KHhbpzH0Efn%2BoBew%3D&reserved=0> > > > > Do you have any thoughts on that? > > thanks, > Rob > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00
Hi Tommy, I also noticed that your email client rewrote the link to "The Register", a site that everyone knows, which then linked to NY Times, etc. It used the domain "nam06.safelinks.protection.outlook.com". Why would that domain be necessary if DNS-based security worked? 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 is >> vulnerable; it demonstrates why adopting TLS 1.3 is so important. >> > > Yeah, that'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:* Eric Rescorla >> *Cc:* dnsop WG ; Paul Vixie >> *Subject:* Re: [DNSOP] Fwd: [Add] new draft: >> draft-grover-add-policy-detection-00 >> >> 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_bullrun_analysis/ >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..theregister.co.uk%2F2013%2F09%2F06%2Fnsa_cryptobreaking_bullrun_analysis%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C496a0b49339349ac921308d70a04e0de%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63698386522988&sdata=SbICd7%2FtkDlhh1zyusjw75CRgg6KHhbpzH0Efn%2BoBew%3D&reserved=0> >> > >> >> Do you have any thoughts on that? >> >> thanks, >> Rob >> > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Add] [Ext] new draft: draft-grover-add-policy-detection-00
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 > with Ralf that NXDOMAIN is the wrong way to signal that. > > > > What about defining a new TXT record format to signal the presence of > policies? This has the benefits of 1) not overloading the interpretation of > whether the domain exists or not as well as 2) giving room for future > flexibility beyond the binary "resolver (does|does not) have DNS policies > in place you shouldn't bypass" signal. > > Please see < > https://datatracker.ietf.org/doc/draft-sah-resolver-information/> for a > proposal that is being discussed in the DNSOP WG. It proposes a message > format (JSON) and two transports (DNS and HTTPS) that can be used by a > resolver for lots of things, including the policy ideas in the draft that > this thread is about. Is there a good definition of the term "policy ideas"? thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Add] [Ext] new draft: draft-grover-add-policy-detection-00
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 ever created in the IETF have been > dissatisfying to some people for various (good) reasons. That's one of the > reasons why the spec in draft-sah-resolver-information allow anyone to > create their own temporary specs before standardization. > So, the spec allows anyone to create whatever they want? Why would that be called a standard? Isn't that just writing code? I might be missing something, but this doesn't seem to make sense. thanks, Rob > > --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Do53 vs DoT vs DoH Page Load Performance Study at ANRW
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 software used in the paper published? Or, at least, is the test page set published? I haven't read the whole thing yet, but it seems like the page set would be relevant if the paper tests page load time. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Do53 vs DoT vs DoH Page Load Performance Study at ANRW
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 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). Another issue is that, while your paper might accurately capture the network conditions on your local network, it's probably doesn't capture network variation as well as a large scale test along the lines of what Mozilla did. For example, if the university used a single router brand, this could skew the test. As one data point, I've never seen the various network-throttling apps match a real-user-metrics test very well, although they do catch really problematic situations. This test is a welcome contribution, but given the data in the paper, it would be difficult to reproduce. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Do53 vs DoT vs DoH Page Load Performance Study at ANRW
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.4 talks about the selection of websites: > > We collect HARs (and resulting DNS lookups) for the top 1,000 websites on > the Tranco top-list to understand browser performance for the average user > visiting popular sites. Furthermore, we measure the bottom 1,000 of the top > 100,000 websites (ranked 99,000 to 100,000) to understand browser > performance for websites that are less popular. > I see, that makes sense. I'm still having trouble interpreting the measurements, given that pageload can be blocked by additional DNS queries and HTTP requests. For example, could an analytics provider interfere with performance evaluation here, if it were present in a lot of pages? Or, what if the results indicate a performance problem in one common hosting vendor (anything from AWS to Wordpress)? As I said, the paper is a welcome contribution, but I find the results surprising and want to look more. I would have expected DoH and DoT to be about the same in practice, but your paper does not show this. > We didn't include the full list in the paper itself for space reasons and > because extracting the list from the paper would be cumbersome. It will be > part of our future open source release though. > Understood--I meant that I looked for a separate download and didn't see one (thank you for sending it along). thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hoffman-dns-terminology-ter-01.txt - some comments
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]..." is transmitted in the clear, even though I'm sure most readers of this list know that. > > draft-hoffman-dns-terminology-ter-01.txt says: > Applications Doing DNS (ADD): Applications that act as stub > resolvers. This is in contrast to the way that applications > traditionally have gotten DNS information, which is to use system > calls to the operating system on the computer, > This part seemed a bit off to me, although I admit I don't have good alternate text. Don't a lot of clients and servers already have userland versions of this functionality, even prior to DoH etc? Sometimes they call getaddrinfo or equivalent, but lots of them have their own cache policies etc. It is true that they usually use the OS-supplied DNS servers by default, though. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter
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 adoption > by DNSOP, and comments to the list, clearly stating your view. > I think it is ok to adopt, but it would be better if the "Classic DNS" section used the word "unencrypted": "Classic DNS: Unencrypted DNS over UDP or TCP as defined in [RFC1035]" thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-sah-resolver-information
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 don't understand what this draft aims to standardize, and I don't think it is suitable for adoption. It might describe an interesting experiment in software, but I don't see why the IETF should be involved. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Please review and provide feedback -- draft-stw-6761ext
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 explanation. Thank you. I think a more salient issue might be that URI schemes can imply default ports and name resolution mechanisms. As applications (imho, rightly) begin to hide URI schemes, inventing new name resolution mechanisms will become easier to do. I think having a global namespace is extremely valuable, but I can see ways in which short-sighted DNS arguments could result in fragmentation at the scheme level. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
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
Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-12.txt
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 name .arc was proposed as short for > "alternative resolution context". That sounds like an amazing discussion! > Unless the intent was a direct invocation of the best parts of Usenet, in > which case carry on. Yeah! thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Why would a v4 client send AAAA query?
> > >> 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 interfce may be configured. > > > > "Think before you ask these questions, Mitch." - Chris Knight > > >> On Tue, Aug 27, 2019 at 5:34 PM Joe Abley wrote: > > > > Bill's answer was pithier, though. Oh. I don't get it. I believe the quote in Bill's message is from the 1985 movie "Real Genius", but I was only a small child when that film premiered. Could one of you explain the joke, in the interests of understanding? thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Why would a v4 client send AAAA query?
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 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 interfce may be configured. >> > >> > "Think before you ask these questions, Mitch." - Chris Knight >> >> >> On Tue, Aug 27, 2019 at 5:34 PM Joe Abley wrote: >> > >> > Bill's answer was pithier, though. > > > Oh. I don't get it. I believe the quote in Bill's message is from the 1985 > movie "Real Genius", but I was only a small child when that film premiered. > > Could one of you explain the joke, in the interests of understanding? > > thanks, > Rob > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Do53 vs DoT vs DoH Page Load Performance Study at ANRW
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 software used in the paper > published? > > Thanks! The code isn’t open source yet, but we will make it public > alongside the Docker setup we used for running it. Not sure when that is > going to happen exactly though. > > > Or, at least, is the test page set published? I haven't read the whole > thing yet, but it seems like the page set would be relevant if the paper > tests page load time. > > The list of websites is attached. It is extracted from the top 1,000 and > 99,000 to 100,000 of a Tranco list. > > Best, > Kevin > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] port number in HTTPSSVC
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. > > "think" and "might" are unpersuasive, and "unduly" is subjective. however, > i'll explain further on the other mailing list that the HTTPSSVC co-chair > directed me to. > It means it would prevent using other ports inside the datacenter. The WG should not make this change. Additionally, I am not sure what a "managed private network" is, since the term seems to imply a lack of privacy. thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Reminder Jan 26, 2022 joint interim ADD, DNSOP, DPRIVE
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 environments, so why would it be different for Encrypted DNS?" DNSSEC isn't generally used at all in such an environment, right? thanks, Rob ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dns-privacy] Reminder Jan 26, 2022 joint interim ADD, DNSOP, DPRIVE
Sure, I meant that DNSSEC is also generally not used for the global names in such an environment. thanks, Rob On Fri, Jan 21, 2022 at 13:42 Deen, Glenn wrote: > Hi Rob, > > > > I’ve learned never to say never in the world of Internet technologies as > there are just too many 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> wrote: > > 1. Draft Agenda: > https://datatracker.ietf.org/meeting/interim-2022-add-01/materials/agenda-interim-2022-add-01-add-01-04 > <https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/interim-2022-add-01/materials/agenda-interim-2022-add-01-add-01-04__;!!CQl3mcHX2A!Va5Z4xJKiwOStoxU6hxWJyICluCPtHr1vWrv9JGtuSQD7nAh9oR49DQLH6IxGMcXJg$> > > > > Hi Glenn, > > > > The agenda says: > > - "DNSSEC is generally not used for the non-global names in Do53 Split > DNS environments, so why would it be different for Encrypted DNS?" > > > > DNSSEC isn't generally used at all in such an environment, right? > > > > thanks, > > Rob > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Re: [TLS] Re: Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech
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 thinks people will use it. thanks, Rob On Fri, Oct 4, 2024 at 5:08 AM Eric Rescorla wrote: > I don't really think it's helpful to re-litigate the broader topic of the > merits of ECH; nothing we say in security considerations will make a > material difference there. > > With that said, I don't love the last sentence as we know users don't > really choose their resolvers. How about simply stating the facts: > > "This specification does not effectively conceal the target domain name > from an untrusted resolver." > > > -Ekr > > > On Thu, Oct 3, 2024 at 9:41 AM Salz, Rich 40akamai@dmarc.ietf.org> wrote: > >> I do not think this conflict of views can be resolved. The draft is >> intended to show how it ECH should be used to preserve it’s security >> guarantees, and there are groups in the DNS community who say this prevents >> their normal course of operation, and providing the features that they >> provide. I apologize in advance if anyone finds my wording clumsy or, >> worse, offensive. I was trying to use neutral words throughout. >> >> >> >> I think we just acknowledge that in the security considerations and >> declare the issue closed. >> ___ >> DNSOP mailing list -- dnsop@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org >> > ___ > TLS mailing list -- t...@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: I-D Action: draft-zzn-dns-new-rr-00 - Prefixed TXT Records as Transition Mechanism for New RR Types
Hi, Speaking to the chair: > (speaking as a chair) > > Thanks for keeping this discussion civil and reasonable. I didn't find this message civil. I thought the tone was incredibly dismissive. thanks, Rob ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
