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.
>
On 9October2015Friday, at 4:41, Joe Abley wrote:
>
>
> On 8 Oct 2015, at 22:25, manning wrote:
>
>> perhaps… I think (well it used to work this way) that regardless of HOW it
>> comes under IETF purview, once it does,
>> it is no longer under the ch
perhaps… I think (well it used to work this way) that regardless of HOW it
comes under IETF purview, once it does,
it is no longer under the change control of the submitting organization.
manning
bmann...@karoshi.com
PO Box 6151
Playa del Rey, CA 90296
310.322.8102
On
operational document, its an IETF process document - at which time
ICANN may find that its flexibility is reduced, if it is going to be compliant
with operational documents it initially wrote. It has happened before.
manning
bmann...@karoshi.com
PO Box 6151
Playa del Rey, CA 90296
trust anchors
as used by the IANA, once upon a time. And be done with this for now.
manning
bmann...@karoshi.com
PO Box 6151
Playa del Rey, CA 90296
310.322.8102
On 5October2015Monday, at 14:16, Paul Hoffman wrote:
> On 5 Oct 2015, at 17:00, Joe Abley wrote:
>
>> On 5 Oct 20
think trying to bound the problem
space into a single trust domain is prudent, if only because stepping outside
that space is quite large and may not be wise for an IETF document.
That said, if the RZM folks don’t document how they handle transitive trust, I
would be much more worried.
manning
On 18September2015Friday, at 11:55, Paul Hoffman wrote:
> On 15 Sep 2015, at 9:46, Stephen Farrell wrote:
>
>> Is a domain a sub-domain of itself?
>
> No. The quoted definition from RFC 1034 starts off "A domain is a subdomain
> of another domain..." There is no language in RFCs 1034 or 103
Mark's testing.
>
> The ability to shut down old versions of BIND9 remotely and force an
> upgrade is a pretty nice feature, in a way :-)
>
> Aue Te Ariki! He toki ki roto taku mahuna!
>
>> On Aug 8, 2015, at 19:24, manning wrote:
>>
>> You may be correct
admins or
the ISP upstreams
have made an explicit choice to enable EDNS(unknown) processing at the server.
manning
bmann...@karoshi.com
PO Box 6151
Playa del Rey, CA 90296
310.322.8102
On 8August2015Saturday, at 15:18, Joe Abley wrote:
> Hi Bill,
>
> Not sure what you mean. Wasn&#x
Of course this means that EDNS, for all its promise as an extension to allow
for more flags/signaling is effectively dead, since anything other than EDNS(0)
will now be blocked. Not sure I agree that EDNS compliance is identical to
EDNS(0) compliance.
manning
bmann...@karoshi.com
PO Box 6151
Slowly but surely, the DNS evolves into a signaling system…. :)
manning
bmann...@karoshi.com
PO Box 6151
Playa del Rey, CA 90293
310.322.8102
On 29July2015Wednesday, at 17:09, Wessels, Duane wrote:
> Seeing Warren's recent draft on updates of DNSSEC trust anchors encouraged
> m
Health!"
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 20July2015Monday, at 8:31, Michael StJohns wrote:
> I'm actually somewhat opposed to adopting Joe's trustanchor draft- I don't
> think the cost/benefit analysis works.
>
cause of DNS originated DDoS in the Internet. I guess the path will be to
obsolete sections of RFC 2181 piecemeal.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 10July2015Friday, at 17:47, Suzanne Woolf wrote:
> Bill,
>
>
> In the interest
On 10July2015Friday, at 13:12, Olafur Gudmundsson wrote:
>
>> On Jul 10, 2015, at 1:31 PM, manning wrote:
>>
>> I am aware of at least three of the independent ideas in RFC 2181 that
>> folks are working on:
>>
>> draft-pfrc-2181--naming-issues-00
&
into their own RFCs
Second, move RFC 2181 to historic
Third, start -bising the specify RFCs that folks are working on anyway.
Clean, Tidy, No trailing steams of toilet paper stuck to our shoes.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 10July2015Friday
et Assigned Numbers Authority
ICANN
———
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 8July2015Wednesday, at 17:36, David Conrad wrote:
> No.
>
> At the time, the Administrative Contact as listed in the IANA Whois database
> was USC-ISI.
-00
DNS Resource Record TTL
draft-pfrc-rfc2181-historic-issues-00
RFC2181 to Historic draft-pfrc-rfc2181-historic-issues-00 Abstract
I would like the WG to adopt these drafts.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
-00
DNS Resource Record TTL
draft-pfrc-rfc2181-historic-issues-00
RFC2181 to Historic draft-pfrc-rfc2181-historic-issues-00 Abstract
I would like the WG to adopt these drafts.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
agreed. while my buddies and I push rocks around, Ed can make sure the
“sleeping[*]” is not wakened. :)
*
http://www.stuff.co.nz/world/asia/10099510/Dead-guru-just-sleeping-in-a-freezer
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 6July2015Monday, at
ensure backwards compatibility. In such a case, it might be
reasonable to “fix” ordering
(among many other things).
Or we can continue to put bandaids over the DNS festering wounds.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 6July2015Monday, at 6:59
President of the University. Neither delay, nor redirection will be
effective. Either no answer or an authoritative answer give the community
certainty.
I’ll step back and let the experts “solve” this.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On
use of
the phrase, “name space” with domain. We have empirical evidence of multiple
domains using the same name space.
(Fred Baker persuaded me that there is a single name space, but we
partition/segregate by function/purpose). The same name space for UUCP,
CHAOS, Internet, Onion, etc… just di
On 3July2015Friday, at 9:26, Suzanne Woolf wrote:
>
> It does seem to me that an important feature here is that "TLD" as we're
> using it is "name in the root zone (or root zone space), to be managed within
> a context that assumes DNS protocol and semantics as well as DNS-compatible
> name
I would be happy to write up something about name spaces, partitions, etc.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 3July2015Friday, at 8:18, Patrik Fältström wrote:
> Unfortunately I think we all in this discussion [again] mix up discuss
to be
developed/deployed, OR folks need
to suck it up and just use the Internet portion of the DNS (and its associated
rules, e.g. new TLDs are defined
by ICANN)
/bill
On 3July2015Friday, at 7:01, Warren Kumari wrote:
> On Fri, Jul 3, 2015 at 9:43 AM, manning wrote:
>> Actually, th
” would
work out very nicely.
After all it’s the Domain Name System. (can comprehend names in multiple
domains, not just the Internet)
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 2July2015Thursday, at 20:56, manning wrote:
>
> On 2July2015Thursday,
On 2July2015Thursday, at 18:21, Robert Edmonds wrote:
> manning wrote:
>> There in lies the problem. These systems have no way to disambiguate a
>> local v. global scope.
>> It seems like the obvious solution is to ensure that these nodes do
>> NOT
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 2July2015Thursday, at 16:44, Robert Edmonds wrote:
>
> Have a look at the later HTTP/1.1 RFCs (7230) and the URI generic syntax
> RFC (3986). RFC 7230 defines http URIs, but it relies on the URI
. recognition that the horse has left the barn (.local,
.onion, etc.) there are two options open:
1) close the door before others escape and completely pollute the watershed,
2) throw in the towel and give up
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On
agreed. but a “reserved string” registry isn’t the way to do that… at least
in a scaleable fashion.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 2July2015Thursday, at 10:34, Paul Vixie wrote:
>
>
> manning wrote:
>> ... STRONGL
implementations MUST use the mechanism defined in
Section 6.1 for mapping between domain names and IP addresses. This
means that every Internet SMTP MUST include support for the
Internet DNS.”
This STRONGLY suggests that “domain-looking-string” is , in fact, a host that
is i
name space for domains and the
DNS, I appreciate
effort, but the facts are that overlaps occur in real life (see also: acronym
overload) and the name space
in question is the DNS view of the name space, not domain name space en-toto.
(whee - hows that for
a run-on sentence!)
manning
bmann
unless, of course, DNSSEC allowed for signing individual records instead of
zones.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 30June2015Tuesday, at 6:57, Tony Finch wrote:
> John Dickinson wrote:
>>
>> I have been planning to w
On 29June2015Monday, at 19:07, David Conrad wrote:
And yes, this will fail if any of the loopback drafts are deployed.
>>> Sorry, I must be missing something obvious. Why?
>> As to why, perhaps I am missing the obvious, but if SUDSTA proceeds, does
>> it matter if the origin IP of the root
distributed? It seems that one could not presume to have the
data to assert the penetration of the new keys nor the
origin of the stale keys, if that information was diffused through the IP
address space.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On
This looks very much like the draft that Olaf, Johan, and I wrote at the same
time MSJ was proposing what we have now.
You might want to talk to either Olaf or Johan for more details. And yes,
this will fail if any of the loopback drafts are deployed.
manning
bmann...@karoshi.com
PO Box
ly on each of the
issues and RFC 2181 could be moved to Historic status.
What do you think? Is there a reason to not do this?
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
___
DNSOP mailing list
DNSOP@ietf.org
rrect).”
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 17May2015Sunday, at 16:59, Paul Hoffman wrote:
> On May 15, 2015, at 1:40 AM, Tony Finch wrote:
>> Another item for section 7:
>>
>> DNS operator -- an entity responsible for running
1 - 100 of 109 matches
Mail list logo
