a Call for Adoption for draft-wkumari-dnsop-root-loopback
The draft is available here:
https://datatracker.ietf.org/doc/draft-wkumari-dnsop-root-loopback/
Please review this draft to see if you think it is suitable for
adoption by DNSOP, and comments to the list, clearly stating your view
On Nov 26, 2014, at 1:12 AM, Jiankang Yao ya...@cnnic.cn wrote:
Are the functions of this kind of recursive resolvers similar to the slave
server of the root?
Yes, of course. As defined in the document, the local root server has exactly
the root server data in it, and acts like an
for adoption.
-Original Message-
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Hoffman
Sent: November-17-14 11:05 PM
To: Nicholas Weaver
Cc: dnsop
Subject: Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
On Nov 17, 2014, at 5:50 PM, Nicholas Weaver nwea
The question at the end of this post was a serious one, FWIW.
On 11/17/14 3:39 PM, Doug Barton wrote:
On 11/17/14 2:50 PM, Evan Hunt wrote:
On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote:
That seems like something that should be fixable in BIND, yes? (And
thanks for doing that
I agree: the validate everything knob seems like a win/win.
I would also like the option of verifying a DNSSEC domain when I do a zone
transfer, because that might be more efficient.
--
Bob Harold
University of Michigan
On 11/17/14 3:39 PM, Doug Barton wrote:
On 11/17/14 2:50 PM, Evan Hunt
On Nov 20, 2014, at 9:19 AM, Doug Barton do...@dougbarton.us wrote:
The question at the end of this post was a serious one, FWIW.
If I understand it correctly, the question is a feature request for
BIND/NSD/whatnot, not an issue with the draft, correct? That is, I think you
are asking for your
On 11/20/14 9:34 AM, Paul Hoffman wrote:
On Nov 20, 2014, at 9:19 AM, Doug Barton do...@dougbarton.us wrote:
The question at the end of this post was a serious one, FWIW.
If I understand it correctly, the question is a feature request for
BIND/NSD/whatnot, not an issue with the draft,
I can see where validate on zone transfer would be a feature request.
And validate everything similarly.
For the draft, could a small paragraph be added explaining the difference
between using a separate view for the root zone and just loading it in the
same view, so that people like me realize
On Nov 20, 2014, at 10:20 AM, Bob Harold rharo...@umich.edu wrote:
I can see where validate on zone transfer would be a feature request. And
validate everything similarly.
For the draft, could a small paragraph be added explaining the difference
between using a separate view for the root
Jacques,
On Nov 20, 2014, at 9:11 AM, Jacques Latour jacques.lat...@cira.ca wrote:
I think the one big drawback for me is the loss visibility and control for
the root operators.
Lack of comprehensive statistics would indeed be an issue (I'm not going to
comment on the control bit of your
Thanks Paul,
I use BIND, but am not an expert. Based on the discussion I will
suggest some words and the experts can correct me:
Note: By using a separate view, the recursive view will do DNSSEC
validation on the responses it receives from the root view, which is
necessary for security. It
What about something like this:
When using BIND, or other software that can act as both a recursive and
authoritative server in the same instance, there is a tradeoff between
using a separate view (or separate instance) for slaving the root zone,
versus slaving the zone into the same view (or
On Thu, Nov 20, 2014 at 11:13:42AM -0800, Doug Barton wrote:
Slaving the zone into the same view/instance as the recursion has the
advantage that when changes happen to the data in the zone the recursive
view/instance will be updated as soon as it receives its copy of the
zone. When using a
On 11/20/14 11:27 AM, Evan Hunt wrote:
On Thu, Nov 20, 2014 at 11:13:42AM -0800, Doug Barton wrote:
Slaving the zone into the same view/instance as the recursion has the
advantage that when changes happen to the data in the zone the recursive
view/instance will be updated as soon as it receives
On 11/16/14 11:12 PM, Evan Hunt wrote:
On Sun, Nov 16, 2014 at 03:12:58PM -0800, Doug Barton wrote:
Before commenting further I'd love the authors to flesh
out their reasoning for not simply slaving the zone where possible.
I'm not one of the authors, but I can give you an answer: in BIND,
Doug Barton mailto:do...@dougbarton.us
Monday, November 17, 2014 2:16 PM
That seems like something that should be fixable in BIND, yes? (And
thanks for doing that testing, btw)
it's not broken. dnssec has no facility for validating data at slave
synchronization time (after each axfr or
On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote:
That seems like something that should be fixable in BIND, yes? (And
thanks for doing that testing, btw)
Yes, by using two views and slaving the root in one of them and validating
in the other one, like it recommends in the draft. :)
On 11/17/14 2:50 PM, Evan Hunt wrote:
On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote:
That seems like something that should be fixable in BIND, yes? (And
thanks for doing that testing, btw)
Yes, by using two views and slaving the root in one of them and validating
in the other
Nicholas,
On Nov 17, 2014, at 5:50 PM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
Lookups to the root themselves should be rare, and the responses have very
long TTLs (48 hours!).
Lookups for names that do not exist are quite (one might say insanely) frequent
and the TTL less (Values
On Nov 17, 2014, at 5:50 PM, Nicholas Weaver nwea...@icsi.berkeley.edu wrote:
Trying to be polite here, but this seems just silly, and the only thing
really should be Don't Bother.
Root latency frankly speaking does not matter. Lookups to the root
themselves should be rare, and the
Please review this draft to see if you think it is suitable for adoption
by DNSOP, and comments to the list, clearly stating your view.
Yes, I think the WG should adopt it. It has some editorial issues, and perhaps
should explain why it doesn't allow, e.g., root on the same LAN rather than only
Hi
In case I wasn't clear enough, the chairs will accept all the emails
supporting the CfA from warren's previous email, so you'll not need to
resend.
thanks
tim
On 11/16/14 1:45 PM, Tim Wicinski wrote:
This starts a Call for Adoption for draft-wkumari-dnsop-root-loopback
The draft
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 11/16/14 1:45 PM, Tim Wicinski wrote:
|
| This starts a Call for Adoption for
| draft-wkumari-dnsop-root-loopback
I have read the draft, I support its adoption, and I will review and
contribute text as necessary.
It should come as no surprise
On Sun, Nov 16, 2014 at 03:12:58PM -0800, Doug Barton wrote:
Before commenting further I'd love the authors to flesh
out their reasoning for not simply slaving the zone where possible.
I'm not one of the authors, but I can give you an answer: in BIND,
and I believe in other DNS implementations
On Sun, Nov 16, 2014 at 02:28:19PM -0800, Tim Wicinski wrote:
In case I wasn't clear enough, the chairs will accept all the emails
supporting the CfA from warren's previous email, so you'll not need to
resend.
I can't remember if I already said I supported adoption. If so, I
support adoption
25 matches
Mail list logo
