Re: [DNSOP] [Ext] Post quantum DNSSEC ?

this crossed my radar in 2016 during a quantum networking retreat at Torry Pines. Talking with some crypto people in 2017, these notes kicked off adding a new algorithm for my test universe. --- https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3040224 https://arxiv.org/pdf/1509.02533

Re: [DNSOP] Last Call: (Moving DNSSEC Lookaside Validation (DLV) to Historic Status) to Informational RFC

I support this. DLV was a mistake and making it historic should close that door. On Wed, Sep 4, 2019 at 4:42 PM The IESG wrote: > > The IESG has received a request from the Domain Name System Operations WG > (dnsop) to consider the following document: - 'Moving DNSSEC Lookaside > Validation

Re: [DNSOP] Why would a v4 client send AAAA query?

ects the transport used to get to the data. (Joe, we should watch more movies together) /Wm On Wed, Aug 28, 2019 at 7:07 AM Joe Abley wrote: > Hi Rob, > > On 28 Aug 2019, at 01:55, Rob Sayre wrote: > > > >> On Tue, Aug 27, 2019 at 5:33 PM william manning < > chinese.apri.

Re: [DNSOP] bar bof, edns buffer size, avoid fragmentation

sounds like a delightful session with some productive ideas. On Wed, Jul 24, 2019 at 5:23 PM Paul Vixie wrote: > one other matter emerged during this discussion. path mtu discovery is > dead at > the moment, for valid security reasons. however, a jumbogram sized campus > can > be described in

Re: [DNSOP] Proposal: Whois over DNS

you mean something like this? https://www.isi.edu/division7/publication_files/novel_use.htm On Mon, Jul 8, 2019 at 2:39 PM John Bambenek wrote: > All- > > In response to ICANN essentially removing most of the fields in WHOIS for > domain records, Richard Porter and myself created a draft of

Re: [DNSOP] [dns-privacy] New: draft-bertola-bcp-doh-clients

al and legal exposure when DOH is shown to be the culprit in exposure of private data. I can't see how DOH is going to pass GDRP muster inside the EU either, but that is for others to debate. I have told my GDRP affected counterparts about the privacy risks with DOH deployment. as usual, YMMV. /W

Re: [DNSOP] Making domains work even when connectivity fails (Was: the root is not special, everybody please stop obsessing over it

Multicast NOTIFY? You mean like RFC 6804, or RFC 7558. Use of a subscription model or lease still depends on reachability and when you don't have that, you have two choices, use a stale lease or abandon it. Take your pick. /Wm On Fri, Feb 15, 2019 at 8:44 AM Paul Vixie wrote: > > > Stephane

Re: [DNSOP] the root is not special, everybody please stop obsessing over it

: > > > william manning wrote on 2019-02-14 17:35: > > so, you would like the DNS to be resilient enough to "see" what was > > topologically reachable and build a connected graph of those assets? > > no. that's not possible, and not desireable in any case. &

Re: [DNSOP] the root is not special, everybody please stop obsessing over it

so, you would like the DNS to be resilient enough to "see" what was topologically reachable and build a connected graph of those assets? I think that has been done, both academically and in a more limited way, commercially, but its not called DNS so as not to upset the DNS mafia. Or do you want

Re: [DNSOP] DNSSEC threshold signatures idea

Great stuff Steve. John Gilmore and I talked about the use of byzantine quorum systems for key management at ISOC in 1998. And Olaf Kolkman, Johan Ihren and I proposed such a system in 2005 as an alternative to what became RFC 5011. I built a DNS system that used these ideas for DNS key

[DNSOP] Fwd: Working Group Last Call on draft-ietf-dnsop-terminology-bis

-- Forwarded message -- From: william manning Date: Thu, Jul 5, 2018 at 9:55 PM Subject: Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis To: George Michaelson true enough, there is a single, canonical dnssec signed zone which can only be generated

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

my mailbox is not filled with crap from spammers, if that is what you mean. it's not empty either. :) if you want to kill off NSAP-PTR, I'd support that. /Wm On Mon, Mar 26, 2018 at 11:44 AM, Dick Franks wrote: > > On 26 March 2018 at 16:42, Paul Vixie

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

concur with Pauls assertions wrt "long tail". Picking on specific RR types to remove is a high maintenance method to put the camel on a diet. Laudable but maybe not worth the efforts needed to clean up the installed base. Perhaps these two ideas might be a better way to simplify things. 1)

Re: [DNSOP] A conversational description of sentinel.

your wrote,: "​In the real world, the user will not be expected to figure this out [...] -- a bit of JS on www.example.com will do the 3 fetches and report "You'll be just fine", "You will have issues, call your ISP and get them to install the new key" or "Sorry, cannot tell.​ Call your ISP and

Re: [DNSOP] Agenda for IETF100

Please keep us posted on the logistics On Sunday, November 12, 2017, Melinda Shore wrote: > On 11/10/17 8:16 PM, Stephane Bortzmeyer wrote: > > Any news on that? The monday session collides with DIN which is really > > unfortunate for me because they talk a lot about

Re: [DNSOP] Resolver behaviour with multiple trust anchors

in reverse order of trustworthiness: the root a third party - e.g. DLV locally verified - e.g. my employer, ISP, someone I have a binding legal relationship with /Wm On Thu, Nov 2, 2017 at 8:04 AM, Bob Harold wrote: > > On Thu, Nov 2, 2017 at 10:41 AM, Matt Larson

Re: [DNSOP] Resolver behaviour with multiple trust anchors

in the last 20 years, there have been a few testbeds that have explored this space. irl.cs.ucla.edu/papers/imc71-osterweil.pdf https://eprint.iacr.org/2013/254.pdf that suggest Matt is spot on here. accepting any success is likely to present the fewest problems from a user perspective. /Wm

Re: [DNSOP] 答复: 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt

You wrote; "we can, if we wish, continue to standardize one protocol, watch as the world deploys a different one, and still pretent that our effort was worthwhile. however, this would fit the technical definition of "insanity", and i urge that we avoid this course of action." The IETF has been

Re: [DNSOP] 答复: Fwd: I-D Action: draft-song-atr-large-resp-00.txt

es. > > > > Davey > > > > *发件人:* DNSOP [mailto:dnsop-boun...@ietf.org] *代表 *william manning > *发送时间:* 2017年9月21日 1:30 > *收件人:* Davey Song > *抄送:* dnsop > *主题:* Re: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt > > > > i think this is a wor

Re: [DNSOP] Fwd: I-D Action: draft-song-atr-large-resp-00.txt

i think this is a worthy document for consideration. /Wm On Sun, Sep 10, 2017 at 9:29 PM, Davey Song wrote: > Hi folks, > > I just submit a draft dealing with issue of large DNS response especially > in IPv6. Commnets are welcome. > > If chairs think it is in the scope

[DNSOP] Fwd: DNSSEC in local networks

'cause warren isn't special enough to warrant getting the only copy of this. /Wm -- Forwarded message -- From: william manning <chinese.apri...@gmail.com> Date: Tue, Sep 12, 2017 at 6:53 PM Subject: Re: [DNSOP] DNSSEC in local networks To: Warren Kumari <war...@kumari.n

[DNSOP] Fwd: Status of "let localhost be localhost"?

-- Forwarded message -- From: william manning <chinese.apri...@gmail.com> Date: Sat, Aug 5, 2017 at 5:33 PM Subject: Re: [DNSOP] Status of "let localhost be localhost"? To: John Levine <jo...@taugh.com> i think the question hinges on zone completion log

Re: [DNSOP] Status of "let localhost be localhost"?

localhost is just a string, like www or mail or supralingua. A DNS operator may chose to map any given string to any given IP address. restricting ::1 so that it never leaves the host is pretty straight forward. if I map localhost to 3ffe::53:dead:beef and NOT ::1 in my systems, why should

Re: [DNSOP] new DNS classes

You need a better imagination then. mDNS is a crippled DNS implementation that was hobbled on purpose. HS was/is an entirely different addressing scheme that emerged from project Athena @ MIT. To the extent that when all you have been given is the IN class and it's associated rooted

Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

I find Randys line of discussion mirroring my own thoughts. And to answer your question above, technically, the TLD org. is a member of the IN class, so in the OF class, it is credible to posit the existence of a org. TLD. TLDs are per class... :) /Wm On Tue, Jul 4, 2017 at 7:01 AM, Ted

Re: [DNSOP] Call for Adoption draft-hunt-dnsop-aname

I will review. I support adoption. On Friday, May 19, 2017, Matt Larson wrote: > > On May 11, 2017, at 6:55 AM, tjw ietf > wrote: > > I'm caught up with my day job, and the discussion on this has

Re: [DNSOP] DNSOP Call for Adoption: draft-hardaker-rfc5011-security-considerations

this is a useful and needed document. I support its adoption by the WG. As a note to the authors, there was a proposed alternate to what became RFC 5011 which addressed some of the same issues as the current draft. It might be useful to review

Re: [DNSOP] New terminology for root name service

do you have a pointer to the rssac document? /Wm On Wed, Mar 15, 2017 at 10:31 AM, Paul Hoffman wrote: > Greetings again. RSSAC has published a lexicon of terms that are commonly > used with respect to the root of the public DNS, but are not in RFC 7719. I > have opened

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Joel, I'd be happy to see the document proceed under two conditions: 1) it becomes a WG document, subject to IETF change control, and 2) that the disclaimer requested back on 20170103 be added to the document. To refresh the collective mind, here is the missing text: applicability statement.

Re: [DNSOP] DNS-Server distribution statistics

which is why, Warren, that modern fingerprinting does not rely on what the server lies about. /W On Sun, Feb 12, 2017 at 2:56 PM, Warren Kumari wrote: > On Sun, Feb 12, 2017 at 5:44 PM, George Michaelson > wrote: > > I have never entirely got with the

Re: [DNSOP] ALT-TLD and (insecure) delgations.

DNAME was considered early in the IDN evaluations, so it's not exactly unknown in the Icann community On Fri, Feb 3, 2017 at 15:33 Steve Crocker wrote: > We (ICANN) have no mechanism or process for inserting a DNAME record into > the root. We do have a process for

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

wrote: > On 12/29/16 1:51 PM, william manning wrote: > > "lets standardize this 'cause everyone does it" sounds like the medical > > community should have standardized on whiskey & leaches & coat hangers > > because thats what everyone did. if this work does

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

"lets standardize this 'cause everyone does it" sounds like the medical community should have standardized on whiskey & leaches & coat hangers because thats what everyone did. if this work does proceed, i'd like to insist that it carry a disclaimer that it is designed specifically for closed

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

the complaints about operator participation in the IETF go back decades. no news there. in fact, there are operator driven fora for just such activities, DNS-OARC comes to mind. this draft actively destroys trust in the DNS, which reduces trust in the Internet overall. is that really what you

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

ns. I'd be happier if there was an exit strategy for RPZ, so we would know when to turn it off. /Wm On Mon, Dec 19, 2016 at 8:58 PM, william manning <chinese.apri...@gmail.com> wrote: > adding complexity in the middle of any system increases the size of an > attack surface. true for SMTP,

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

adding complexity in the middle of any system increases the size of an attack surface. true for SMTP, Firewalls, and DNS. This draft formalizes adding massive complexity throughout the DNS without a clear or crisp way to debug and correct problems, particularly since resolution issues will

Re: [DNSOP] warning

SMTP configuration is not relevant... That said, the morphing of open SMTP services to the tightly controlled heirarchy and draconian locally administered rules which prevent delivery are EXACTLY what this draft proposes for the DNS. On Sunday, 18 December 2016, Tim Wicinski

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

operators a heads up that they were, once again, being asked to backstop issues that should be handled elsewhere. /Wm On Sat, Dec 17, 2016 at 11:42 AM, David Conrad <d...@virtualized.org> wrote: > Bill, > > On Dec 17, 2016, at 11:36 AM, william manning <chinese.apri...@

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Is there any public data to support the presumptions of excess capacity at the roots and the impact of NSEC aggressive use on the DNS? I know that in the previous century, punting on operational impact by guessing about outcomes was common. I thought the IETF had moved away from SWAG and was

Re: [DNSOP] [homenet] iterative vs. forwarder, was Fwd: WGLC on "redact" and "homenet-dot"

actually, IoT OS platforms are mostly not stripped versions of linux, most are purpose-built, real time OS's. One of the more popular is RIOT. If you look at the attacks on these OS's, you can look at Miri, the BOT which shows lots of packet love. Concur that you should touch base with RSSAC

Re: [DNSOP] DNSSEC operational issues long term

Johan Ihren and I and Olaf had a competing ID that delt with shelf life and embedded devices w/o an easy way to update key info. RFC 5011 won out since shelf life and embedded devices were considered edge cases. /Wm On Wednesday, 16 November 2016, Tony Finch wrote: > Wessels,

Re: [DNSOP] Fwd: New Version Notification for draft-bellis-dnsext-multi-qtypes-03.txt

flogging a dead horse. Did you see this? https://www.rfc-editor.org/rfc/rfc6804.txt On Wed, Oct 26, 2016 at 2:23 AM, Ray Bellis wrote: > This is a very minor update, mostly just to keep the document alive. > > Ray > > Forwarded Message > Subject: New Version

Re: [DNSOP] review of draft-ietf-dnsop-no-response-issue-05

Unfortunately we are no longer in the early days of the Internet AND the IETF has no business in enforcing compliance with our protocol standards. That's for the zone operators to do. We are not the dns police. Even Paul mocapetris has called for more innovation in the dns space. We must not

[DNSOP] Late to the "special use labels" party

actually, these ideas touch on a few threads that seem to (still) be flying around. I expect to turn this into an ID, headed for Informational - possibly to the ISE. comments and constructive input appreciated. /Wm What is the Domain Name System (DNS)? The DNS was created to provide a

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

On Thu, Sep 29, 2016 at 3:28 PM, John R Levine wrote: > I suppose I could use jrl.alt, but I wouldn't want to use plain .alt for >>> fear of, if you'll pardon the phrase, name collisions. >>> >> > Name collisions may occur at any delegation point - why do you think the >> root

Re: [DNSOP] Tell me about the ISO 3166 user assigned two-letter codes and TLDs

On Thursday, 29 September 2016, John R Levine wrote: > I've been telling people that if they need a fake private TLD for their local network they should use one of those since it is exceedingly unlikely ever to collide with a real DNS name. Am I right? >>> > C:

Re: [DNSOP] Off topic: DNS and Internet Naming Research Directions (DINR-2016) workshop

take a gander at this... On Wed, Sep 28, 2016 at 11:30 AM, Wes Hardaker wrote: > > This is slightly off topic from dnsop, though is definitely heavily > related so please excuse my side topic posting: > > > USC/ISI will be holding a workshop, of which the announcement

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

I think Jim is on to some thing here. I suspect part of the problem is that there is no crisp understanding of what the DNS actually is. Without that it is much harder to say what it is not. /Wm On Tue, Sep 27, 2016 at 11:38 AM, Jim Reid wrote: > > > On 27 Sep 2016, at

Re: [DNSOP] Mitigation of name collisions

this bit of thread jumped out. > In the case of mitigation through wildcard-to-localhost, it is safe to >> assume that many organizations did in fact mitigate; we simply can't tell >> how many or when. >> > > How come? > back in the early days of potentially confusing assignments/delegations, I

[DNSOP] Fwd: moving forward on special use names

maybe others would be interested. /Wm -- Forwarded message -- From: william manning <chinese.apri...@gmail.com> Date: Mon, Sep 19, 2016 at 10:49 AM Subject: Re: [DNSOP] moving forward on special use names To: John Levine <jo...@taugh.com> I'm liking Jo

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

Good thing refuse-any is just a draft then isn't it. Now any v. Concurrent queries. To ensure the resolver gets all the RRs, wouldn't you have to query for all defined RR types? Perhaps you want ALL instead of ANY? /Wm On Thursday, 25 August 2016, Tony Finch wrote: > Edward

Re: [DNSOP] draft-ietf-dnsop-no-response-issue-03

I'm with Ed here, A valid response is silence. The resolver/client has no way to determine if the lack of a reply is due to the server has chosen silence, or if there was something in-path which dropped the packet. In this case, client misbehaviour is panicking and sending many queries to try

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

please help me get over the feeling that this argument is founded on the same logic as that used by folks who "know" I might want, no NEED that extra bit of email in my inbox. As I read it, it sounds like DNS Server Spam being "PUSHED" to the Resolver who may or may not want the data. Please

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

from an attacker POV, I would strongly support PUSH, as it would increase DDoS effectiveness. The performance enhancement seems to be based on some presumptions about servers retaining residual knowledge of the resolver behaviours. PULL minimizes the attack surface. wrt cache coherence and delay,

Re: [DNSOP] Term for "signing software"? Re: I-D Action: draft-ietf-dnsop-terminology-bis-02.txt

i look at much of the current work product and it reminds me of the term "guilding the lily"... my view of the DNS landscape is a series of concentric circles, the center is DNS protocol fundamentals, the namespace and wire formats. outside that are things like namespace representation, which

Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-resolver-priming

re the 2 second timeout. perhaps timeout does not express the intent well. I think of most of the DNS timeout options to be effectively hold-down timers - to be used to prevent excessive "chatty" behaviours. /W On Fri, Aug 5, 2016 at 2:45 AM, Shane Kerr wrote: >

Re: [DNSOP] Definitions of basic DNSSEC terms

must be mass hallucination. My memory concurs with Ed on the history. If you MUST define authentication, validation, and verification, I would place them under, "local policy" /W On Tue, Aug 9, 2016 at 3:55 AM, Edward Lewis wrote: > On 8/4/16, 10:16, "DNSOP on behalf

Re: [DNSOP] Call for Adoption: draft-bellis-dnsop-session-signal

I'll be happy to work on/review/ suggest text for this draft. /W On Fri, Jul 22, 2016 at 6:39 PM, Tim Wicinski wrote: > I know we've just started talking about this, and the authors are still > sorting out a few things, but the sense of the room we received was to > adopt