Re: [DNSOP] [dnsext] Re: Computerworld apparently has changed DNS protocol

On 11/11/2009, at 3:29 PM, Duane Wessels wrote: On Wed, 4 Nov 2009, Nicholas Weaver wrote: Also, has someone done a study what the major recursive resolvers do on response failures from a root? Do they go to another first or do they try a smaller EDNS MTU? I gave a presentation

Re: [DNSOP] Further observationon AS112 ipv4 cull

On 26/07/2011, at 1:48 PM, William F. Maton Sotomayor wrote: All, As a data point, the original draft of -00 really started life as a straight copy of George's and Geoff's draft. I was looking for a way to establish a procedure for sending instructions to IANA for new delegations

Re: [DNSOP] Adoption of draft-wkumari-dnsop-omniscient-as112-01.txt as a WG work item?

On 21/02/2013, at 6:46 AM, Mark Andrews ma...@isc.org wrote: While I think we should adopt the document I have grave concerns about it. * there is no demonstrated need for it. thats opinion, not fact Mark. 'demonstrated need' stems from other people's desires. you might as well come

Re: [DNSOP] Review of draft-manderson-rdns-xml-01

My personal view, from deep time, is that this protocol was offered into the process facing upwards, as a result of an applications REST interface which was developed in APNIC facing downwards. Terry may have a different perspective but thats my sense: we had this working in-house as a lightweight

Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-as112-dname-01.txt

Worth logging a fault with the maintainers of the distro(s)? It seems to be DNAME in reverse V6 may well be useful, albeit as you say not relevant to AS112 On Mon, Oct 14, 2013 at 9:51 PM, Tony Finch d...@dotat.at wrote: Joe Abley jab...@hopcount.ca wrote: Geoff Huston and George

Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn

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 more complexity, it can be demonstrated that as long as 1) the sigs

Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn

, Jan 15, 2014 at 10:16 AM, Paul Hoffman paul.hoff...@vpnc.orgwrote: On Jan 14, 2014, at 3:04 PM, George Michaelson g...@algebras.org 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

Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

I used to get very unhappy when big name IETF attendees would wander into a room and say this makes me very uncomfortable at the mike. So having said that, and noting I'm nobody special, and certainly not a big name in IETF, or DNS... something about this makes me very uncomfortable we are a

Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

I am not personally convinced by there are too many people committed arguments. I never have been, and I think the chilling effect of this has been seen time and again. There has always been too many people doing things. Claiming the dead hand of history prevents us from changing course or

Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

Its a scaling question. Please don't sidetrack into distaste, its the question of preventing progress by saying too many when in fact, its tractable, and its software. .onion is an eminently tractable problem. Arguing otherwise is to argue the current .onion codebase dependency cannot move,

Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

by and large, thats right. So is what the TOR people did usurping .onion respectful of process? What do you do, when process isn't respected? -G On Tue, Feb 4, 2014 at 11:08 AM, Ted Lemon ted.le...@nominum.com wrote: On Feb 3, 2014, at 6:27 PM, George Michaelson g...@algebras.org wrote: .onion

Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt

On Thu, Feb 13, 2014 at 4:24 AM, Joe Abley jab...@hopcount.ca wrote: On 2014-02-12, at 11:28, Marc Blanchet marc.blanc...@viagenie.ca 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

Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)

in OID space, It was my experience that Russ ran the registry pretty open-minded. Its a classic dewey-decimal growing numberfield, so the cost burden of carving out a new OID is low, and he was minded to ask basic questions, steer you, but in the end, assign a unique value for the wider public

Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt

it. HELL NO and WE CAN'T aren't words in that post. -G On Fri, Feb 21, 2014 at 7:18 AM, John Bond m...@johnbond.org wrote: -Original Message- From: David Conrad d...@virtualized.org Date: Thursday 13 February 2014 02:48 To: George Michaelson g...@algebras.org Cc: draft-wkumari

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

are you saying that to pre-validate signed materials along a trust chain outside some immediate context (x) is inherently invalid? whats the limit on x? seconds? microseconds? don't all cacheing resolves cache common path trust checks under the TTL of the elements along the path anyway? On Wed,

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

, Tony Finch d...@dotat.at wrote: George Michaelson g...@algebras.org wrote: are you saying that to pre-validate signed materials along a trust chain outside some immediate context (x) is inherently invalid? whats the limit on x? seconds? microseconds? I'm sorry I can't parse that. Tony

Re: [DNSOP] AD bit with DNS64

useless bit is useless. Doge at 11. keep sciensing the DNS. apply more bits! On Sun, Jul 20, 2014 at 9:35 PM, Mark Andrews ma...@isc.org wrote: In message 20140721011015.ge22...@laperouse.bortzmeyer.org, Stephane Bortzmey er writes: The resolver on the IETF NAT64 network at the Royal York

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

knowing its not the root issue, I would like to remind people the RIR system for rDNS delegation is almost entirely automatic from our various portals, and WHOIS based nserver mechanisms. Its not hard to do the top part. We're not roadblocking. We don't have any failure to delegate the parent

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

statement. On 3/11/2014 2:36 pm, George Michaelson g...@algebras.org wrote: [snip] We don't have any failure to delegate the parent blocks facing down: Its people's willingness to invest energy on the various different approaches to the sub-delegation engines inside your own block management

Re: [DNSOP] Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia (circleid)

Given the behaviour of unknown algorithm, if the anycast node signs with an algoritm they can guarantee you don't understand, how did you know DNSSEC was turned off silently? ie, downgrade silent response means that an anycast node can mask changes to the root, because you won't know DNSSEC was

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

I'll take a dollar for every query in PTR we take at the ipv4 /8 and Ipv6 /12 level. Thats somewhere around 170,000/sec. Luckily, you'll all stop before I have the entire western economy in my pocket, but thats ok. I'll take the cents.. I'll take the millicents... Seriously: the volume of query

Re: [DNSOP] Using PTRs for security validation is stupid

PTR checks for ssh on call-in is stupid. But, putting ssh host keys in the DNS and not having to do that 'are you sure? are you sure? are you sure?' dance from Father Ted is not stupid. On Tue, Nov 11, 2014 at 5:48 PM, Lee Howard l...@asgard.org wrote: Many SSH servers (by default) reject

Re: [DNSOP] Using PTRs for security validation is stupid

The irony in SSH is that its a two way strongly authenticated connection. (assuming you do client keys) -So perhaps the sense of the story is that where proof-of-identity is innately part of the exchange, it makes little sense to deploy a barrier to entry like PTR checking, since you are using

Re: [DNSOP] Using PTRs for security validation is stupid

I would be asking anyone who says VerifyReverseMapping on by default, and VerifyHostKeyDNS likewise, should justify their position. Because the collective wisdom I'm seeing here is that its a false benefit, and considering what SSH is, and what it seeks to do its rather sad to be driven down a

Re: [DNSOP] Requesting adoption of draft-wkumari-dnsop-root-loopback

support. -G On Thu, Nov 13, 2014 at 11:20 AM, Warren Kumari war...@kumari.net wrote: Dear DNSOP Chairs, We are requesting a call for adoption of draft-wkumari-dnsop-root-loopback. W A new version of I-D, draft-wkumari-dnsop-root-loopback-01.txt has been successfully submitted by Paul

Re: [DNSOP] Call for Adoption: draft-eastlake-dnsext-cookies

support. anything to help cut down the noise in the DNS. On Thu, Nov 13, 2014 at 6:20 PM, Evan Hunt e...@isc.org wrote: On Thu, Nov 13, 2014 at 04:55:36PM -1000, Tim WIcinski wrote: https://datatracker.ietf.org/doc/draft-eastlake-dnsext-cookies/ Please review this draft to see if you

Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?

I think its possible people have misunderstood what we said, when we measured 'do not understand ECDSA' as a problem and presented on it. It is a tenable, arguable case, that PRECISELY because the fail mode is 'unsigned' we can move to ECDSA more easily than any other key transition under

Re: [DNSOP] RSA/SHA-1 to = RSA/SHA-256 ?

Another take on this, which may make some people feel very uncomfortable, is to propose key migration in RSA via a downgrade keylength: sign with a shorter RSA key, and re-sign with a long one once the original long one is widely deprecated under 5011. 1024- new512 (!) - new1024 this avoids

Re: [DNSOP] draft-ietf-dnsop-root-loopback-01

On Wed, Mar 25, 2015 at 9:57 AM, Paul Vixie p...@redbarn.org wrote: Tony Finch Wednesday, March 25, 2015 7:31 AM k...@wide.ad.jp k...@wide.ad.jp wrote: I don't know if such ISPs still exist, but when we started Anycast, it was reported that some ISPs did per-packet load balancing. If

Re: [DNSOP] 答复: Fwd: New Version Notification for draft-wkumari-dnsop-multiple-responses-00.txt

Mark.. can you amplify a bit on: FORMERR will just cause the nameserver to think that EDNS is not supported. This is not a issue unless there are signed zones and the resolver is validating. Because somewhere north of 10% of the world now validates.. On Wed, Jan 14, 2015 at 10:09 AM, Mark

Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material

I got to air my view. I concur its not a majority view. I don't feel I have to have the last word and I respect you really do think this is a good idea, and even meets the technical merit consideration for the process as designed. So I'm pretty ok with people weighing this up on the strengths and

Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material

by reserving a word in gethostbyname() space to stop the problem. -G On Thu, May 14, 2015 at 1:06 PM, Ted Lemon ted.le...@nominum.com wrote: On May 14, 2015, at 3:42 AM, George Michaelson g...@algebras.org wrote: I have a lot of agreement for what David is saying. What I say below may

Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material

I have a lot of agreement for what David is saying. What I say below may not of course point there, and he might not agree with me because this isn't a bilaterally equal thing, to agree with someone, but I do. I think I do agree with what he just said. I think that prior use by private decision

Re: [DNSOP] Order of CNAME and A in Authoritative Reply.

How specific is the ordering dependency by resolver code variant? by version? If this becomes a candidate for typing specific resolvers, its useful knowledge -G On Wed, Aug 12, 2015 at 3:25 PM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Wed, Aug 12, 2015 at 06:17:39PM +, Viktor

Re: [DNSOP] draft-mayrhofer-edns0-padding

What does it mean to exceed the proffered EDNS0 buffer size with your padded response? You're 'silent' on length, but surely the server should respect the EDNS0 size proffer as a limit? On Thu, Jul 23, 2015 at 6:50 PM, Alexander Mayrhofer alexander.mayrho...@nic.at wrote: Hi, I had a

Re: [DNSOP] Warren's DNSSEC root update draft

a long lived mechanism is in-band, not using labels in the DNS or query payload. bits in the EDNS space, indicating yes-no and where more than bits are needed, explicit field:value definitions will get us further. because they demand code change they can only inform us of the future. warrens

[DNSOP] we already have a new version of this problem

So can somebody explain to me what we are meant to do with a possible emerging homenet desire for .home? https://datatracker.ietf.org/doc/draft-cheshire-homenet-dot-home/ because I believe this isn't just the tail of odd requests from the tor people for various hash based names.. its another WG

Re: [DNSOP] we already have a new version of this problem

discussion time? please? -G On Thu, Nov 5, 2015 at 10:16 AM, Tim WIcinski <tjw.i...@gmail.com> wrote: > I believe the IESG guidance given to us is that no Special Use Domain > Names will be addressed until the 6761 "scaling issue" has a direction. > > On 11/5/15 10:11

Re: [DNSOP] Soon-to-come DNS over HTTP drafts

\o/ -G On Wed, Nov 4, 2015 at 2:03 PM, Shane Kerr wrote: > All, > > At BII we have been working on a couple of drafts that might be of > interest to the dnsop working group. We are happy to work them through > as independent submissions, but if there is interest in

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-edns-client-subnet

I have read the draft. I am collecting information carried in EDNS0 client_subnet and have been running modified authoritative state server-side in order to tickle it out, and I am happy with what I see. It ain't perfect but its pretty good. I like that the draft is reasonably clear about the

Re: [DNSOP] Brian Haberman's No Record on draft-ietf-dnsop-root-loopback-04: (with COMMENT)

Strong +1. This is an obvious, useful, rational and alas, strictly irrelevant point. Which I agree with. -G On Thu, Oct 1, 2015 at 12:51 PM, David Conrad wrote: > > > On Oct 1, 2015, at 10:45 AM, John Levine wrote: > > > >>> Uh, no. The *only* loopback

Re: [DNSOP] draft-lewis-domain-names-00.txt

Your example has some problems for me. Problems which I guess your question was designed to draw out. Firstly, *some* tor active clients operate by using bump-in-the-stack methods based or analogous to SOCKS. So, there is an API which intervenes on the normal operations and tunnels, and then its

Re: [DNSOP] draft-lewis-domain-names-00.txt

of scoping. -G On Fri, Sep 18, 2015 at 11:51 AM, Bob Harold <rharo...@umich.edu> wrote: > > On Fri, Sep 18, 2015 at 9:54 AM, Alec Muffett <al...@fb.com> wrote: > >> >> On Sep 18, 2015, at 14:16, George Michaelson <g...@algebras.org> wrote: >> >&

Re: [DNSOP] draft-lewis-domain-names-00.txt

My private comment bears repeating in public. DOMAIN names is about the property of domains. Domains are encompassing, set-theory/venn-diagram style. A domain and a prefix are analogous concepts. One is expressed syntactically somehow, the other is a mathematical property of bounding in a number

Re: [DNSOP] draft-lewis-domain-names-00.txt

I think its possible I'm arguing off to the side Ed. But, there was a scoping quality in domain, as applied to domain names, which is pretty "big" in my opinion. Its analogous to the ordering issues in fully qualified (relative) distinguished names in X.500. The order of elements of Surname=

Re: [DNSOP] draft-lewis-domain-names-00.txt

Ed wrote a draft whose purpose claimed to be definitional around what domain names are. In that context I replied. If you don't really care how we use words, thats fine too. I agree it won't alter anything and I want to stop here, since I suspect I'm already well on the way to hitting peoples

Re: [DNSOP] Expiration impending:

If its on the internet, its not out of band. On Mon, Oct 5, 2015 at 9:55 AM, Joe Abley <jab...@hopcount.ca> wrote: > > > On 5 Oct 2015, at 10:42, George Michaelson wrote: > > > Something very left field for me, but I believe important, is that we > need > >

Re: [DNSOP] Expiration impending:

every time I post a reply to a thread I think a million kittens (for herding) are born Joe, so it evens out. Here's another kitten to kill... Something very left field for me, but I believe important, is that we need to also publish the out-of-band publication point of the trust material. I

Re: [DNSOP] Expiration impending:

over > test setup now, so id like to know. > > > > I have no opinion regarding the more abstract discussion regarding where > such a description belongs and look to learn from those better versed in > that subject. > > > > -Rick > > > > > > > >

Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

The 7 Layer model is a useful tool to talk about things, its not a rei-fied thing. That said, apparent layer violations invite critique because they inherently carry architectural consequence. I think the overloading of a (semantic space) name to have special properties to take it out of the

Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

Given a conversation about DNS over DTLS, DNS over TCP, I think a body of work exploring the simple mapping over HTTP/HTTPS makes perfect sense and is more about the DNS than its about the underlying transport. So I'm in support, adopt. -George On Thu, Dec 17, 2015 at 11:07 AM, Shane Kerr

Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-01.txt

I want to dispute one part of this: the "DNSSEC may not scale well" part. With thanks to Ray Bellis, APNIC has been running an evldns webserver which signs on the fly, and we have achieved north of 3000 signs/second from this code on a smallish cloud node signing on demand. Our model was unique

Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

I think the REST/JSON conversation is worth having too! Didn't Jay Daley submit some ideas on that a while back? -G On Wed, Dec 23, 2015 at 3:15 PM, Paul Vixie <vi...@tisf.net> wrote: > On Wednesday, December 23, 2015 03:13:04 PM George Michaelson wrote: > > > I'd be inter

Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

I'd be interested in the cache effects. If the TTL is mapped into cache age, then there is potential for CDN distribution to work more better gooder. More for entertainment value, since label compression is totally bogus, like carrying forward ASCII only standards documents I mean who does that

Re: [DNSOP] Should we try to work on DNS over HTTP in dnsop?

https://www.ietf.org/mail-archive/web/dnsop/current/msg10479.html et seq. -G On Wed, Dec 23, 2015 at 3:21 PM, Paul Vixie <vi...@tisf.net> wrote: > On Wednesday, December 23, 2015 03:20:05 PM George Michaelson wrote: > > > I think the REST/JSON conversation is worth having too

Re: [DNSOP] Some thoughts on special-use names, from an application standpoint

I have a different perspective on this question Mark. Firstly, I find use of .magic as the extreme RHS of a name, to force special behaviour architecturally disqueting. I really do worry about what we think we're building when we encode this behaviour into name strings. It leads to all kinds of

Re: [DNSOP] Prefixed name spaces and DANE client TLSA

I think the mapping of SMTP (a protocol, an over-the wire framing and dialogue about exchanging mail) has been crossed (crossing-the-beam crossed) with a ROLE. a client can be an SMTP speaker, and a forwarder/delivery agent can be an SMTP speaker. They aren't performing the sale role. So does

Re: [DNSOP] DNS Delegation Requirements

its maybe me, I'm having a bad (no?) hair day, I need more caffiene.. but this feels like a "oh can't we just stop" moment. MUST in protocols terms is good: its proscriptive, definitive language around on-the-wire. MUST in operations terms is getting way off IETF charter, even with an ops focus.

[DNSOP] Can I have a slot in the DNSOP WG to discuss draft-michaelson-dnsop-rfc6761-is-closed

I've just lodged https://datatracker.ietf.org/doc/draft-michaelson-dnsop-rfc6761-is-closed/ I am requesting a slot in the DNSOP WG session at ietf95 B.A. to discuss this. cheers -George ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] I-D Action: draft-michaelson-dnsop-rfc6761-is-closed-00.txt

I know it had that clause Brian. I kept the document short. I think the clause was a sanity clause whose invokation was basically insane. We should not have formalized a process on it, it should have been something done on very mature consideration. Instead, we've had a very immature conversation

Re: [DNSOP] normative language in BCPs Re: DNS Delegation Requirements

On Mon, Feb 22, 2016 at 11:37 AM, Suzanne Woolf wrote: > (no hats) > > I think the other way to frame the use of strongly prescriptive language > in this document would be to leave the intended status at Informational, > and introduce it as an example of what some

Re: [DNSOP] I-D Action: draft-michaelson-dnsop-rfc6761-is-closed-00.txt

e On 23 February 2016 at 17:18, Brian E Carpenter <brian.e.carpen...@gmail.com > wrote: > On 23/02/2016 13:17, George Michaelson wrote: > > I know it had that clause Brian. I kept the document short. I think the > > clause was a sanity clause whose invokation was basic

Re: [DNSOP] Can I have a slot in the DNSOP WG to discuss draft-michaelson-dnsop-rfc6761-is-closed

On Tue, Feb 23, 2016 at 2:48 PM, Paul Wouters wrote: > > I seem to remember that the working group already put all 6761 related > requests for TLDs on hold. So new TLDs cannot be requested to be reserved > via 6761 anyway. I don't think a further RFC is needed to formalise >

Re: [DNSOP] Can I have a slot in the DNSOP WG to discuss draft-michaelson-dnsop-rfc6761-is-closed

On Tue, Feb 23, 2016 at 3:05 PM, Paul Wouters wrote: > > Face to face time is rare. It also does not include everyone that's on > the list. So where possible, discussion on the lists is always preferred. A good bar. A high bar. A high bar, which I don't think the "design team"

Re: [DNSOP] Can I have a slot in the DNSOP WG to discuss draft-michaelson-dnsop-rfc6761-is-closed

initiatives about resolving these 6761 > issues have progressed a bit further. > > Paul > > Sent from my iPhone > > On Feb 22, 2016, at 18:14, George Michaelson <g...@algebras.org> wrote: > > I've just lodged > > https://datatracker.ietf.org/doc/draft-mich

Re: [DNSOP] I-D Action: draft-song-dns-wireformat-http-01.txt

I expect that DNS over TLS and DNS over HTTP/2 are both going to get to much the same place because the technology is driving to the same place: get more of the query into the initial incoming packet so that the first response has useful payload. Do you think the differences are down to more than

Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

I don't personally think cacheing NXDOMAIN is bad per se: the question is with what negative cache time, and what consequence in the context of a change in zone delegation structure in order to achieve DDoS mitigation. When there is no DDoS you want the cache to do its job. When there is, you want

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

I wouldn't normally invoke 'the nuclear option' but the parallels with good science/bad politics are stark here. Norbert Weiner left the field and moved into biology and cybernetics because he realized his personal ethics were totally adrift in the sea of consequence of work on nuclear physics. I

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

: > it wasn't my intention to ignore the socio-legal issue, but the problem > statement also can't presume a solution. I will think about this and try to > come up with better text. thanks for the feedback, both of you. > > On Wed, Apr 6, 2016 at 5:16 PM, George Michaelson <g...@al

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

On Wed, Apr 6, 2016 at 5:07 PM, Alain Durand wrote: > Reading section 4.2 and 4.3 of draft-tldr-sutld-ps-00, it would appear you > are in the camp that does believe those “special names” are immune those > socio-economic pressures and/or the IETF can deal with this. Do I

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

I'm confused. DO bit implies EDNS0, and we think DO bit in the field is north of 75%. What did I mis-understand? The APNIC 1x1 is a random sample over users, and it sees significantly more than 75% EDNS0. More like 93%. -George On Tue, Mar 22, 2016 at 11:55 AM, Paul Vixie

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

On Thu, Mar 24, 2016 at 7:10 AM, Florian Weimer wrote: > DO was used initially for SIG and kept for RRSIG. For an early DNSSEC > implementation, RRSIG was just another unsolicited RR type because it > could only know about SIG. This suggests (to me at least) that >

Re: [DNSOP] I-D Action: draft-song-dns-wireformat-http-01.txt

Bearing in mind that I like being a purist and could understand the GET/POST thing in terms of architecture, I'm asking myself if it makes sense to use GET URL semantics which require super-encoding things to fit into URL norms, or to use POST semantics where the block of data might be constrained

Re: [DNSOP] [internet-dra...@ietf.org: New Version Notification for draft-sullivan-dns-class-useless-01.txt]

if we defined them as 'ignored' for now, could we repurpose them in some mythical future? I have a feeling we did this with things like the ToS bits in the original v4 packet, given that diffserve didn't exist when they were first defined, or .. did I just find the time machine? -G On Mon, Mar

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

Whats your reaction going to be, to a closed 6761 because if you come to the microphone with a "but we built to the userbase, we have millions" and make bambi eyes, I feel a bit like saying "you were warned" ie, squatting a domain, is squatting a domain, no matter how much you believe in your

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

On Tue, Mar 29, 2016 at 1:36 PM, Andrew Sullivan wrote: > That's in effect an argument that the special-names registrations are not > special. I > do not agree with that claim. >From an extreme point of view (which clearly, contextually, I hold) thats exactly what I

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

Make the application for .alt actually ask for xn--59g and I'd be there. or even xn--3ve9dwb1a The application demands .alt? It has the same problems as any other. Its sole purpose should be uniqueness, and choosing a string which has semantic meaning for a large community is confronting the

Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

On Tue, Mar 22, 2016 at 12:07 PM, Paul Vixie <p...@redbarn.org> wrote: > > > George Michaelson wrote: >> >> I'm confused. DO bit implies EDNS0, and we think DO bit in the field >> is north of 75%. >> >> What did I mis-understand? The APNIC 1x1

Re: [DNSOP] my lone hum against draft-wkumari-dnsop-multiple-responses

"in reality" is skewing the story. You don't foresee a usecase, but you do foresee abuse? So deploy cookies or move to TCP, or DTLS or some other cost space where amplify implies special knowledge, or cost on the amplifier. I'm not sure I understand the use-case either btw, but this rebuttal

Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

UDP+cookies could work for you? -G On Mon, Jul 11, 2016 at 10:19 PM, Ray Bellis <r...@bellis.me.uk> wrote: > > > On 11/07/2016 07:13, George Michaelson wrote: > >> Things like client capability signalling, I suspect are in a harder >> bucket. I won't say intractably

Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

Thats good to know Mark. I took a dark view of change in DNS, but I do recall believing that for some problems, with tractable volumes of change-effectors, you can move on them. So, thanks for pushing: it helps. Things like client capability signalling, I suspect are in a harder bucket. I won't

Re: [DNSOP] 答复: Fw: New Version Notification for draft-shane-dns-manifesto-00.txt

I think you missed the point John. Its a manifesto, and it can take radical positions. If you read Shanes markup its clear a lot of things which are implicit in 'UDP/EDNS0' are up for grabs. I for one, would welcome versioning models closer to HTTP. I'd also welcome client-capability signalling

Re: [DNSOP] Fwd: I-D Action: draft-tldr-sutld-ps-01.txt

I won't be in Berlin, but I think this draft deserves discussion. It's simple, focussed on the problem statement side. [ I'm speaking from left field, since I think the best course right now is to shut the process down, but I don't see a problem-statement as a problem in that light: all the

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

On Tue, Aug 16, 2016 at 10:57 PM, Tim Wicinski wrote: > All of these documents are attempting to solve a larger problem in different > ways. The end result is "Return Associated Answer" to the client. > > The question is starting to coalesce around these two premises: > > -

Re: [DNSOP] The Larger Discussion on Differences in Response Drafts

my bad. I've been re-framed. Contextually, PUSH means (to me at least) 'do this promiscuously' and PULL means (to me at least) 'do this if asked' -which is not what I previously understood. In that case, I think PULL makes more sense: do this, if the client signals its what it wants. Otherwise,

Re: [DNSOP] ALT-TLD and (insecure) delgations.

sorry to be thick, but.. can we have both on a case-by-case basis somehow? it feels like no, because the sign over the zone state implicitly carries either denial of all false, or denial of none. I can't see how it can be in a dualistic middle ground. but if we could do it somehow, cleverly, it

Re: [DNSOP] DNS-Server distribution statistics

I have never entirely got with the people who think obscuring version information is necessary and correct. Designing for the bad actors presupposes they will somehow magically not attack you, simply because you obscured the version info. Root ops (I may misremember) stand out in my mind as a

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

chosen. But I did also hope, that it would terminate in DNS of older code. A useful side-effect. G On Tue, Sep 13, 2016 at 11:02 AM, Warren Kumari <war...@kumari.net> wrote: > On Mon, Sep 12, 2016 at 8:27 PM, George Michaelson <g...@algebras.org> wrote: >> Alt being semantical

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

Alt being semantically overloaded in times past, contextually even in domain names (Usenet, the great renaming) It seems highly unwise to ignore that historic understanding that people thought it meant the same thing as "burning man" The string >not-dns< has two useful properties: its not

Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names

If you can come up with an efficient, "fair" and trusted process for a unitary name space on domain principles (domains of scope. trees.) that doesn't confront collisions over desires for labels at arbitrary points in the tree, and of essential 'centrality' in decision making logic over things

Re: [DNSOP] moving forward on special use names

This is an instance of embedding. {th...@example.com}.{non-DNS-part} is not subject to special delegation rules in some sense, because the test of {non-DNS-part} requires no DNS action. If its synonymous with _special_label_.{non-DNS-part}.{example.com} then its about a conversation with upper

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

None of these named spaces would "fail" to work as sub-spaces of .ALT or .arpa or any other community-led IETF tech community managed label. You haven't convinced me they innately need to exist as a TLD. The sole entrypoint into that model, is a belief in what happens in the browser bar and at

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

exact same situation in this discussion, but > with different things that they lose and gain. So we have to all try to > understand each others' perspectives in order to come up with a way forward > that can gain consensus. We can't just start arguing over which way > forward to choose wi

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

The initiation problem is the belief IETF needs a mechanism to identify non-use of the DNS or special use of the DNS demanding a break-out from normal gethostbyname() and related processing. The second order problem is that people come to the table with proscriptive ideas about the specific

Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

Thats precisely why its NOT a false analogy: the design model in the IETF is that the value doesn't matter, but in the DNS, the design model is "follow the money" and 6761 crosses the bars: it enables people in tech-space, to reserve labels in meat-space. We got it wrong. We should have

Re: [DNSOP] Future of "Using DNAME in the DNS root zone for sinking of special-use TLDs" ?

Mark, thats a bit of an unsatisfactory answer. the RFC (which you authored) says: "...As with caching positive responses it is sensible for a resolver to limit for how long it will cache a negative response as the protocol supports caching for up to 68 years. Such a limit should not be

Re: [DNSOP] Future of "Using DNAME in the DNS root zone for sinking of special-use TLDs" ?

I would encourage you to write up some terminal state, either for publication as an informational or in some other document series. People find stuff, and if you link to it in the mail archives, it will be a useful reminder of where we got to on the conversation. On Wed, Oct 19, 2016 at 8:38 AM,

[DNSOP] CBOR-DNS compression is 30% the size of gzip compressed PCAP

Terry clarified, the 30% size compression is not from uncompressed, but is the comparision with compressed gzip pcap. So, compressed DNS-CBOR is *significantly* smaller than pcap.gz -G ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] DNSSEC operational issues long term

btw this is not in any sense a novel problem. Anyone who owns a Dell, and uses iDrac will be familiar with the "your certificate chain to this console java app is expired" problem. It can be fixed, but it requires effort. And alongside the crypto age-out problem, the dependency on java is

Re: [DNSOP] Heads-up - draft about "letting localhost be localhost" in SUNSET4 that really should be in DNSOP

This may seem a little strange, contrarian even, given how implacably opposed to new things in this space pending some sanity, but I am actually, broadly speaking, in favour of defining the world as it is, regarding localhost. If somebody seeks to invent something new, that is a discussion of its

  1   2   3   >