On 2010-03-09, at 11:59, Tony Finch wrote:
> On Tue, 9 Mar 2010, Matt Larson wrote:
>>
>> Even after .net is signed (in Q4 2010)
>
> I note that Verisign's press releases say "by Q1 2011" which I find rather
> hard to interpret. Why don't they say "by the start of 2011"? Do they mean
> "in Q1 2
Hi all,
A quick update since we have a meeting today. From measurements made at ICANN
it seems that the D, E and K root servers have all completed their DURZ
transition. This leaves the current status as follows:
A DURZ
B unsigned
C unsigned
D DURZ
E DURZ
F unsigned
G unsig
On 2010-03-24, at 11:27, Joe Abley wrote:
> Hi all,
>
> A quick update since we have a meeting today. From measurements made at ICANN
> it seems that the D, E and K root servers have all completed their DURZ
> transition. This leaves the current status as follows:
>
> A
On 2010-04-06, at 09:22, Alfred HÎnes wrote:
> The 4th paragraph of that section in the draft says:
>
> | This document also ignores IP6.INT. IP6.INT has been wound up with
> | only legacy resolvers now generating reverse queries under IP6.INT
> | [RFC4159].
I also think the text above coul
On 2010-05-13, at 19:33, Mark Andrews wrote:
> There are lots of way to do this.
> * Use UPDATE to update the delegation records in the parent.
> This would work today it only requires a willingness to do so.
> This can be done securely (TSIG) and will scale.
>
On 2010-05-13, at 22:13, Joe Abley wrote:
> ... and there's also the approach that is actually being implemented, which
> is described in RFC 4310.
Or 5910, since that seems to exist now. :-)
Internet Engineering Task Force (IETF) J. Gould
Request for Com
On 2010-05-13, at 22:32, Mark Andrews wrote:
> Which is essentially registrar to registry. It really does not
> make for a general solution to the problem unless every operator
> of every zone that delegates any zone runs epp in addition to running
> a DNS server.
Sure, but be aware that you're
Hi all,
FYI -- see below.
The authors currently plan to seek advancement of this document as an
individual submission rather than a working-group document, but certainly
people here should be aware of it (and reviews and suggestions, as always,
would be most welcome).
Joe
Begin forwarded me
Hi Peter, Stephen,
An earlier version of this document passed working-group last call. This
document has some minor changes as described in Appendix A that the authors
believe are non-substantive.
The authors are of the opinion that this document is ready to be written up and
sent to the IESG.
Hi Peter, Stephen,
The authors are of the opinion that this document is ready for working-group
last call.
Thanks,
Joe
Begin forwarded message:
> From: internet-dra...@ietf.org
> Date: 29 July 2010 09:00:02 EDT
> To: i-d-annou...@ietf.org
> Cc: dnsop@ietf.org
> Subject: [DNSOP] I-D Action:dr
On 2010-08-02, at 12:33, Peter Koch wrote:
>> The authors are of the opinion that this document is ready to be written up
>> and sent to the IESG.
>
> the chairs intend to send this version of the document to the AD/IESG
> for publication as an Informational RFC in the FYI subseries (see RFC 11
On 2010-09-13, at 10:36, W.C.A. Wijngaards wrote:
> On 09/10/2010 01:24 PM, Stephen Morris wrote:
>>
>
>> 1. Is the situation addressed by the draft - that of a validator that
>> has been offline or that has missed an (emergency) rollover needing
>> to reconfigure itself - a problem that needs
On 2010-09-14, at 13:55, Tony Finch wrote:
> On Tue, 14 Sep 2010, Joe Abley wrote:
>>
>> Doesn't trust-history impose a requirement high standards of operational
>> security for key materials which have long since fallen out of
>> production, and hence exte
On 2010-09-17, at 06:28, W.C.A. Wijngaards wrote:
> * The URL that iana published in their description is:
> https://data.iana.org/root-anchors/root-anchors.xml
> * 'widely available trust certificates' to verify the https
We also specified
- http:// URLs (no "s")
- detached OpenPGP signatur
FYI
Begin forwarded message:
> From: internet-dra...@ietf.org
> Date: 29 September 2010 12:45:03 GMT
> To: i-d-annou...@ietf.org
> Subject: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt
> Reply-To: internet-dra...@ietf.org
> list-id: Internet Draft Announcements only
>
> A New Internet-Dr
On 2010-09-29, at 13:07, Brian Smith wrote:
> I'm looking for an installation that will use multiple resolvers. What I
> would like to do is to use 1 server that will be the shared cache for all of
> the resolvers to share. Theoretically this will reduce the amount of traffic
> going out of th
On 2010-09-29, at 16:04, David Conrad wrote:
> Useful draft. A couple of comments/questions:
>
> In section 2.1:
>
> "The document contains a complete set of
> trust anchors for the root zone, including anchors suitable for
> immediate use and also historical data."
>
> This strikes me as
Hi George,
On 2010-09-30, at 06:45, George Barwood wrote:
> Not directly related to this draft ( it's probably out of scope ), but is
> there any guidance on the timing of rollover of the Trust Anchor for the Root
> Zone?
We have issued no guidance for this to date beyond
(a) in an emergency,
Hi Alfred,
On 2010-09-30, at 09:29, Alfred HÎnes wrote:
> I've taken a look at draft-jabley-dnssec-trust-anchor-00
> and have a couple of comments -- mostly editorial in nature.
Many thanks for the review. I have made changes based on your editorial
observations, and my co-author is working on
On 2010-09-30, at 16:51, Stephan Lagerholm wrote:
> It is not clear if the validUntil time is referring to the time when the
> key is expected to be rolled into RFC 5011 revoked state or when it is
> expected to be removed from the zone.
I see what you mean.
> What will happen with the keytag f
On 2010-09-30, at 18:42, Tony Finch wrote:
> I think it was a mistake to drop the trust anchor history draft, because
> it has a reaasonably coherent answer to the problem. I think the arguments
> that it is not secure enough are misguided. What we want is a way for
> software to bootstrap its DN
On 2010-09-30, at 19:23, Paul Hoffman wrote:
> At 7:42 PM +0100 9/30/10, Tony Finch wrote:
>> At the moment the trust anchors are the ICANN x.509 self-signed
>> certificate and/or the PGP keyring. What are the processes for rolling
>> over these keys? How should manufacturers of software or hardw
On 2010-10-01, at 06:58, Tony Finch wrote:
> What is the purpose of the historical information in the XML TA file?
Debugging, context, historical record.
Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On 2010-10-03, at 07:59, Tony Finch wrote:
> On 3 Oct 2010, at 08:27, Jakob Schlyter wrote:
>> On 1 okt 2010, at 20.59, Tony Finch wrote:
>>>
>>> Right, so it's aimed at human consumption rather than automatic tools?
>>
>> Given the historical information (together with old DNSKEY), you could
On 2010-10-03, at 12:32, Eric Rescorla wrote:
> Why?
Are you asking because you've reviewed those discussions and have issues with
them, or because you didn't review those discussions?
I'm not entirely sure the answer shouldn't be "because we manage the keys, and
we say so" actually.
Joe
__
On 2010-10-03, at 13:31, Eric Rescorla wrote:
> I'm asking because I'm pretty familiar with cryptography and I know that keys
> don't suddenly become
> worthless just because they get past their intended use lifetime. The
> semantics of signature
> security of old keys is a lot more complicated
Hi,
On 2010-10-04, at 10:31, Eric Rescorla wrote:
> On Sun, Oct 3, 2010 at 10:54 AM, Joe Abley wrote:
>
>> On 2010-10-03, at 13:31, Eric Rescorla wrote:
>>
>> > I'm asking because I'm pretty familiar with cryptography and I know that
>> >
On 2010-10-04, at 11:11, Eric Rescorla wrote:
> Carefully specified, perhaps, but what you're saying here also makes me think
> it was
> also incorrectly specified, since, as I said, the technique I described is
> well-known,
> and failing to do so leads to precisely the complications that ar
On 2010-10-04, at 11:24, bmann...@vacation.karoshi.com wrote:
>>> So, rather than designing a bunch of kludgy workarounds, it would be better
>>> to ask
>>> what the right thing to do is, even if that requires changing some
>>> preexisting
>>> document.
>>
>> Workarounds to what?
>>
>> I have
On 2010-10-04, at 11:18, Tony Finch wrote:
> It isn't immediately clear to me from the root KSK DPS whether you expect
> RFC 5011 to work in the event of a compromise.
>
> [...]
We seem once again to be moving from the subject at hand to a review and
discussion of the KSK DPS. I would prefer t
On 2010-10-04, at 11:33, Tony Finch wrote:
> On Mon, 4 Oct 2010, Joe Abley wrote:
>>
>> I have not heard a clear description of a problem yet
>
> How can a system that missed a TA rollover bootstrap its DNSSEC validator?
The same way that it bootstraps itse
On 2010-10-04, at 12:56, Tony Finch wrote:
> On Mon, 4 Oct 2010, Jakob Schlyter wrote:
>>
>> Depending on the type of compromise, a RFC 5011 may not be appropriate.
>
> RFC 5011 allows for smooth operation across compromise or loss of the
> active KSK, or compromise or loss of the backup KSK. O
On 2010-10-04, at 12:53, Tony Finch wrote:
> On Mon, 4 Oct 2010, Joe Abley wrote:
>> On 2010-10-04, at 11:33, Tony Finch wrote:
>>> On Mon, 4 Oct 2010, Joe Abley wrote:
>>>>
>>>> I have not heard a clear description of a problem yet
>>>
>&
On 2010-10-04, at 13:41, Tony Finch wrote:
> On Mon, 4 Oct 2010, Jakob Schlyter wrote:
>>
>> RFC 5011 is not very useful if the active KSK is rendered in-operational
>> ("lost")
>
> Er, yes it is. You have a pre-published standby SEP key
No. We don't.
Joe
___
On 2010-10-04, at 14:13, Tony Finch wrote:
> One thing that is missing is any description of the kind of load you
> expect the service to bear. Would it be OK if a vendor sold millions of
> DSL modems that hit data.iana.org every time they recovered from a power
> loss?
This, to me, is an operat
Hi all,
[sending separately to dnsext and to dnsop, apologies for duplicates]
http://www.ietf.org/id/draft-liman-tld-names-04.txt
is the latest iteration of an effort started quite some time ago to clarify the
somewhat vague inference in RFC 1123 and create a more precise specification
for the
On 2010-11-21, at 22:53, Doug Barton wrote:
> On 11/17/2010 01:19, Stephane Bortzmeyer wrote:
> | On Thu, Nov 11, 2010 at 01:42:24PM -0500,
> | Joe Abley wrote
> | a message of 15 lines which said:
> |
> |> http://www.ietf.org/id/draft-liman-tld-names-04.txt
&g
Hi Jim,
On 2010-11-21, at 17:56, Jim Reid wrote:
> On 21 Nov 2010, at 22:20, Patrik Fältström wrote:
>
>> Noone is asking strong enough to get correct data from the whois service.
>> Instead, ICANN is asking to have the whois protocol available, and on top of
>> that money is spent on anonymou
On 2010-11-23, at 17:44, Doug Barton wrote:
> I don't think you can mix those 2 terms in the same sentence. :)
Just so I understand the context for your comments, you're saying that in your
opinion:
1. there is no restriction to be inferred from RFC 1123 that TLD labels be
alphabetic;
2. it
On 2010-11-23, at 20:26, Doug Barton wrote:
> On 11/23/2010 16:19, Joe Abley wrote:
>>
>> 1. there is no restriction to be inferred from RFC 1123 that TLD
>> labels be alphabetic;
>
> Unqualified "yes" to this.
I presume you appreciate that not everybody s
On 2010-11-26, at 11:53, Tony Finch wrote:
> Some implementers may have understood the above phrase "will be
> alphabetic" to be a protocol restriction. This is incorrect. It is in fact
> a description of the TLD allocation policy at that time.
What's your basis for this assertion?
We (authors
On 2010-11-27, at 13:02, Tony Finch wrote:
> On 27 Nov 2010, at 15:57, Joe Abley wrote:
>>
>> I don't know how to defend an assertion in absolute terms that this
>> understanding is categorically wrong. How would you do it?
>
> As I have said before, RFC 11
Hi Alfred,
On 2010-12-01, at 08:06, Alfred HÎnes wrote:
> It is now going to be two weeks since the IANA ITAR has been
> factually decommissioned, but still the last entry that has
> been removed from the ITAR, the DS record for the ARPA. zone,
> has not been placed into the root zone -- as confi
On 2010-12-01, at 10:40, Joe Abley wrote:
> I appreciate that there is eagerness amongst the technical community to see a
> DS record in the root zone. Operationally, we are ready. I have no
> information on the expected time at which the root zone change processing for
> ARPA
Hi all,
A DS RRSet for ARPA was published in the root zone a few minutes ago, details
below.
Joe
Begin forwarded message:
> From: jab...@monster.hopcount.ca (Cron Daemon)
> Date: 6 December, 2010 18:40:01 EST
> To: jab...@monster.hopcount.ca
> Subject: Cron
> ${HOME}/work/watching-root-zone
On 2011-01-09, at 16:40, Zheng Wang wrote:
> I have a question on the ICANN's processing time of the regular DS RR rollover
> request from TLD operators.
>
> I find in ICANN's document saying that "the emergency change process will be
> completed and reflected in the root zone within 48 hours f
facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32
On 2011-01-18, at 10:17, Florian Weimer wrote:
> * Joe Abley:
>
>> I don't think special-use names are a concept of the DNS in the
>> protocol sense, but rather a set of administrative conventions.
>
> LOCAL. is very much protocol-enshrined, but I think it has be
e:
> From: IETF I-D Submission Tool
> Date: 31 January 2011 14:24:56 EST
> To: Joe Abley
> Cc: Dave Knight
> Subject: New Version Notification for
> draft-jabley-dnsop-validator-bootstrap-00
>
>
> A new version of I-D, draft-jabley-dnsop-validator-bootstrap-00.txt has
[we should probably choose either dnsop or dnsext for this, and stop posting to
both, sorry for starting that trend]
On 2011-01-31, at 16:44, John Bashinski wrote:
> On 2011-01-31 14:32, Joe Abley wrote:
>
>> Individual trust anchors are also packaged as X.509 identity
>> ce
On 2011-01-31, at 15:26, Ted Lemon wrote:
> On Jan 31, 2011, at 2:32 PM, Joe Abley wrote:
>> It's scrappy, and it's little more than I have said on this list in the past
>> week, but I thought it might be handy to have in written form.
>
> I'm not entirely s
On 2011-04-18, at 15:01, George Barwood wrote:
> I have a few comments.
>
> (1) It's my belief that almost all Zones except for the root zone should NOT
> use a KSK/ZSK split.
In practice, for a TLD zone operator, rolling a KSK is a more complicated and
time-consuming process than rolling a Z
On 2011-04-20, at 17:50, George Barwood wrote:
> The arguments for operating with a split still seem very weak to me.
Since you're proposing a SHOULD NOT, I think the pertinent point is (a) whether
it does any harm, and (b) whether it is useful in some circumstances.
I have seen no discussion
Hi all,
I've been poking about a bit in other signed zones looking for impending
signature expirations. I've been doing this mainly because we sign a lot of
zones and have had at least one accident in the past, but this also seems like
something that is worth knowing if you're the operator of a
On 2011-06-02, at 13:17, João Damas wrote:
> at first glance it might look useful, but this is the kind of info that tends
> to go stale and then what do you do when there is a mismatch?
I guess you flag it for manual investigation. The alternative is that you don't
really know when a situatio
On 2011-07-08, at 14:03, Stephen Morris wrote:
> If the answer is yes, then the CDS approach is certainly one to be
> looked at. The answer also suggests that we should be looking at an
> equivalent mechanism for updating NS (and possibly glue) information in
> the parent zone. Perhaps all can
On 2011-07-08, at 18:23, Olafur Gudmundsson wrote:
> Just let Whois die a peaceful death, it serves no purpose other than make
> work.
Other people are working on the death of whois; I was just trying to clarify
the type of data I was talking about.
Joe
_
On 2011-07-14, at 12:02, Peter Koch wrote:
> With the trilogy published, there is new work in front of us. Stephen and
> me have reserved space on the Quebec agenda for a closer look at
>
>
So, it seems to me that there are various aspects to consider in the general
area of extending
On 2011-09-27, at 10:09, Edward Lewis wrote:
> A noble idea, but alas not terribly useful.
Not very useful for Neustar, maybe, but I would suggest that your requirements
in this regard are likely not to be universal.
We respond honestly to queries for HOSTNAME.BIND, VERSION.BIND, ID.SERVER,
V
On 2011-09-27, at 14:21, Edward Lewis wrote:
>> We respond honestly to queries for HOSTNAME.BIND, VERSION.BIND, ID.SERVER,
>> VERSION.SERVER as well as RFC5001/NSID on L-Root, for example.
>
> It's not a matter of honesty.
No inference intended; what I meant was we let the software report its a
Hi Bill,
On 2012-02-06, at 14:12,
wrote:
> Thanks to Warren, Ed, John D., David C. and Kato-san for their
> comments/corrections.
> Any more?
I see you added some text based on our conversation in sunny Christchurch,
thanks for that. As promised, here's a summary of that conversation for t
On 2012-02-27, at 19:49, Paul Vixie wrote:
> 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.
>>
On 2012-04-04, at 08:20, 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
On 2012-04-04, at 11:31, Tony Finch wrote:
> I think BIND treats NXDOMAIN replies with the wrong authority as a
> FORMERR. Domainers are returning positive replies which BIND does not
> subject to a SOA sanity check.
monster.hopcount.ca is serving the fake (empty apart from apex SOA/NS and glue)
On 2012-04-11, at 12:09, Wes Hardaker wrote:
>> On Wed, 11 Apr 2012 06:28:49 -0700, Nicholas Weaver
>> said:
>
> NW> a) If end-time is specified as a date, not an interval, you can set
> NW> the date to be 'end of epoch', so you can basically have it 'stay
> NW> forever', even if thats
Dr Lisse,
On 2012-04-11, at 13:45, Dr Eberhard Lisse wrote:
> on 2012-04-11 17:56 Joe Abley said the following:
> [...]
>> ; example.com's DNSSEC is broken, let's not use it for a day
>> example.com NTA 20120412162716 20120411162716 "ticket [HOPCOUNT-12345]
>
Patrik,
Nobody is talking about creating NTAs. NTAs already exist. The question for
this group is whether or not they are worth standardising.
Joe
Sent from my Ono-Sendai Cyberspace 7
On 2012-04-15, at 2:34, "Patrik Fältström" wrote:
> On 15 apr 2012, at 03:23, Warren Kumari wrote:
>
>> On
On 2012-04-15, at 20:02, Scott Schmit wrote:
> On Fri, Apr 13, 2012 at 04:38:10PM -0700, David Conrad wrote:
>> On Apr 13, 2012, at 3:30 PM, Jaap Akkerhuis wrote:
More pragmatically, while I understand the theory behind rejecting NTAs,
I have to admit it feels a bit like the IETF reject
On 2012-04-18, at 14:53, "Jim Reid" wrote:
> On 18 Apr 2012, at 19:28, David Conrad wrote:
>
>> If you don't like the policy of your validator operator, change to a
>> validator operator whose policy you agree with (or, better yet, run
>> your own validator -- it is the only way to be sure).
On 2012-06-01, at 21:04, "SM" wrote:
> The authors of draft-ietf-dnsop-dnssec-dps-framework-07 have stated that:
>
> "This Internet-Draft is submitted in full conformance with the
>provisions of BCP 78 and BCP 79."
>
> It is simply a matter of asking them an appropriate question. :-) I
On 2012-06-05, at 08:28, Gilles Massen wrote:
> One set of root servers fills the additional section with 2 names, and
> their v4 and v6 addresses. But it's always the same two servers,
> indepently of the server asked. The other set answers with a bit more
> servers, but only v4 adresses, and he
Hi Nicholas,
On 2012-06-12, at 10:58, Nicholas Weaver wrote:
> On Jun 12, 2012, at 7:40 AM, Warren Kumari wrote:
>
>> So, back in (AFAIR) Taipei I proposed making AS112 instances simply be
>> authoritative for *everything*, and then simply delegating and undelegating
>> things to it as appropr
Hi all,
The only suggestion I have heard relating to this draft is that if we supplied
custom software to synthesise answers we could avoid the overly-broad SOA RR
returned with the NXDOMAIN.
(My personal opinion is that this leads us down a path of needing to develop,
publish and support part
Hi Mark,
On 2012-06-27, at 20:01, Mark Andrews wrote:
> I personally think a vendor education campain would be more productive.
> We can't do much about already deployed servers but we can make
> sure the next major release supports RFC 6303 by default.
I'm not sure we can influence the next maj
On 2012-07-11, at 11:09, Chris Thompson wrote:
> [That's not to say that any differences between the two NS RRsets is ever
> desirable, except as may be necessary or expedient during a change.]
That's a good rule of thumb, but so long as the union of the delegation and
apex NS sets contains no
On 2012-07-14, at 16:50, Doug Barton wrote:
> I would argue further that a child NS set which is a superset of the
> parent is not lame, or broken. There are valid reasons to do this,
> (outside the scope of this document, certainly) and I'd hate to see this
> instantiated as "an RFC violation" a
On 2012-07-14, at 17:35, Doug Barton wrote:
>> Any new work which needed to assert that both sets were the same
>> would meet with little objection though, I think.
>
> It's already met with at least 2 objections, so I'm pretty sure you're
> wrong. :)
Well, my note wasn't an objection and yours
On 2012-07-16, at 10:53, Paul Hoffman wrote:
> The use cases in section 3 are fine because they are use cases for
> standardized things. Patrik's objections were (all?) about the "use cases" in
> section 4, which in fact are business models, some of which exist today and
> others which do not.
On 2012-07-24, at 07:53, Matthijs Mekking wrote:
> As you might know, I had this idea of unraveling key states. Instead
> of having states that describe the overall state of the key, we would
> have states for components of the key. How to divide the key into
> components is based on the parts th
On 2012-07-24, at 12:25, Edward Lewis wrote:
> At 17:05 -0400 7/14/12, Joe Abley wrote:
>
>> Any new work which needed to assert that both sets were the same would
>> meet with little objection though, I think.
>
> I disagree.
>
> I would object to any strengthe
On 2012-08-30, at 13:11, Paul Hoffman wrote:
> On Aug 30, 2012, at 9:45 AM, Paul Vixie wrote:
>
>> On 2012-08-30 9:40 AM, Johan Ihrén wrote:
>>> Not to question the abilities of the WG, but I still have to ask whether
>>> (in your opinion) the operations community would be better off with a
On 2012-10-09, at 21:56, Mark Andrews wrote:
> Please review draft-andrews-dnsop-rfc6598-rfc6303
OK!
The idea is good. Reverse queries for addresses in 100.64.0.0/10 have been
observed in the wild. I agree that this document should proceed.
RFC 6303 did not specify the requirements for
On 2012-10-10, at 08:23, "William F. Maton Sotomayor" wrote:
>
>> Please review draft-andrews-dnsop-rfc6598-rfc6303
>
> I've read this draft and would support it, in lieu of the omniscient-
> darft should that not proceed any further.
I don't understand the logic in the sentence above.
On 2012-10-12, at 11:20, Joseph Gersch wrote:
> We had posted an updated draft on the reverse-DNS naming convention for CIDR
> address blocks and asked to discuss this at the Atlanta meeting. Did you
> miss this request?
I didn't actually reply, but there are some aspects of trust anchor pub
Hi Lee,
Some comments below, based on a fairly cursory skim through (so, I may well
have missed and/or understood things).
2.2 Wildcard match
There is no mention of the issue of uniqueness. What do you do when you have
five thousand different customers who all attempt secure dynamic updates wi
On 2012-11-22, at 18:10, Mark Andrews wrote:
> Individual hosts should be doing dynamic DNS. Where that update
> is sent to may change but all machines should be doing it and should
> support TSIG as a minimum.
The missing pieces here include:
- what sane ISP/campus/home network/hotspot oper
On 2012-11-23, at 06:28, Tony Finch wrote:
> Joe Abley wrote:
>
>> I think you skipped a step -- you need to find the zone cut before you
>> can find the nameservers responsible for the zone. I guess I do that by
>> asking for blah.ip6.arpa/IN/SOA and checking th
On 2013-02-16, at 18:04, Ted Lemon wrote:
> I would suggest that the right solution is to rely on the DNSSEC security
> infrastructure to publish negative trust anchors, rather than relying on
> RFC5280. I realize that this means more work, probably for DNSEXT, the
> chairs of which were ho
On 2013-02-17, at 09:57, "Livingood, Jason"
wrote:
> A Negative Trust Anchor should IMO be locally configured and not rely upon
> any external validation or sourcing for the Negative Trust Anchor(s).
I hear you, but I'm not sure why you think so.
If I was running a farm of validators inside a
On 2013-02-17, at 10:37, "Livingood, Jason"
wrote:
> Makes sense to me. So if I added very explicit text to the effect that
> "Negative Trust Anchors MUST NOT be used by host-based DNSSEC validating
> DNS resolvers; this practice only pertains to network-based DNS recursive
> resolvers that mul
On 2013-02-17, at 10:48, Ted Lemon wrote:
> On Feb 17, 2013, at 10:35 AM, Joe Abley wrote:
>> - hopcount.ca's signer explodes (or something else happens such that
>> hopcount.ca is badly signed)
>> - since hopcount.ca is such a popular domain for Comcast customers,
On 2013-02-17, at 21:59, Ralf Weber wrote:
> That sounds like a negative DLV to me. I think DLV was a bad idea and I don't
> think this is a good idea either when you are crossing organization
> boundaries. I guess it is ok when used inside a provider as mechanism to
> distribute NTA, but the
Hi Ralf,
On 2013-02-17, at 22:19, Ralf Weber wrote:
> I fully agree on this, which is why I support this draft. However to achieve
> that goal (making it easier for ISPs to implement DNSSEC) I don't think it is
> necessary to specify how NTA will be distributed. If you think it is
> important
On 2013-02-20, at 14:50, Richard Lamb wrote:
> FWIW: The -04 draft looks good. It is clear and well written and I think it
> is a valuable resource.
> As I am late to looking at this draft please take this only as a comment from
> a narrow minded engineer ;-) After the rationale, explanati
On 2013-02-22, at 01:47, Mark Andrews wrote:
> In message , George
> Michaels
> on writes:
>
>> On 21/02/2013, at 6:46 AM, Mark Andrews wrote:
>>
>>> * it changes the response from NXDOMAIN to NOERROR NODATA.
>>
>> And why is that "wrong" ? I dont understand what you see as the outcomes.
>
On 2013-02-22, at 07:57, Paul Vixie wrote:
> 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.
It does smell a bit wr
On 2013-02-22, at 09:39, Mark Andrews wrote:
> I can well imagine a machine doing a reverse lookup on a proposed
> address and not proceeding with that address if it doesn't get a
> NXDOMAIN.
>
> NODATA -> unsafe
> NXDOMAIN -> may be safe
So, out of interest, do you think it's legi
On 2013-02-22, at 10:42, Nick Hilliard wrote:
> I agree we should be cautious. So why not run it on some as112 servers on
> a pilot basis and see what happens? Full logging would be required, as
> well as some idea of what sort of problems to look for (e.g. multiple
> repeated queries from the
On 2013-02-22, at 12:33, "Dickson, Brian" wrote:
> One question/caveat:
>
> What would the practical impact be, if the TTL on the SOA were the same as
> the default negative caching TTL (for the NXDOMAIN)?
The longevity of the negative answer in the cache is defined as min(SOA TTL,
SOA MINIMU
Hi Paul,
That was our starting point; however, it turned out that resolvers wouldn't
cache the name error, I think because the SOA returned with the name error
in the authority section was clearly bogus (i.e. conflicted with the root
zone SOA presumably already cached by the resolver client).
I t
601 - 700 of 884 matches
Mail list logo
