t? Is there any doubt at all or any
ambiguity in what we want said? ... Paul
Joe Abley wrote:
>
>
> 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 most recent decision that I saw from the chairs was that it should
not be adopted. I do not agree that that is the best path forward.
Aue Te Ariki! He toki ki roto taku mahuna!
On 2013-02-24, at 13:15, SM wrote:
> At 11:27 22-02-2013, Warren Kumari wrote:
>> If the WG consensus is NXDOMAIN,
On 2013-03-04, at 05:39, Antoin Verschuren wrote:
> Op 01-03-13 16:50, Olafur Gudmundsson schreef:
>
> > One CDS's goals is to get the "Parent" out of the habit of
> > calculating hash, just publish what the Child wants.
>
> I strongly disagree on this.
> I don't think CDS goal should be to m
Hi Antoin,
On 2013-03-04, at 09:44, Antoin Verschuren wrote:
> Op 04-03-13 14:22, Joe Abley schreef:
>
> > Contrarily, I don't think the goal should be for registry policy to
> > dictate what DS records should be acceptable for a child. I think
> > this s
Hi Antoin,
It's clear that we have different opinions on this, and I don't want to argue
for the sake of noisemaking. However, I have a couple of clarifying questions
(see below).
On 2013-03-04, at 11:21, Antoin Verschuren wrote:
> Op 04-03-13 16:02, Joe Abley schreef:
>
On 2013-03-05, at 11:54, Paul Hoffman wrote:
> On Mar 5, 2013, at 8:44 AM, Paul Wouters wrote:
>
>> That said, I'm still with the authors. Keep the CDS format identical to
>> the DS format. (and let parent and child local policy determine what to
>> do with the CDS RRset)
>
> Seeing that at l
On 2013-03-05, at 12:09, Paul Hoffman wrote:
> On Mar 5, 2013, at 9:05 AM, Joe Abley wrote:
>
>> I presume this has already come up, and there are good reasons why the
>> apparent lexical flexibility in what I'm about to suggest are swamped by a
>> sea of vicio
On 2013-03-05, at 15:01, Paul Wouters wrote:
> On Tue, 5 Mar 2013, Joe Abley wrote:
>
>> I presume this has already come up, and there are good reasons why the
>> apparent lexical flexibility in what I'm about to suggest are swamped by a
>> sea of vicio
On 2013-03-05, at 15:18, Paul Wouters wrote:
> On Tue, 5 Mar 2013, Joe Abley wrote:
>
>> Every new RR is a zone syntax change.
>
> Not true. I am still running generic record syntax in some opendnssec
> signers because those systems don't know all ne
Hi all,
The following public comment period opened today:
http://www.icann.org/en/news/public-comment/root-zone-consultation-08mar13-en.htm
Your responses to the questions presented above would be most welcome. Please
feel very free to pass on the link to anybody you think might be intereste
1. Because not all parents (by policy) construct DS records on behalf
of children;
2. Because sometimes you want to publish DS RRs in your parent that
correspond to standby keys that are not published in the child.
Aue Te Ariki! He toki ki roto taku mahuna!
On 2013-03-13, at 3:00, Doug Barton w
On 2013-03-13, at 12:26, Doug Barton wrote:
> On 03/13/2013 07:45 AM, Joe Abley wrote:
>> 1. Because not all parents (by policy) construct DS records on behalf
>> of children;
>
> So how likely are those parents to utilize CDS records to auto-publish DS?
> Or, put mor
On 2013-03-13, at 12:54, Doug Barton wrote:
> On 03/13/2013 09:39 AM, Joe Abley wrote:
>
>> However, there's nothing to stop registrars making
>> arrangements with their registrants to receive change requests via
>> signed RRSets. It may that for gTLDs (and other T
On 2013-03-13, at 13:05, Paul Wouters wrote:
> If a TLD contract does not allow registrant-registry contact directly,
> then that prevents child-parent interaction,
No, it just prevents direct child-parent interaction.
> and so nothing we specify
> here can be used.
There's nothing to stop a
On 2013-03-13, at 13:17, Doug Barton wrote:
> In order to really make this work a non-trivial number of TLD registries
> (which have a variety of different rules and policies) AND registrars would
> have to be on board.
No. Where there are registrars involved, you just need a registrar that c
On 2013-03-13, at 13:34, Doug Barton wrote:
> On 03/13/2013 10:20 AM, Joe Abley wrote:
>>
>> On 2013-03-13, at 13:17, Doug Barton wrote:
>>
>>> In order to really make this work a non-trivial number of TLD
>>> registries (which have a variety o
On 2013-03-13, at 16:27, Doug Barton wrote:
> On 03/13/2013 12:53 PM, Joe Abley wrote:
>
>> Doug, I don't understand your concern.
>>
>> You insisted earlier that for gTLDs, we would need support by all TLD
>> registries and all registrars.
>
> I did
On 2013-02-22, at 15:14, "Dickson, Brian" wrote:
> Instead of delegating to omniscient AS112 servers, what about doing a
> DNAME to a specific target "foo" (replace "foo" with what you will) in the
> DNS tree?
I've thought about this a bit, and I've decided that I quite like it.
So, if I can p
On 2013-03-14, at 18:52, George Michaelson wrote:
> how many of the deployed resolvers can understand DNAME
Good question, it would interesting to design an experiment to measure that.
> and whats the outcome for dns lookups where the intermediate systems dont
> understand DNAME.
CNAME synth
On 2013-03-15, at 14:34, Steve Crocker wrote:
> It feels like there are two distinct issues here. If the signatures expire,
> all copies of those records will be affected, so diversity of name servers
> won't help.
My assumption was that this was a reference to the "signatures expired becaus
ions)
Thanks,
Joe
Begin forwarded message:
> From: "internet-dra...@ietf.org"
> Subject: New Version Notification for
> draft-jabley-dnsop-anycast-mapping-00.txt
> Date: 25 March 2013 15:29:43 EDT
> To: Joe Abley
>
>
> A new version of I-D, draft-jable
Hi all,
As advised a month or so ago, the following public comment period is open:
http://www.icann.org/en/news/public-comment/root-zone-consultation-08mar13-en.htm
We have received a small number of responses which are accessible from that
page.
The topic at hand and the specific questions
On 2013-04-03, at 11:00, Paul Hoffman wrote:
> On Apr 3, 2013, at 7:11 AM, Joe Abley wrote:
>
>> We have received a small number of responses which are accessible from that
>> page.
>
> Maybe that should be a strong indication of how little people care about this?
On 2013-04-03, at 11:11, Paul Wouters wrote:
> I'd say addressing that problem should be done before rolling the root
> key.
It would be great to hear such opinions expressed as part of the public comment
process, so that they can be used to identify the approach that will be
followed.
Joe
On 2013-04-03, at 11:20, Stephane Bortzmeyer wrote:
> On Wed, Apr 03, 2013 at 11:14:24AM -0400,
> Joe Abley wrote
> a message of 14 lines which said:
>
>> It would be great to hear such opinions expressed as part of the
>> public comment process,
>
> Is ther
On 2013-04-04, at 15:45, Jim Reid wrote:
> On 3 Apr 2013, at 16:11, Paul Wouters wrote:
>
>> It's the vendors of equipment supporting DNSSEC that have
>> the real issues. If they shipped with a root anchor, and their stuff
>> is offline for 5 years and turned on, their DNS will be broken and 5
On 2013-04-04, at 16:23, Nicholas Weaver wrote:
>
> On Apr 4, 2013, at 1:19 PM, Paul Hoffman wrote:
>>> I think nothing is needed here except perhaps a statement of the bleeding
>>> obvious: "if you miss too many key rollovers, Very Bad Things will happen
>>> so make sure you have a foolproo
On 2013-04-04, at 16:19, Paul Hoffman wrote:
>> eg Have some out of band means of fetching and verifying the current version
>> of the One True Trust Anchor.
>
> And has the IETF supplied anything like that? If not, should ICANN wait for
> the first roll until we have?
ICANN has published do
On 2013-04-04, at 16:35, Mark Andrews wrote:
> Validators need to have end dates for DNSKEYS. If it starts up
> after that date it goes to all insecure.
http://tools.ietf.org/html/draft-jabley-dnsop-validator-bootstrap-00
was a first attempt to describe how a validator should bootstrap itself
On 2013-04-04, at 17:00, Paul Hoffman wrote:
> You must have misread the verb tense in my message. :-) "has supplied" is
> quite different than "efforts is ongoing".
Well, what we have is a design that was put together by ICANN, Verisign and
NTIA (the three organisations that maintain and pub
On 2013-04-06, at 16:55, Tony Finch wrote:
> On 3 Apr 2013, at 17:38, Evan Hunt wrote:
>>
>> Then there's the issue Paul mentioned -- gear configured with a root KSK
>> that gets switched off and not rebooted for a few months or years, and then
>> no longer works and can't recover.
>
> Validator
in developing this
approach, but we remain interested.
Joe
Aue Te Ariki! He toki ki roto taku mahuna!
On 2013-04-06, at 17:22, Tony Finch wrote:
> On 6 Apr 2013, at 10:04, Joe Abley wrote:
>> On 2013-04-06, at 16:55, Tony Finch wrote:
>>>
>>> Validator vendors hav
On 2013-04-12, at 10:54, Stephane Bortzmeyer wrote:
> On Mon, Mar 25, 2013 at 03:40:55PM -0400,
> Joe Abley wrote
> a message of 66 lines which said:
>
>> However, I am of course interested in accuracy and clarity in the
>> text. If you have a few spare minutes an
Hi Ed,
On 2013-04-15, at 13:14, Edward Lewis wrote:
> I have no problem with this in spirit. But I always wonder why the
> presentation formats, as in section 3.2 and 4.2, have MUST concerning how the
> record is "written." I've never considered the presentation format to be
> subject to a
On 2013-04-15, at 14:08, Edward Lewis wrote:
> On Apr 15, 2013, at 13:32, Joe Abley wrote:
>
>> I think a SHOULD is too weak though. I spend a lot of time parsing the
>> output from tools that decode DNS messages, and if different tools used
>> different presentat
On 2013-04-18, at 18:15, Wes Hardaker wrote:
> CDS is at least a decent middle ground that offers a middle point in the
> balance equation. It provides a decent point where security and
> operational practice might be at the top of the tradeoff bubble. And,
> that's why we have operational and
On 2013-04-18, at 20:35, Paul Vixie wrote:
> Joe Abley wrote:
>
>> There's no protocol meaning at present for an apex DS RRSet, which means it
>> ought to be harmless to add one. A parent (or the parent's agent) could
>> decide to act upon the presence
On 2013-04-19, at 10:14, Tony Finch wrote:
> Joe Abley wrote:
>
>> ... except that the clients that would use the apex DS RRSet are
>> special, in that they know precisely what servers to query.
>
> That isn't enough to disambiguate which DS is being asked fo
On 2013-04-19, at 11:21, Wes Hardaker wrote:
> Joe Abley writes:
>
>> By this thinking, a signed apex DS RRSet with the meaning discussed
>> for CDS could be deployed today, with no need for code point
>> assignment. What am I missing?
>
> Besides the othe
On 2013-04-19, at 11:33, Paul Wouters wrote:
> On Fri, 19 Apr 2013, Joe Abley wrote:
>
>>> Besides the other two comments: DS records are signed with the ZSK, and
>>> the CDS document explains why it needs to be signed with the KSK instead
>>> (also).
>>
On 2013-04-20, at 12:09, Paul Wouters wrote:
> There is currently one publisher (ICANN pem bundle plus static web page
> with certs signed by particular CA). Will that page be there in 10 years?
> Where will the other publications be?
The pragmatic answer to this is that ICANN is under contract
On 2013-04-22, at 17:17, Wes Hardaker wrote:
> Wes Hardaker writes:
>
>> For what it's worth: I'm sort of on the fence when it comes to needing
>> to sign with the KSK. There are so very very few key-split owners out
>> there that it's not a huge market for them, and I doubt any of them will
Hi Wes,
On 2013-04-24, at 09:18, Wes Hardaker wrote:
> I
> think part of the problem has been we don't have a good list of
> requirements to compare any given solution to and we're talking around
> them all because they're not written down (at least in one place).
I like your list. I think it's
On 2013-04-25, at 14:14, P Vixie wrote:
> Let's not burn a type code just to keep CDS separate.
Note that the type code for CDS has already been assigned, see:
http://www.iana.org/assignments/dns-parameters/dns-parameters.xml
(it's 59)
Joe
___
DNS
27;ll
forward) that'd be great.
Thanks,
Joe
Begin forwarded message:
> From: "internet-dra...@ietf.org"
> Subject: New Version Notification for
> draft-jabley-dnsop-anycast-mapping-02.txt
> Date: 24 June 2013 12:22:42 EDT
> To: Joe Abley
>
>
> A ne
On 2013-06-24, at 12:56, Paul Hoffman wrote:
> In looking at the diffs, I still have the question I had earlier about NSID.
> I give the following command three times quickly:
> dig -4 @L.ROOT-SERVERS.NET . SOA +nsid +norec +noall +comments
> I get three different answers (lax16..., lax09...,
On 2013-06-24, at 13:23, Paul Hoffman wrote:
> Ah, got it. I missed the linkage of "add NSID to the troublesome query".
> Proposal:
> Current:
> Use of the NSID option can obviate this possibility
> Proposed:
> Adding the NSID option to the query that causes the problematic response can
> obvi
On 2013-06-21, at 11:25, Warren Kumari wrote:
> Things that requite more discussions:
> 1: Is DNAME a viable alternative?
I think it is. I found Brian Dickson's suggestion on this list quite
compelling. Some experimentation is likely required to characterise the impact
of that approach with a
ietf.org"
> Subject: New Version Notification for draft-jabley-dnsop-dns-flush-00.txt
> Date: 24 June 2013 15:16:29 EDT
> To: Joe Abley
>
>
> A new version of I-D, draft-jabley-dnsop-dns-flush-00.txt
> has been successfully submitted by Joe Abley and posted to the
&g
On 2013-06-24, at 17:12, Warren Kumari wrote:
>> I'd be very happy to work with Brian (assuming he's interested; I haven't
>> talked to him) and write this up as a second option.
>
> Great. We could:
> A: replace the current method outlined in
> draft-wkumari-dnsop-omniscient-as112-03 with DN
Hi Guangqing,
On 2013-06-25, at 08:02, "Guangqing Deng" wrote:
> Hi, Joe, I like this draft, though I am puzzled by some questions. First, the
> change of
> the zone content of an authority server does not mean that a corresponding
> recursive server
> has to flush its cache, since a recursi
nodes!
:-)
Joe
Begin forwarded message:
> From: "internet-dra...@ietf.org"
> Subject: New Version Notification for draft-jabley-dnsop-as112-dname-00.txt
> Date: 28 June 2013 18:23:33 EDT
> To: Joe Abley , Brian Dickson
>
>
>
> A new version of I-D, draft-jab
Hi all,
We have two drafts on the table relating to extensions to AS112 service, in
particular to accommodate delegation or redirection of new zones to the
infrastructure:
draft-wkumari-dnsop-omniscient-as112
draft-jabley-dnsop-as112-dname
I suspect that it makes no sense to proceed with b
On 2013-07-01, at 13:45, Warren Kumari wrote:
> In the mean time -- assuming that we test DNAME and find out that:
> A: it is well supported
A.5: the interactions between components are not harmful in the event that
DNAME is not supported (i.e. that CNAME synthesis mitigates the lack of
suppo
On 2013-08-01, at 11:52, Guangqing Deng wrote:
> It seems that the slides of DNSOP WG are still not available on website yet.
> Hope such slides can be posted before meeting time.
As one of the people guilty for not sending slides to the chairs earlier, I
apologise. But Tim has my slides now,
Just saying :-)
Begin forwarded message:
> From: "da...@from525.com"
> Subject: [dns-operations] Request To Clear Cache: NYTimes.com
> Date: 27 August 2013 17:55:19 EDT
> To:
> Reply-To: da...@from525.com
>
> All,
>
> I am a DNS Administrator at NYTimes.com. Earlier today we had issues with
On 2013-09-10, at 17:59, Olafur Gudmundsson wrote:
> [cc'ed to a more approriate IETF wg]
... and I'll gratuitously mention draft-jabley-dnsop-validator-bootstrap here
too, since it addresses exactly this topic.
Joe
___
DNSOP mailing list
DNSOP@i
On 2013-09-11, at 11:43, Phillip Hallam-Baker wrote:
> OK lets consider the trust requirements here.
>
> 1. We only need to know the current time to an accuracy of 1 hour.
[RRSIG expiration times are specified with a granularity of a second, right?
I appreciate that most people are generous w
Hi all,
Nevil Brownlee is graciously considering this document for the
independent-submission stream:
http://tools.ietf.org/html/draft-jabley-dnsop-anycast-mapping-02
It's an informational document that describes the various mechanisms provided
at L-Root to identify what anycast node you see
On 2013-09-25, at 04:33, ice jew wrote:
> I think it's related to the real load balancing strategy of L-root's back end
> nodes.
> Joe more details?
It's always possible for successive queries to be directed at different anycast
nodes. This is described in the text:
4. Identification of L-
cation for draft-jabley-dnsop-as112-dname-01.txt
> Date: 12 October 2013 17:26:28 EDT
> To: George Michaelson , "George G. Michaelson"
> , Joe Abley , Brian Dickson
> , Warren Kumari
>
>
> A new version of I-D, draft-jabley-dnsop-as112-dname-01.txt
> has been suc
On 2013-10-21, at 11:29, Tim Wicinski wrote:
> This starts a Call for Adoption for draft-andrews-dnsop-rfc6598-rfc6303.
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-andrews-dnsop-rfc6598-rfc6303/
>
> Please review this draft to see if you think it is suitable for
On 2013-10-21, at 13:21, Ted Lemon wrote:
> On Oct 21, 2013, at 1:15 PM, joel jaeggli wrote:
>> I don't think there's any likelyhood of them being acepted here. cross-area
>> socialization if appropiate is not a problem imho.
>
> Yup, plus more dns folks will likely be at dnsop than intarea.
On 2013-10-21, at 14:16, Paul Wouters wrote:
> For CPE devices, I think querying for the root key without dnssec to
> use as time and possible TA is something it could possibly prompt the
> user for. It would work without DHCP and not require new DHCP options.
> CPE devices could also insecurely
ersion Notification for draft-ietf-dnsop-as112-dname-00.txt
> Date: 6 November 2013 at 10:58:36 PST
> To: Joe Abley , George G. Michaelson , George
> Michaelson , Warren Kumari , Brian Dickson
>
>
>
> A new version of I-D, draft-ietf-dnsop-as112-dname-00.txt
> has been successfu
On 2013-11-06, at 17:08, Mark Andrews wrote:
> Guess what
> every time the Registrant does a DNS lookup in the Registry zone
> it is talking directly with the Registry.
You're conflating registry services with DNS services. This is a common mistake.
Joe
signature.asc
Description: Message s
Hi John,
On 2013-11-18, at 17:53, John Levine wrote:
>> So, we got some good review and feedback on this from Tony Finch, anyone
>> else?
>
> I read the draft, and as a spec it looks fine to me. Once there are a
> few empty.as112.arpa servers, you can send any branch of the DNS to
> oblivion
On Monday 2 December 2013 at 10:38, Paul Hoffman wrote:
> SLDs under .arpa are cheap and easily managed by the IETF.
Yes.
> Forcing someone into a different class (where all sorts of things could block
> by accident) seems silly.
I don't know that anybody is talking about force. I'm not sure w
On Monday 2 December 2013 at 11:17, Ted Lemon wrote:
> RFC 6761 has IETF consensus, and does not propose adding new namespaces under
> .arpa, but rather at the top level. Here's what RFC3172 says on the topic of
> .arpa:
>
> This domain is termed an "infrastructure domain", as its role is to
On Monday 2 December 2013 at 12:44, Ted Lemon wrote:
> On Dec 2, 2013, at 11:29 AM, Joe Abley (mailto:jab...@hopcount.ca)> wrote:
> > > RFC 6761 has IETF consensus, and does not propose adding new namespaces
> > > under .arpa, but rather at the top level. Here&#x
On Monday 2 December 2013 at 13:13, Ted Lemon wrote:
> On Dec 2, 2013, at 12:58 PM, Joe Abley (mailto:jab...@hopcount.ca)> wrote:
> > > This seems like a non-sequitur, since RFC 5855 refers to a function that
> > > RFC 3172 specifically mentions.
> >
> >
On Wednesday 4 December 2013 at 14:40, Warren Kumari wrote:
> I really like .alt -- it makes it clear that this is an alternate namespace
> type thing, mirrors the usenet alt convention, etc.
> .p2p seems less descriptive, and not all alternate things are peer to peer.
I think it's pertinent t
On Wednesday 4 December 2013 at 15:01, SM wrote:
> At 09:14 04-12-2013, David Conrad wrote:
> > On the minus side, management of .ARPA is a part of the IANA
> > functions contract which implies changes will require US DoC NTIA
> > approval, so I'd agree that there is a potential for delays and
On 2013-12-05, at 07:15, Chris Thompson wrote:
> On Dec 4 2013, Joe Abley wrote:
>
> [...snip...]
>> There was at least one study commissioned by ICANN on the prudence of
>> provisioning DNAME RRs in the root zone that concluded that there was
>> no obvious danger,
Hi Tim,
On 2013-12-07, at 08:59, Tim Wicinski wrote:
> We're kicking off the Working Group Last call on Adding 100.64.0.0/10
> prefixes to IPv4 Locally-Served DNS Zones Registry. The author believe that
> this document has addressed all the issues raised on the document. The
> latest version
On 2013-12-07, at 11:33, Paul Hoffman wrote:
> Alas, this document is definitely not ready for publication as an RFC. It
> still is very unclear which parts are restatements of RFC 6304, which are
> changes, and which are speculative. Appendix B makes an attempt to make this
> clearer, but fa
On 2013-12-07, at 21:09, David Conrad wrote:
> It appears we now have multiple registries listing the same information.
> Specifically:
>
> http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml
>
> seems to be a subset of
>
> http://www.iana.org/assignments
On 2013-12-10, at 12:23, Peter Koch wrote:
> At this time, after 25 IETF meetings, I have informed our AD that I'd
> like to step down from the position of a DNSOP co-chair and hand over
> the responsibility to somebody else to join Tim in chairing the group.
Viel Dank, mein Freund. Ich kaufe d
On 2013-12-31, at 15:06, Christian Grothoff wrote:
> And again, a key question for me is, if you really want to _encourage_
> people to _first_ deploy at large scale and _then_ reserve the name.
You can reserve a name for $10/year, no IETF process required. Less if you
reserve under an existin
Hi there,
On 2014-01-02, at 01:46, Guangqing Deng wrote:
>> If (to take an example at random) Tor users could make use of names outside
>> of the DNS that look like DNS names under a .ONION TLD, why could they not
>> just as easily make use of names that end in ONION.EFF.ORG?
>
> Another fac
On 2014-01-14, at 12:22, Andrew Sullivan wrote:
> For my sins, I have been following some of the recent discussions
> about "Internet governance". One of the discussions over on the
> "1net" list (http://1net-mail.1net.org/mailman/listinfo/discuss) is
> about the control by one particular gover
On 2014-01-14, at 18:04, George Michaelson wrote:
> If multiple independent entities sign, can't they elect to use shorter
> algorithms?
>
> I know 'short can be spoofed' is out there, but since there are now n * <512>
> instead of 1 * 2048 is it not theoretically possible that at a cost of m
On 2014-01-29, at 11:40, Ralf Weber wrote:
> On 29 Jan 2014, at 08:10, Paul Hoffman wrote:
>>> I also don't think there are risks in delegation these other than
>>> the applicants will get lots of traffic.
>>
>> Others disagree. ICANN has documented many scenarios where there are
>> security
On 2014-02-03, at 11:15, Paul Hoffman wrote:
> On Feb 3, 2014, at 7:19 AM, Stephane Bortzmeyer wrote:
>
>> "squatted" is not a bad word here. In the physical world, squatters
>> are often people who do not have the money to rent a home, because
>> some rich people put the price of the housing
On 2014-02-04, at 01:39, John Levine wrote:
> I suppose the situation with .onion is slightly different, but in
> concept it's not all that different from .arpa.
I think it's quite different.
ARPA is really no different from any other TLD. There's a registry, there are
rules you need to follo
On 2014-02-04, at 10:00, Paul Vixie wrote:
> Joe Abley wrote:
>> ...
>>
>> ONION is like LOCAL. Neither are like ARPA (or any other TLD).
>
> How like LOCAL is ONION?
Neither is a zone in the DNS or a domain in the DNS namespace, and both refer
to names for whic
On 2014-02-07, at 13:18, Doug Barton wrote:
> On 02/07/2014 10:14 AM, Warren Kumari wrote:
>
>> We are not allowing zones to go from unsigned to signed:
>
> Right, and because it says not to do it in the RFC no one is going to do it?
> :)
I don't see how it would work. The parental agent has
On 2014-02-07, at 14:22, Warren Kumari wrote:
> On Fri, Feb 7, 2014 at 2:12 PM, Joe Abley wrote:
>
>> On 2014-02-07, at 13:18, Doug Barton wrote:
>>
>>> On 02/07/2014 10:14 AM, Warren Kumari wrote:
>>>
>>>> We are not allowing zones to
On 2014-02-07, at 13:31, Mukund Sivaraman wrote:
> Did you see my reply to your email a few weeks ago where I asked why new
> CDS/CDNSKEY RR types are required instead of adding a new bit to the
> Flags field of the DNSKEY RR. Please can you look for my last email
> which lists some advantages?
On 2014-02-12, at 11:28, Marc Blanchet wrote:
> - I like better that approach than the previous draft registering many tlds.
The previous draft (at least for some of the TLDs) was anchored in the reality
that changing the name already in use was not practical, e.g. there's a
sufficient deploy
Hi Tony,
On 2014-02-13, at 15:56, Tony Finch wrote:
> There was some discussion last month about dispersing trust in the root.
> http://www.ietf.org/mail-archive/web/dnsop/current/msg10977.html
>
> This inspired me to write up a concrete proposal for the
> quorum-of-witnesses idea that I have v
112 Redirection using DNAME
>Authors : Joe Abley
> Brian Dickson
> Warren Kumari
> George Michaelson
> Filename: draft-ietf-dnsop-as112-dname-01.txt
> Pages : 2
On 2014-02-14, at 16:02, Tony Finch wrote:
> Joe Abley wrote:
>>
>> Reactions and reviews of the two documents would be most welcome!
>
> The as112-dname draft still does not mention the glibc DNAME logging bug.
Oops, sorry for missing that, and thanks for the reminder
On 2014-02-16, at 11:39, Patrik Fältström wrote:
> - We can not use new RR Types, lets use A and TXT
> - DNSSEC will never take off
> - Lets just use HTTP for transport
I think we are suffering from a knee-jerk instinct to say no to ideas that we
assume will never work in the real world.
We c
On 2014-02-17, at 11:58, joel jaeggli wrote:
> On 2/16/14, 8:48 AM, Joe Abley wrote:
>
>> We can't do anything that will cause larger responses, because EDNS
>> support is not widespread, and in any case the network can't reliably
>> deliver fragments.
>
&
On 2014-02-18, at 10:54, SM wrote:
> Seriously, it may take some effort to get things deployed but that is not an
> insurmountable task [1]. One of the problems is that there isn't any money
> in doing that.
>
> [...]
>
> 1. I actually looked into it some time back.
I had some experience
Hi Tony,
On 2014-02-14, at 16:02, Tony Finch wrote:
> I think it's fairly obvious that I wrote just enough to get the idea
> across in a reasonably complete form, but didn't bother with thorough
> references (in particular not to your previous work, sorry!) or thorough
> review of formal termino
On 26 Feb 2014, at 5:03, Mark Andrews wrote:
> In message , David
> Conrad
> writes:
>
>> On Feb 25, 2014, at 9:51 AM, Stuart Cheshire wrote:
>>> If we have *some* pseudo-TLDs reserved for local-use names,
>>
>> I would think =
>> http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned
On 28 Feb 2014, at 6:31, Tony Finch wrote:
> John Levine wrote:
>
>> Since the device and the browser will not be online when you do the
>> initial configuration, it seems to me that if you use a validating
>> resolver you lose no matter what the name is.
>
> Hmm yes a very good point :-/
>
Hi Greg,
On 1 Mar 2014, at 19:45, okTurtles wrote:
>> ask them if they would be willing to accept a dns.alt or something like that.
>
> *.dns is a metaTLD, whereas I don't believe *.alt has been designated as such?
You're right, ALT (the TLD) doesn't exist today, might one day exist, and is
n
701 - 800 of 884 matches
Mail list logo
