Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
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 again. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
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 as well, local authoritative data isn't subject to DNSSEC validation. > (And yes, I'm aware that one of the primary motivators is DNSSEC, but the > only thing in the root that we care about are the DS records, and a > validating resolver is going to chase those up to its trust anchor > anyway.) No. If the root zone is slaved locally in the same view as the validator, then the server (correctly) sees the top level DS as local authoritative data, and presumes it to be valid. (I just tested BIND to confirm this. The log shows that org/DNSKEY, isc.org/DS, and isc.org/DNSKEY were validated, but org/DS wasn't.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
-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 that I'm in support, as I've been advocating slaving the root zone locally since 2001. :) The one flaw I see in the draft is that the configuration it recommends is needlessly complex. Where possible (such as for BIND) slaving the zone in the resolver instance gives a lot of benefits, and few drawbacks. Before commenting further I'd love the authors to flesh out their reasoning for not simply slaving the zone where possible. There is currently some mumbling about the resolver not handing out AA, but no reasoning as to why that is a problem. I've read the threads on the original draft, and on this one, and there was some good discussion of pros and cons there, I'd like to see some of that discussion in the text. (And yes, I'm aware that one of the primary motivators is DNSSEC, but the only thing in the root that we care about are the DS records, and a validating resolver is going to chase those up to its trust anchor anyway.) Doug -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUaS96AAoJEFzGhvEaGryEOf8IALMQEt2gg3SUuJs8VKSz5w40 lcrooyF+NUrqS3+uWdlzIddHsm2fqluXV25QNiRDySn7J/We/dsokBr8RxH7nqLc aSupz/domI7uTaPD/hz7LR/5HNf/7vCfUrlhlWn9FoboZQy7FeOqFr8HQrGSEKw1 IsXCCHK23U9QEQM16I96kBCUO+JSM+w1ACqKaSo3qJMxG37fAAzPSga0X6UeLlaJ +amLZzWu5I2QrbhqQNYeFm4t5jDg2wi8NrS8u5IxDSWRUEWrNnz9lO4UpjOl8gjo EQS+T618nUeLBawFxMNmcrFMU4SS6654oD0ttXGN+hbxoXBAVRJMHCuGMlXMcik= =hAqD -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
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 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. Please also indicate if you are willing to contribute text, review, etc. We will take all adoption support from Warren's email. This official call for adoption ends Sunday, November 30th, 2014. Thanks, tim wicinski DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption 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. 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 the same host, but we can easily deal with those. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback
This starts 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. Please also indicate if you are willing to contribute text, review, etc. We will take all adoption support from Warren's email. This official call for adoption ends Sunday, November 30th, 2014. Thanks, tim wicinski DNSOP co-chair ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] "Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia" (circleid)
On Friday, November 14, 2014, Wolfgang Nagele (AusRegistry) <
wolfgang.nag...@ausregistry.com.au> wrote:
> Hi,
>
> AS112 absolutely proves that unowned anycast can work at scale; that's
> not
> my concern. But if my neighbor announces a route to the AS112 addresses,
> and then misconfigures a server, fills it with lies, or logs all my
> queries, the practical effect on me is pretty small: the worst case
> scenario I can think of offhand is that somebody gleans information about
> my internal network topology that probably wouldn't have been difficult to
> guess anyway.
>
> One of my biggest concerns about the current proposal is that it seems
> to suggest that AS112 works.
>
Actually, AS112 works just fine
.
.
.
... except when it doesn't.
It is very hard to discover who is answering AS112 queries and go poke them
when things go awry - luckily, the primary effect of a "bad" AS112 node is
often (usually?) just a reduction in the AS112 benefit - it doesn't
actually break you, it just means you don't get the win.
The very fact that anycast works so well means that finding all the AS112
nodes and contacting them, to either delegate new space to them, or remove
existing delegations lead to the omniscient-as112 draft, and
then draft-ietf-dnsop-as112-dname ("AS112 Redirection using DNAME"), which,
IIRC finished IETF LC is waiting for us to incorporate a comment or two.
> I would like to find some definition of “works” and how we come to that
> conclusion. In my experience there are AS112 nodes out there that are
> misconfigured in many ways (RIPE Atlas be your friend). Returning
> SERVFAILs, wrong data, etc. While wrong data is safeguarded by using DNSSEC
> in this proposal, malfunction is likely to occur still and can be just as
> bad.
>
Well, luckily DNSSEC is ubiquitous at this point...
> In the current system this issue is lessened due to the many different
> operators.
> Within a given enterprise or ISP that would have limited impact and one
> could just point the finger at them and not care (although I don’t agree
> with that either). However route leaks are going to occur as they have in
> the past (no-export stripping happens by accident) and will start to have
> impact on users outside of that admin/routing domain. Assuming that local
> routes are always the routes that are chosen first is a flawed assumption.
> Routing is integral to this proposal and cannot be disregarded if you wanna
> find a workable solution.
>
> From a TLD operator perspective I think it’s a huge step backwards that
> we will loose our update propagation assurance. Will I have to rely on the
> RRSIG expiry as my worst case scenario for a zone update to be fully
> propagated? With the sort of requirements that are put on TLD operators and
> DNS operators these days that sounds completely unacceptable path to me.
> It’s very different from AS112 where there is are simple zones that are
> configured as master and then remain that way.
>
> I support the expansion of root server deployments. In my opinion this
> can be fully achieved in the given framework and ICANN as the operator of
> L-root has shown what can be done in a very short period of time. The
> discussion should be about the standards of operation that each root server
> operator is held to these days. There should be no question that some of
> the current root server operators muscle a way more substantial deployment
> than others. If it’s politically too sensitive/hard to establish any level
> of quality with the given root server operators, the addition of other root
> server operators within the current protocol limitations could be used to
> hold them to a certain standard. For the overall system to function well
> this would suffice. This is very similar what was done as part of the new
> gTLD program from ICANN where a whole set of requirements was added that
> didn’t exist before (IPv6, DNSSEC, etc.).
>
> In closing, this draft proposes a solution to a problem that hasn’t been
> quantified and has no measure of success. Personally I think that’s bad
> practice.
>
> Regards,
> Wolfgang
>
--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
