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
ieeexplor
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 (DL
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...@g
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
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 s
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 an
cal 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,
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 B
:
>
>
> 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 ca
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 s
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
managemen
-- 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 with
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 wrote:
>
>>
>>
>> Ondřej Surý wrote:
>>
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) remove
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 as
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 name resolution
> > (Namecoi
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
> wrote:
>
>> The root KSK r
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
On
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 doi
DNS response issues.
>
>
>
> 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
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 of dnsop wg and encourage
'cause warren isn't special enough to warrant getting the only copy of this.
/Wm
-- Forwarded message ------
From: william manning
Date: Tue, Sep 12, 2017 at 6:53 PM
Subject: Re: [DNSOP] DNSSEC in local networks
To: Warren Kumari
cry me a river. in the face of conflicti
-- Forwarded message --
From: william manning
Date: Sat, Aug 5, 2017 at 5:33 PM
Subject: Re: [DNSOP] Status of "let localhost be localhost"?
To: John Levine
i think the question hinges on zone completion logic and fully qualified
domain names.
when 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 you
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 hierarchy,
Most of the other application (besides dns) presume a single class, IN,
hence the URL presumption of "DNS name" will -always- be in the IN class.
Technically imprecise and sloppy, but pragmatically it works... until some
loons come along and do something creative with classes. Then all bets
are
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 Lemo
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 died down,
> but it looks like the work is moving along smoothly, it's time to kick off
> a Call fo
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
https://tools.ietf.org/html/draft-ietf-dnsext-trustupd
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 an issue for the termino
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.
Th
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 people who think obscuring version
> > inf
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 considering the general issue
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 proceed, i'd like to
"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 netw
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 want
lled gardens.
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
wrote:
> adding complexity in the middle of any system increases the size of an
> attack surface. true for SMTP, Firewalls,
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
emerg
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 wrote:
> Jim is corr
root 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 wrote:
> Bill,
>
> On Dec 17, 2016, at 11:36 AM, william manning
> wrote:
> > Is there any public data to s
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
wo
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 bef
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, Duane > wrote:
>
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 Notification for
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
pr
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
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 zone is special in
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: why not just use .a
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 follows.
> This, sadly, c
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 18:52, Warren Kumari
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
maybe others would be interested.
/Wm
-- Forwarded message --
From: william manning
Date: Mon, Sep 19, 2016 at 10:49 AM
Subject: Re: [DNSOP] moving forward on special use names
To: John Levine
I'm liking Johns approach - There is not a technical solution to a poli
You should probably wait until it's formally added to the root hints file.
On Monday, 29 August 2016, Ray Bellis wrote:
>
>
> > On 29 Aug 2016, at 03:53, Shane Kerr > wrote:
> >
> > Thanks, but I'm curious... raised a ticket... where? Via the "Contact
> > Us" page here?
> >
> > https://e.root-
Actually, any of the root ops have that data. I suspect this is a
"pre-opening", to gauge reachability of the prefix before public commit.
That was the operational practice for the 20+ years I was active in root
ops.
/Wm
On Sunday, 28 August 2016, Shane Kerr wrote:
> Ray,
>
> At 2016-08-26 18:
On Thursday, 25 August 2016, Tony Finch wrote:
> william manning > wrote:
>
> > I'm with Ed here, A valid response is silence.
>
> I think it is important for people producing and deploying DNS server
> software and DNS-interfering middleboxes to understand the b
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 Lewis > wrote:
>
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
an
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 advi
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,
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 has
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:
> All,
>
> At 2016-08-04 20:03:3
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 of Paul Hoffman" <
> dnso
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 it, work on it, etc.
>
63 matches
Mail list logo
