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.
>
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
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
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
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
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
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
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
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
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
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
for WG consideration…
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
Begin forwarded message:
> From: manning
> Subject: observations re:
> https://tools.ietf.org/html/draft-ietf-dnsop-resolver-priming-05
> Date: April 27, 2015 at 15:08:13
this is what I think of when I look at the DNS protocol. Well done Lyman!
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 30April2015Thursday, at 8:14, Lyman Chapin wrote:
>
> On Apr 29, 2015, at 6:39 PM, Paul Hoffman wrote:
>
>> On Apr
terminology at the protocol level
and terminology for implementation and policy.Is that concern important to
the group?
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 1May2015Friday, at 7:41, Edward Lewis wrote:
>
>
> On 4/30/15, 10:35
again, this is where the document tries to cover terminology for both the DNS
protocol and the DNS policy/operations (as seen through the lens of today).
I don’t see any reason to define anything other than TLD.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
terminology at the protocol level
and terminology for implementation and policy.Is that concern important to
the group?
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 1May2015Friday, at 7:41, Edward Lewis wrote:
>
>
> On 4/30/15, 10:35
As long as we are taking this path, will the Special Use Names folks please
remove MX from the ISO 3166 list and
delete the TLD so as not to confuse email … MX is so overloaded.
manning
bmann...@karoshi.com
PO Box 12317
Marina del Rey, CA 90295
310.322.8102
On 8May2015Friday, at 16:10
Research and Burlington Northern Railroad.Bell registered
BNR.com and was challanged (successfully) by
Burlington over the domain name, since the railroad predated the telecom lab.
Will the Special Names Registry be used for legal challenges?
manning
bmann...@karoshi.com
PO Box 12317
Marina
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
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
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
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
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
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
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
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
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
. 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
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
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
” 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,
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
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
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
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
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
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
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
-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
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.
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
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
&
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
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
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
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
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
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
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
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
-- 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
'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
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
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
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
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
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
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
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
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
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:
>>
-- 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
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
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
:
>
>
> 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
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
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,
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.
>
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
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
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
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,
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
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
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:
>
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
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:
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-
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
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
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
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
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
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
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
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
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
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:
>
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
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
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
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
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
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,
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
"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
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
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
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
1 - 100 of 109 matches
Mail list logo
