mailing list
posts, and the moderator ought to simply squash anything that's encumbered.
--
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
I think this is exactly the sort of thing the IPR RFC requires for accepting
encumbered ideas. (Although the restriction to root zone operators is a bit
troubling.)
yes. (also, TAKREM was offered free for GPL implementators, and so, worthless.)
Anyways, the basic idea is that there's no
IETF to standardize encumbered IPR so
that he can make money from license fees paid by people who deploy it. i
think that's offensive screwheadedness and i am opposed to it.
--
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org
important.
Other than that, I think this is a good and useful draft, and should
be advanced.
me too!
--
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
Mr. Paul Vixie to ISC, and the subordination relationship that can be
inferred from Mr. Paul Vixie's position as ISC president.
Paul has never tried to control what I do as DNSOP WG co-chair, and
clearly understands the obligations that go with my position. Paul also
knows me well
Austein needs to avoid participating in issues that affect
his company, its financial position, or that of his co-workers.
Should Rob recuse himself from *any* matter that Paul's sent an email
about? What about opinions Paul may have discussed with Rob privately?
Or just things he's
can.
I support using AS112 for that. Great way to reduce the error traffic
at root-servers.net.
wildcards can't be cname's or ns's. (of the many important reasons why
the suggestion is terrible, that's the first/simplest that comes to mind.)
--
Paul Vixie
[EMAIL PROTECTED] (William F. Maton Sotomayor) writes:
At this point, I'd like to see the current pair of drafts move forward,
and would cast this particular issue as the subject of some sort of
other document.
likewise, me.
--
Paul Vixie
. ...
therefore while i find your proposed solution to be of high quality, there
is a cost in overall system complexity for adding a virtual routing layer to
the DNS, which would have to be justified by a much more complete problem
statement and an objective analysis of more than one alternative.
--
Paul Vixie
From: 黄理灿 [EMAIL PROTECTED]
... almost all web pages was unreachable even the machine was in China
because of root servers are located in USA. ...
according to http://f.root-servers.org/, there are two f-root servers in
china. if you have local contacts within china, please help us add
as RFC 2136 was not
correctly implemented, and if people start putting SOA.MNAME=. then it
will just lead to a lot more QTYPE A queries for ..
--
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
NS.NSDNAME, in which case they are
already out of spec and it's difficult to say how much effort should be spent
changing the spec further.
--
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Is it not the case that ANCOUNT=0 RCODE=0 responses could be cached, whilst
failures to send DNS UPDATE messages to root servers would not be cached?
the data at hand tells me that lots of people don't cache, and those who
do only cache positives. but in principle, yes, if the hosts who aren't
mistreatment.
(had i known at the outset how IETF worked, i would have worked to prevent
that mistreatment, but i was a n00b.)
--
Paul Vixie
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean
Paul's original proposal, C (if I interpret it correctly) applies to
resolver-authority-server communications, not stub-resolver
communications.
no, i was pretty much ruling them out period. especially (RA=1 AND RD=0).
however, i could accept a SHOULD NOT for ADNS vs. a SHOULD for RDNS
what would it do if it had a TCP-forbidding firewall between it and its
RDNS?
Dunno, but when PowerDNS had TCP bugs in its resolver code, all the
complaints I got were from Exchange users.
they'll cope.
What's the rush with deprecating DNS/TCP btw? It languished in the shade for
25
Bad example. One of the reasons we don't see more crypto per default on
web browsing is precisely the limitations of SSL/CA's on using SSL with
virtual host web sites. I'd hardly call the lack of port 443 a success
story.
we don't need a reason to deprecate tcp/53 beyond what's written in
worried about corruption inside servers not just between them, and i want
to defend against provider-in-the-middle attacks (including several that
opendns currently monetizes.)
--
Paul Vixie
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed
... let's deprecate these bit patterns altogether for OP=QUERY:
QTYPE=255
Breaks some sendmail versions and qmail.
i once hacked sendmail internals, and what i remember is that it would try
a QTYPE=ANY to see if it could get both the MX and its A in one shot, on the
hopeful
i answered this on namedroppers, where the thread actually belongs.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
DNSOP mailing list
DNSOP@ietf.org
no hop-by-hop solution can address the problem of a MiTM who can see
and/or alter your queries and responses.
If you have a malicious man in the middle, he will do bad things to you.
DNSSEC will not stop that.
please explain how i can get undetectably bad data in a dnssec environment,
of the silent majority of fence sitters watching the back forth.
show some willpower, folks, please.
--
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
the un-answered argument wins
only if it's never answered. that would cross the line.
answering it every day for the rest of all of our lives crosses the other line.
(not responding publically to the personal parts of what bill said to me.)
Date: Wed, 26 Aug 2009 16:39:31 -0500
From: Michael Graff mgr...@isc.org
...
since by definition, I always really need stuff.
+1.
years ago i tried to differentiate between additional data or authority
section data that a requestor could live without, vs. additional data or
authority section
Date: Thu, 03 Sep 2009 06:48:21 -0700
From: Todd Glassey tglas...@earthlink.net
Actually Dean - good point - the MOU was never codified in a formal
contract meaning that the US Department of Commerce still formally owns
the root's and so under this newly proposed cyber-control law would
From: Nicholas Weaver nwea...@icsi.berkeley.edu
Date: Fri, 19 Mar 2010 12:48:24 -0700
...
Enshrining tho shalt never fragment into the Internet Architecture is
dangerous, and will cause far MORE problems. Having something which
regularly exercises fragmentation as critical to the
From: John L. Crain john.cr...@icann.org
Date: Sun, 21 Nov 2010 09:51:45 -0800
Why would we do this, who gains by adding this?
I don't see the benefit.
i think it's so that folks can refuse e-mail from domains under N days
old where N is a local policy decision. i have no direct use for
Date: Mon, 22 Nov 2010 20:36:17 +
From: bmann...@vacation.karoshi.com
we tried this a couple time last decade with limited success. (pre
SRV). it would work, if and only if there were general agreement by
the zone admins to actually keep up w/ the data.
while i expect that it would
Date: Mon, 22 Nov 2010 22:52:34 +
From: bmann...@vacation.karoshi.com
well, at least two schemas have been proposed and there was
limited uptake either time. perhaps times have changed.
the fact that so few people have spoken up gives me my answer -- there's
not enough
On Tuesday, September 27, 2011 09:49:03 am Masataka Ohta wrote:
Xun wrote:
Unicast address of an
anycast server is very useful for many diagnostics, however, as
DNS queries is sent to the anycast address and the path is decided
by routing system, knowing the set of unicast address may not
On Tue, 27 Sep 2011 22:51:09 +0900
Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote:
Paul Vixie wrote:
The purpose I see in this proposal, that cannot be handled by the
IP layer, is to tell me which anycast instance is seen by some
recursive name server. All our current diagnostics
On Thursday, September 29, 2011 07:34:55 am Masataka Ohta wrote:
The problem is that the report is unreliable. As your assumption is:
The purpose I see in this proposal, that cannot be handled by
the IP layer, is to tell me which anycast instance is seen
by some recursive name server.
On Thursday, September 29, 2011 03:36:26 pm Nicholas Weaver wrote:
Word wrapping MUST be done on the recipient side, not on the sender side,
unless you want to maintain ridiculous conventions like text lines are at
most 72 characters, monospaced which were obsolete two decades ago.
And in
On Thursday, October 27, 2011 10:06:25 Havard Eidnes wrote:
I wonder if I could please have someone say whether they agree
with me on this one:
...
My claim is that it is a Registry Error for the operator of the
registry for the 'z' domain to permit this to happen, as it
violates the basic
On 1/18/2012 7:06 PM, W.C.A. Wijngaards wrote:
this sounds very cool; is there an internet draft or tech note
describing the protocol so that others may also implement this?
It exists to bypass deep inspection firewalls, and it works. The plain
DNS format as you would use over TCP, but
On 2/11/2012 5:25 PM, Paul Hoffman wrote:
On Feb 9, 2012, at 1:39 PM, bmann...@vacation.karoshi.com wrote:
I think that starting work on such a draft is a great idea -BUT- in the mean
time
do not let perfect get in the way of good enough.
Just to be clear: a good handful of people, me
On 2/14/2012 5:20 PM, David Conrad wrote:
...
I agree, however I'd think a better approach would be to write a BCP for
important DNS servers, not a document that sets up false expectations or
assumptions.
+1. there are a lot of important non-root dns servers, and the collected
wisdom of all
On 2012-02-28 12:27 AM, Edward Lewis wrote:
At 13:35 -0500 2/27/12, Hector Santos wrote:
If it doesn't already exist or not considered in the past as an
unfeasible concept, I am interest in seeing if this is something
worth pursuing.
One (not the only, Ohta replied with another) of the
On 2/28/2012 3:28 AM, Hector Santos wrote:
Paul Vixie wrote:
... http://nsa.vix.com/~vixie/edns1.txt.
Thanks Paul. Great material.
I'm just winging it at this point.
First, I was focusing on the batching of related types, i.e. a
protocol with new RR type but has an initial default intro
On 2/28/2012 5:57 PM, Nicholas Weaver wrote:
But since if you could coalesce you could do parallel, this savings doesn't
help latency much at all: just the transit time for 50B out and 50B back. If
anything, parallel will be BETTER on the latency since batching would
probably require a
joe, et al,
your draft-gersch-dnsop-revdns-cidr-01 is very clean and simple; the
draft and the design are of admirable quality. as a co-author of RFC
2317 i agree that it does not suit the needs of bgp security since it
seeks only to provide a method of fully naming hosts, not networks.
On 3/30/2012 10:19 AM, Ray Bellis wrote:
With the current scheme it's possible to delegate longer prefixes, and this
is a necessary feature.
The stuff Dan was saying about two alternate representations concerns me,
though. As written, by default:
192.168.64/18 is 1.0.m.168.192
but
On 2012-04-04 12:20 PM, William F. Maton Sotomayor wrote:
It seems that after delivering my presentation on subsequent AS112
delegations in Quebec City, I hadn't recalled what the group thought
about adopting this work as a dnsop item. So, I'm soliciting feedback
on this request. I have
the information economics of this draft are all wrong. with all possible
respect for the comcast team who is actually validating signatures for
18 million subscribers and is therefore way ahead of the rest of the
industry and is encountering the problems of pioneers... this is not
supposed to be
. an actual security
incident. IOW, if we do this, we might as well just abandon DNSSEC
altogether.
this is what i was alluding to in some text up-thread:
On 2012-04-13 5:43 PM, Paul Vixie wrote:
... i'm opposed to negative trust anchors, ... for their security
implications if there were secure
On 2012-04-15 4:09 PM, Patrik Fältström wrote:
On 15 apr 2012, at 16:42, Joe Abley wrote:
Nobody is talking about creating NTAs. NTAs already exist. The question for
this group is whether or not they are worth standardising.
Fair. I am the one that extrapolate from standardizing to wide
On 2012-04-15 4:20 PM, Stephan Lagerholm wrote:
... However, the open resolvers that don't support DNSSEC are a bigger
issue since the Service Providers' customer instantly can get what
he believes is a better working resolver by switching to one of those.
If we could convince 8.8.8.8
On 2012-04-15 7:04 PM, David Conrad wrote:
On Apr 15, 2012, at 9:37 AM, Paul Vixie wrote:
i'd tell validator operators who think they need NTA's in
order to control the risks posed by zone owner errors, if you can't
stand the heat then stay out of the kitchen.
Given the benefits provided
On 2012-04-15 9:07 PM, David Conrad wrote:
I guess in the end it boils down to the philosophical question of the
role of the IETF. If DNSOP declines to accept this topic, I suspect it
merely means each vendor will come up with their own implementation
with their own quirks that operators will
On 4/17/2012 9:51 AM, Shane Kerr wrote:
Is it just me, or does the NTA discussion remind anyone else of NAT
discussions? And not just because they have the same letters. ;)
Operators say, wow, here is a useful tool that can solve real-world
problems, maybe it would be helpful to recognize
On 4/18/2012 6:28 PM, David Conrad wrote:
... Their validator, their rules. ...
that would be a fundamental change to the architecture of dnssec.
see again:
http://www.circleid.com/posts/20121012_dns_policy_is_hop_by_hop_dns_security_is_end_to_end/
On 4/25/2012 4:58 PM, Alfred � wrote:
It has been pointed out that the DNS Referral Response Size Issues
I-D should not be left going to final expiry, and I have performed
a new review of the last version, draft-ietf-dnsop-respsize-13.
I only found a small number of remaining editorial nits
On 6/27/2012 6:15 PM, Joe Abley wrote:
...
Adopt this doc?
yes please.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 2012-08-30 9:40 AM, Johan Ihrén wrote:
On Aug 20, 2012, at 17:33 , Paul Hoffman wrote:
On Aug 20, 2012, at 6:19 AM, Peter Koch p...@denic.de wrote:
My current reading of the sense of the WG is that we move to
WGLC with -03, declaring the July 24 suggestion out of scope
for this document
On 2012-11-21 4:44 PM, Ted Lemon wrote:
... Aside from this quibble, I think the document is useful and should
be published.
my quibble is different. ipv6 is bringing some tough love to the
consumer-facing edge. the fact that ISP's auto-populated the IPv4 PTR
tree made it impossible for mail
On 2012-11-23 2:34 PM, Mark Andrews wrote:
...
There is nothing wrong with using the SOA record from the -ve
response. Named has been doing it for about 15 years in nslookup.
If it is not there it falls back to stripping a label at a time
until it gets the SOA record.
indeed not. i think
if we can't return nxdomain, then i'm opposed to the omniscient spec,
and we should continue as before, enumerating on the responding servers
every zone to which we wish to delegate.
noerror/nodata is the wrong answer.
___
DNSOP mailing list
...
Tony Finch wrote:
...
Why not something like Paul's metazone idea to automate the configuration
of which zones the server should answer for?
for reference:
http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html
paul
___
DNSOP mailing
...
Paul Vixie wrote:
...
Tony Finch wrote:
...
Why not something like Paul's metazone idea to automate the configuration
of which zones the server should answer for?
for reference:
http://www.ietf.org/mail-archive/web/dnsop/current/msg05192.html
that message's pdf attachment appears
Joe Abley wrote:
...
ONION is like LOCAL. Neither are like ARPA (or any other TLD).
How like LOCAL is ONION? ICANN knows it can't sell .LOCAL, but does
ICANN know it can't sell .ONION ?
___
DNSOP mailing list
DNSOP@ietf.org
Zi Hu wrote:
We recently posted draft-hzhwm-start-tls-for-dns-00 (Starting TLS over
DNS) to explore one proposal to add standard TLS over standard DNS to
improve privacy.
http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-00
This topic may be of interest to DNSOP and PERPASS. Some
Joe Abley wrote:
...
If we believe all these problems are intractable, then we might as well just
accept that overloading TXT records and reflection attacks are a fact of
life, and stop worrying about them.
reflection attacks aren't a fact of life. DNS RRL does not require a
forklift
Lawrence Conroy wrote:
Hi Chaps,
stupid quick question, listening to the stream:
How does this work with CDNs (I think you may need to capture the IP address;
bailiwick could act as a proxy for that, but ...)
this is well described, as follows:
Phillip Hallam-Baker wrote:
This was the use case that originally drove the development of OmniBroker.
If we do DNS Encryption right it is going to be very easy for end
users to chose their DNS provider and very hard for the authorities to
block them.
+1.
Security is a balance. Going
bert hubert wrote:
...
43.504115 IP x.y.117.10.0 192.175.48.6.53: 6365+ SOA? 168.192.in-addr.arpa.
(38)
45.504152 IP x.y.117.10.0 192.175.48.6.53: 6365+ SOA? 168.192.in-addr.arpa.
(38)
49.505124 IP x.y.117.10.0 192.175.48.6.53: 6365+ SOA? 168.192.in-addr.arpa.
(38)
PowerDNS now
Christopher Morrow wrote:
If I have a patch which makes no sense, will you also add it?
nope. not for you anyway. only mark andrews.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
for reasons well-spoken up-thread, if we're going to add a dns
transport, i'd like it to be RFC 6013 style TCP (in which session
context can be compressed and retained after FIN for full-window-size
restart, and which permits the query to be bundled into the SYN packet),
or at a minimum, SCTP.
Andrew Sullivan wrote:
Dear Uncle Ben,
keep it civil, please.
On Wed, May 07, 2014 at 07:26:51PM +0200, P Vixie wrote:
The architectural context of a feature should not be divorced from its
specification. RFC is an imprimatur. With great power comes great
responsibility.
I disagree
Tony Finch wrote:
Barry Margolin pointed out an amusing interaction between two stupid DNS
tricks on the bind-users list:
https://lists.isc.org/pipermail/bind-users/2014-May/093171.html
If you have an authoritative server with ANAME or CNAME flattening
support, and the target of the ANAME
Ralf Weber wrote:
...
There is madness, but the madness is in mixing authoritative and recursive
functions in one server and not in using DNS to direct traffic.
while i'm on record has holding that view, it turns out that RFC 1035
does describe recursion and authority as co-residing in a
one of the icann ssac (then secsac) consensus processes i am most
proud to have been part of was this, in 2004:
http://www.icann.org/en/groups/ssac/report-redirection-com-net-09jul04-en.pdf
indeed, this document and the process followed in creating it may still
stand today, as ssac's finest
Mark Delany wrote:
On 17May14, Mark Andrews allegedly wrote:
domain ENAME domain {0|1} [type list of included / excluded types]
(0 == include, 1 == exclude)
As I recall, the HTTP/2.0 folks have been intermittently talking about
supporting SRV. Would encouraging that group
Mark Andrews wrote:
... Everytime I have mentioned SRV records to HTTP folks they say it
won't work as the extra lookup takes too long.
this sounds strange to me. TTL=0 SRV RR's strike me as precisely what
the CDN industry needs, since they can include an (or for
back-compatibility, an
Ted Lemon wrote:
On May 19, 2014, at 6:12 PM, David C Lawrence t...@akamai.com wrote:
Not so much pushing required, at least of Akamai. You have a
ready-made [SRV] ally in me, if only clients actually made good use of it.
The clients are the real obstacle.
Yup. It would be great if we
Mark Delany wrote:
one can lookup A, and SRV in parallel and positive answer
to SRV, as Paul mentioned, can have additional A and RRs.
A downside is that clients has to wait for the SRV query to complete
so they can be sure of the presence or not of an SRV. ...
in a blast
Masataka Ohta wrote:
Mark Andrews wrote:
The reason why CNAME is prohibited at a zone apex is described in RFC 1034:
If we must change something, isn't it easier to allow CNAME at
a zone apex than introducing ENAME?
the reasons for prohibiting it, as given in RFC 1034, still apply.
.
If you would like to volunteer please kindly indicate those intentions known by
sending an email to rssac-members...@icann.org.
Kind Regards,
Kaveh Ranjbar, RSSAC Membership Committee Chair
Tripti Sinha, RSSAC Membership Committee Member
Paul Vixie, RSSAC Membership Committee Member
session at ICANN 50 and it
was announced that first face to face caucus meeting will be held during
IETF 90 in Toronto.
Kind regards,
Paul Vixie
on behalf of RSSAC Caucus membership committee
re:
Paul Vixie wrote:
Greetings,
If you are interested in participating at ICANN's Root Server System
Tim Wicinski wrote:
...
On 6/24/14 3:57 AM, Paul Hoffman wrote:
My hope is that DNSOP doesn't become too DNSEXT-like where if the -00
for a proposal isn't universally loved, it is destroyed instead of
worked on.
We as chairs do not have that mind set. My personal feeling is to
figure
Hosnieh Rafiee wrote:
Hello,
We actually put all our efforts to change the document thoroughly and not
only consider the IPv4 scenario that was comment of some people in
mailinglist but also we expand the DNS privacy section and explained it in
more detail (no need to change the protocol.)
i've now seen a number of proposals reaction to the snowden
disclosures, seeking channel encryption for dns transactions. i have
some thoughts on the matter which are not in response to any specific
proposal, but rather, to the problem statement and the context of any
solution.
first, dns data
Joe Abley wrote:
Hi Paul, Warren,
On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote:
Greetings. Warren and I have done a major revision on this draft, narrowing
the design
goals, and presenting more concrete proposals for how the mechanism would
work. We welcome
Matthäus Wander wrote:
* Paul Vixie [7/5/2014 5:04 AM]:
datagram level channel secrecy (for example, DTLS or IPSEC) offers a
solution which matches the existing datagram level UDP transport used
primarily by DNS. however, the all-pervasive middleboxes (small plastic
CPE devices installed
Matthäus Wander wrote:
* Paul Vixie [7/5/2014 7:47 PM]:
Matthäus Wander wrote:
DTLS works on top of UDP (among others) and thus can pass CPE devices.
no, it cannot. DTLS does not look something that the CPE was programmed
to accept; thus in many cases it is silently dropped.
DTLS can
Hannes Tschofenig wrote:
Just a minor note on this paragraph:
because HTTPS currently depends on X.509 keys, other
groups in the IETF world are already working to make HTTPS proof against
on-path surveillance. (google for perfect forward secrecy to learn
more), and others are working to
Bernard Aboba wrote:
this is extremely narrow but i can envision activists and dissidents who
rightly fear for their safety based on this narrowly defined threat
[BA] Presumably protection would only be from an attacker that can snoop on
the wire, but not have access to the logs?
yes.
Paul Ferguson wrote:
...
That is *not* to say that DANE is not a desirable thing to
deploy/accomplish.
DANE relies on DNSSEC which relies on EDNS. the placement of a
DNS-over-HTTPS channel would have to be below EDNS in the stack, and
non-reliant. therefore my correction up-thread --
Nicholas Weaver wrote:
...
One important observation: ONLY the path between the client and the
recursive resolver in the classic model substantially benefits from channel
security.
if i were proposing a secrecy scheme that was easy to do on
stub-to-recursive but hard to do on
Matthäus Wander wrote:
...
I didn't mean to imply that a DTLS solution can be universally deployed.
because the dns is a map to the territory known as the internet, and
because most internet packet flows begin with a dns transaction, i'm
dismissing out of hand anything that will almost
David Conrad wrote:
Paul,
...
that's why query minimization is the preferred solution to this problem.
This isn't either/or.
are you proposing to solve problem A (junk queries at the root) and
problem B (junk queries at tld's and pseudo-tld's) using different
mechanisms? why is the cost
Declan Ma wrote:
Zhiwei,
Your proposal seems reasonable. But we can not separate the
recursive-level and authorative-level, as you call it by the way, since the
DNS is an integrated one. If both of the two solutions are feasible, we need
to figure out how and to what extent, both
Paul Hoffman wrote:
On Jul 9, 2014, at 12:43 AM, Paul Vixie p...@redbarn.org wrote:
in my opinion, the applicability statement of a recursive solution would
be: if you want these benefits and can manage these risks, then you can
configure your rdns as follows. whereas the applicability
Paul Hoffman wrote:
On Jul 9, 2014, at 10:45 AM, Paul Vixie p...@redbarn.org wrote:
Criticisms of the current and historical Root Name Server System include
lack of resistance to DDoS attack, noting that even with the current wide
scale anycasting by every Root Name Server Operator
Paul Hoffman wrote:
On Jul 9, 2014, at 11:15 AM, Paul Vixie p...@redbarn.org wrote:
Paul Hoffman wrote:
...
Apologies, but that doesn't answer the question. In the face of lack of
resistance to DDoS attacks, why is it better to have more *authoritative*
root servers, as compared
Paul Hoffman wrote:
On Jul 9, 2014, at 1:47 PM, Paul Vixie p...@redbarn.org wrote:
i don't know how to state the case more clearly. my answer is not no as
you surmise. the cost of the recursive solution is high and the benefit low.
the cost of the authoritative solution is low
David Conrad wrote:
On Jul 9, 2014, at 2:17 PM, Paul Vixie p...@redbarn.org wrote:
the freebsd experiment proved this to my satisfaction,
My understanding of the freebsd experiment you keep referencing was that
one individual on the FreeBSD core team decided to change the default
Tony Finch wrote:
John C Klensin john-i...@jck.com wrote:
IN MX 0 .
At least in the near term, some SMTP Server (MTA)
implementations will conform to that rule (many already use it)
and some won't. For the latter, they will presumably do what
the SMTP specs say to do. In summary,
David Conrad wrote:
Masataka,
On Jul 23, 2014, at 7:57 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
wrote:
http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03
In what context, did you mention it?
I asked if the authors had compared their draft
i think there's a necessary and healthy tension between the installed
base and new technology. i would not like to see every new application
designed to run inside TCP/80, even though that's the only universal
wide area protocol. and we won't see any new application that requires a
forklift
as at least a reviewer
and perhaps (if invited) as an editor.
--
Paul Vixie
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
1 - 100 of 937 matches
Mail list logo
