Re: [DNSOP] DNS Grease?

so yet again, I voice things which show my ignorance, not yours. I thank you for the gentle clue-stick hit, it was educational. -G On Tue, Feb 27, 2024 at 12:24 PM Shumon Huque wrote: > > On Tue, Feb 27, 2024 at 12:01 AM Mark Andrews wrote: >> >> >> > On 27

Re: [DNSOP] DNS Grease?

Not in any way to stop this specific draft, I wonder if this is a more general principle of exercising code points which are not marked "never to be used" and should also be raised cross-area, or in another place? Maybe the best path is to get this proved here, and then embrace-extend. I tend

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-rfc8109bis

I support publication. The remainder feel like nits which would get resolved in editor queue. I discussed the priming issue with Paul H privately and I think his response covered my concerns. Basically, if you run hyperlocal root, it subsumes the functionality of the cache priming activity, but

Re: [DNSOP] NOTIFY: How to locate the target

I think we're conflating how you learn what endpoint to send NOTIFY to, with the protocol extensions or changes to make it legal/normal to do NOTIFY for this purpose. I don't personally think the whole "but how do I know where to do it" is as important as some of you seem to think it is. But,

Re: [DNSOP] Fwd: New Version Notification for draft-many-dnsop-dns-isolated-networks-00.txt

I wonder if some kind of "limited licence local signing key" model could be used, to get a signed permit from a "real" TA in the DNS to specify the zone(s) that a limited licence key could use, with a far longer than normal time over the rights signing. Because we don't want inflated

Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?

make false assumptions. -G On Thu, Jul 27, 2023 at 10:08 AM Robert Edmonds wrote: > > George Michaelson wrote: > > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > > the header. > > > > What would be interesting uses of the flow-label? Oh wait

Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?

I like your idea! Another one is to reserve n bits for the length of the resolver/forwarder chain to the answer. if you pass it on, increment the n bits. preserve it in the answer. would permit authorities, and clients to know how long the chain is behind the answers they see and questions made.

[DNSOP] what could we do with 15 unused bits of QDCOUNT?

if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in the header. What would be interesting uses of the flow-label? Oh wait.. that's right, nobody really knows at scale how to use flow-label either. I tend to "use it for 15 bits of signalling" because there are a lot of things I

Re: [DNSOP] should all ccTLD be on the Public Suffix list?

Joe, it's clear I didn't understand and I've been hit with quite enough cluesticks for today. I missed the wildcards in my parse and having accounted for them I now see reality as it is. George On Wed, 19 July 2023, 19:26 Joe Abley, wrote: > On Wed, Jul 19, 2023 at 02:42, George Michael

Re: [DNSOP] should all ccTLD be on the Public Suffix list?

l 19, 2023 at 3:30 PM Paul Vixie wrote: > > > > George Michaelson wrote on 2023-07-18 17:42: > > I know, I could submit these to the PSL website directly. I am asking > > a meta question: do we think that operationally, if a PSL exists, that > > all ccTLD and TLD sho

[DNSOP] should all ccTLD be on the Public Suffix list?

I know, I could submit these to the PSL website directly. I am asking a meta question: do we think that operationally, if a PSL exists, that all ccTLD and TLD should be on it? The following ccTLD are in ISO3166 but not in the PSL: bd bl bq ck eh er fk jm kh mf mm np pg um za all

Re: [DNSOP] WGLC rfc8499bis for revised lame delegation definition

To the definition and future use of lame, I think this is reasonable editorial. I think the draft could use some linkage to the "better terms" so it's clear what terms are now held to refer to what we formerly called "lame" -But that would be connective, not substantive to the definition of what

Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

When people talk about "lame" they're in a sentence with a subject (the DNS), and an object(ive) -But there isn't a single parse. Sorry, but the declarative "this is what it means" seems to me to be failing, hard. The subject(s) are the zone(s) that are lame? thats one case. the other case, is

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

Yes, that's pretty succinct and clear. G On Sat, 29 Apr 2023, 04:26 Hugo Salgado, wrote: > Thanks a lot George for your comments. > About this suggestion: > > On 14:29 27/04, George Michaelson wrote: > > It's a debug tool. It isn't going to be something I expect to use, but &

Re: [DNSOP] WGLC rfc8499bis one week extension for lame delegation definition

I prefer option 2. I think it fulfills the implicit obligations inherent in 1) -which would be to fill the hole of uncertainty. Its succinct, and it covers the cases I think define the condition. I would ask if 2) also needs to define ".. or cannot be resolved" because "[or not at all]" is a bit

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

I've read this draft. I think its a simple and straightforward proposal. It explicitly notes the security issue that its not covered by DNSSEC, it has implementations, and it had a good discussion run 2021/2022 which was overwhelmingly positive. I had no problems understanding the intent. its

Re: [DNSOP] Meaning of lame delegation

The shortest path out is to avoid use of the term and be explicit about the 3 (false trichotomy: there may be more) cases. If they lack labels, then number the bullet points or paragraphs and refer to them as RSSAC-.A.B.[C|D|E] instances until the name(s) settle. We're unlikely to terminate in a

Re: [DNSOP] draft-ietf-dnsop-alt-tld next steps

I agree. I would be amazed if a 6 month feedback window was sufficient to get this through the formalisms. -G On Wed, Mar 8, 2023 at 7:02 AM David Conrad wrote: > > Rob, > > 4 weeks for ICANN (which? Organization, Board, Community, all 3?) to provide > feedback? (That feels sort of like the

Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC

I described at IETF 111 ( > https://datatracker.ietf.org/meeting/111/materials/slides-111-dnsop-sessb-black-lies-ent-sentinel-01 > ) and currently implemented > by NS1. > > Christian and I are currently discussing some tweaks to that mechanism > which we will broach in a

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

Joe Abley wrote: > > Hi George, > > On Wed, Feb 22, 2023 at 19:37, George Michaelson wrote: > > purely administratively, I'd like to understand how the WG chairs and > AD intend dealing with fundamentally opposed drafts. > > > There's only one draft here, as far as

Re: [DNSOP] QDCOUNT > 1 (a modest proposal)

purely administratively, I'd like to understand how the WG chairs and AD intend dealing with fundamentally opposed drafts. I would think that a formalism here might be needed: if we discuss A and not B and reject A, have we implicitly accepted B? And vice-versa? Do we actually need to discuss

Re: [DNSOP] Generalized DNS Notifications (draft-thomassen-dnsop-generalized-dns-notify-00)

I got quite used to being told "stop inventing things" and as a general principle, its not such a bad thing to be told. But it occurs to me, inventing a way to be told authoritatively where the zone cut should be might not be such a bad idea, if it was useful. If the alternative is to have to

Re: [DNSOP] [Ext] root crud, Possible alt-tld last call?

... https://www.icann.org/rzerc-membership points to a fine body of membership. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] "Moving .INT" (was Re: [Ext] root crud, Possible alt-tld last call?)

> > George, > > This is unrelated to alt-tld, but just as a point of clarification: > > On Oct 25, 2022, at 5:17 PM, George Michaelson wrote: > > Just because we're punting ALT into their process, and moving .INT into their > process […] > > > I presume you’re talking about &

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

On Wed, 24 Aug 2022, 12:23 pm John Levine, wrote: > > I don't see any reason why that is our problem. > > On my system at least, the only DNS queries that go through nsswitch > are ones starting from calls like getaddrinfo() or gethostbyname(). If > you're interested in MX or SRV or HTTPS or

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-17

On Wed, Aug 24, 2022 at 11:45 AM Paul Hoffman wrote: > > On Aug 23, 2022, at 5:52 PM, John Levine wrote: > > > > It appears that Paul Hoffman said: > > > 4) Say in English prose that since the DNS ignores ASCII case > > distinctions, all versions of .alt are excluded from the DNS, but it's > >

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

I pose human factor and UX questions: Do you think people expect to have to do things at url Point and Click time to select which namespace is resolved? If I specified my.domain.gns.alt do I expect the entity behind my.domain to be the same in gns and in dns? If I am writing gns resolution code

Re: [DNSOP] Anything goes in ALT, was On ALT-TLD, GNS, and namespaces...

You appear to be taking the concept to a place where alt is the label which defines the start of non-DNS switching, and the 2LD is the specification of the namespace/service you work in. So its a domain model, driving to software and namespace path, before it begins resolution of the name proper.

Re: [DNSOP] [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

I have a question which doesn't need answering, but I have it anyway. Nobody intends re-using the code points, right? So the deprecation is about BCP, not about conformance to protocol? It's just the DNS police telling people to move along? Some days, I think that kind of thing might be better

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

ULA is no different. "its private addressing" except when ip6.arpa shows that people are trying to use it, to the outside world. Lots of great theories about things break .. when they meet the DNS. On Mon, Aug 15, 2022 at 1:17 PM John Levine wrote: > > It appears that Tim Wicinski said: >

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

How to privatise the commons in names. 1) release a browser with remotely enable-able features, initially disabled 2) when you hit 95% penetration, enable the feature. If the omnibar in the dominant browser had a selection logic akin to nsswitch.conf or resolver.conf config options, this debate

Re: [DNSOP] On ALT-TLD, GNS, and namespaces...

To paraphrase and bastardise an old saying: "Domains are powerful. All the good ones are taken" I think Paul V is right that the powerful concept here is the domain concept, scope and hierarchy. G ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

Not trying to say you're wrong, I just observe that if there is an omnibar, and people type names into it, then there is a latent problem of ordering lookup, and deciding, in names and more than one namespace. Pretty much all the hard stuff stems from there IMO. Names are hard. I think belief in

Re: [DNSOP] [EXT] Re: draft-schanzen-gns and draft-ietf-dns-alt-tld

In a similar spirit to avoiding "be damned" in a doc, I think referring to choice 3 as "squatting" is probably both truthful/accurate, and regrettable. We probably shouldn't formally document (ab)use of a space this way without more considered language and text around what it implies. I thought

Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

+1 This feels like a process run-around. The conversation has been held in DNSOP and didn't reach consensus. It is not like the WG said "we don't care" -the WG cared immensely. It just couldn't come to a single point of view. A lot of the issues are layer-8/9 and I think it's most likely this is

Re: [DNSOP] CDS Bootstrapping for vanity DNS servers

As a point of information, All the parent zones (the /8 and /12 RIR delegations in in-addr.arpa and ip6.arpa) are now signed. Or should be. it is possible a couple of stand-out /8 holdings aren't but thats resolvable at some pain. The problem would be that for CDN hosting instances of DNS, the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-03.txt

for a 200 in 200,000,000 problem? Ban it. -G On Fri, Jan 7, 2022 at 9:46 AM Wessels, Duane wrote: > > In order to make progress on the glue-is-not-optional draft, we need the > working group to reach consensus on the requirement level for sibling glue > (MUST, SHOULD, or MAY). > > The only

Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

This is one of those times where classic email quoting isn't helping my brain. Maybe I'm alone, but I think there may be others in a similar situation. We're close to a discussion of very specific language. I think the best thing is for people to state once, in their level of indentation (ie

Re: [DNSOP] [EXT] Re: [Technical Errata Reported] RFC7686 (6761)

Two instances of 'if' there. Only one appears to me to be certain. (Now we can disagree about which one) G On Thu, 2 Dec 2021, 10:56 am Paul Hoffman, wrote: > On Dec 1, 2021, at 4:02 PM, Warren Kumari wrote: > > I think that enough time has now passed that we might be strong enough > to

Re: [DNSOP] Question on interpretation of DO and CD

> First of all, it is apparent that if a resolver maintains a unified cache in > which it has DNSSEC-aware and DNSSEC-oblivious data, things will definitely > break. The general wisdom appears to be that you need to maintain two > caches, and only answer DO-set queries with DO-set cache (or go

Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-02.txt

I had it said to me, that "lies" about the ns.bar.example are not a problem because if they can tell you a DNSSEC verified truth about the primary request, you don't care who told you. That can only be truly not a concern, if the primary is DNSSEC verified. So, for the non-DNSSEC, it feels like

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

It's time to ship. I mean sure, if somebody who does detailed reading has a killer problem I can see we'd talk it out but we're 7 revisions in, its 4 years later, and it seems rational to document the expectation this is modern DNS, and we do TCP as a MUST SUPPORT, Auth and recursive. Its

Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries

No. thats good and clear. Priming is not just the concept of being correct, its specifically following a mandated in-band mechanism. It is a standard, and the bis requirements are not just "arrive at the state, don't care how" they are "arrive at the state by following this specific procedure"

Re: [DNSOP] [Ext] Starting a -bis document for RFC 8109: Initializing a DNS Resolver with Priming Queries

If I (insanely) ran a totally manual, out of band process to periodically canvas the space and injected the knowns into the model of "root" for my resolver, would I be able to say I am primed? I am trying to get to the point that the "how" part is only exemplary, explanatory. The requirement is

Re: [DNSOP] definitions of "public DNS Service"

On Mon, May 25, 2020 at 7:06 PM Vittorio Bertola wrote: > > If you wanted to convey the nuance that it's not just open, but open on > purpose and meant to attract users from the entire Internet, you could add > "global": "open global resolver". > > Or, as an alternative, you could use the term

Re: [DNSOP] definitions of "public DNS Service"

George Kuo who is not subscribed to the list said this: >Thanks all for sharing. >I have learned from all your input. > >George Kuo. On Fri, May 22, 2020 at 2:11 PM George Michaelson wrote: > > Thank you all for the responses. This has been very interesting. Paul

Re: [DNSOP] definitions of "public DNS Service"

DNS-attacking terms. BTW, I'm happy to see there is a document to define all > DNS attacks and mitigation suggestions. > > Best regards， > Davey > > On Fri, 22 May 2020 at 08:56, George Michaelson wrote: >> >> My Colleague George Kuo asked me for definitions of public DNS >> s

[DNSOP] definitions of "public DNS Service"

My Colleague George Kuo asked me for definitions of public DNS service. not "public DNS" but the trigram "public DNS service" Colloquially we understand this reasonably well. It is in the space of what Google, quad9, CloudFlare and others do. The various clean DNS feeds people subscribe to, it is

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

Op 12-05-2020 om 00:48 schreef George Michaelson: > > I support adoption. > > > > I wondered a little about "it is absolutely essential for these > > transfers to be protected from unexpected modifications on the route. > > So, catalog zone transfers SHOULD

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

I support adoption. I wondered a little about "it is absolutely essential for these transfers to be protected from unexpected modifications on the route. So, catalog zone transfers SHOULD be authenticated using TSIG [RFC2845]." The use of a categorical *absolutely* and SHOULD is jarring. If this

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt

This is a not uncommon problem in 'make this protocol work in future' spec. It could say "for version ZERO of this protocol" and then say "future versions of this protocol should stipulate what other values mean, and how this affects handling of all-zeros state, and other states" Saying "must not

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

I dislike the rate of change in terminology, and what feels like intrusion of somebodys favourite term, which is not actually reflective of widespread use in DNS discussion. I have never said DO53 and I don't know anyone who has. Every other term of art, has sound basis. This feels like a bad

Re: [DNSOP] Proposal: Whois over DNS

On Wed, Jul 10, 2019 at 1:07 AM Joe Abley wrote: > > Hi John, > > On 9 Jul 2019, at 10:36, John Bambenek wrote: > > > If the proposal is to create a standard by which to put contact > > information into DNS records, what venue would you suggest? > > I think that the protocol aspects of this are

Re: [DNSOP] TA signal - suggestion to enhance signal

On Mon, May 13, 2019 at 11:21 AM Wessels, Duane wrote: > > Thanks for the suggestions. I think the first discussion needs to be whether > there is support for better signals at the expense of possibly less privacy. > My sense of the way things are today is that "privacy is king." > > DW I

Re: [DNSOP] Call for Adoption: draft-wessels-dns-zone-digest

Support adoption. This is a mechanism which I think is useful and which permits out-of-dns provisioning mechanisms to have high trust in the specific state of a zone being fetched. It is complementary to DNSSEC and not antagonistic. -George On Sun, Mar 10, 2019 at 3:31 PM Tim Wicinski wrote: >

Re: [DNSOP] [Doh] Proposal for a side-meeting on services centralization at IETF 104 Prague

we're in danger of acronym soup here. RDNS can refer to reverse-DNS (in-addr.arpa and ip6.arpa) and I think usurping it for Resolverless DNS is an interesting moment. -George On Thu, Mar 14, 2019 at 10:49 AM Ted Lemon wrote: > > On Mar 12, 2019, at 2:52 PM, Paul Vixie wrote: > > please do not

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

I feel backup key, and alg, are sufficiently of wide benefit, that the qualms about frequency are second-order to the primary goal of an improved outcome 1) backups go to stability of unplanned events 2) new alg would permit a return to shorter packet sizes even across keyroll, which makes IPv6

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

as usual, billions arithmetic got me. 0.001 * 2,300,000,000 is 2,300,000 so thats a few dodgers stadiums more than I said... -G On Tue, Oct 30, 2018 at 10:41 AM George Michaelson wrote: > > There is a tension between assumed privacy ("this is my resolver, what > I run is my busin

Re: [DNSOP] Informal meeting about root KSK futures at IETF 103

There is a tension between assumed privacy ("this is my resolver, what I run is my business, how I run it is my business") of entities running resolvers, and customers ("this is my DNS query. what I ask is my business") and providers of infrastructure ("this is my liability: the consequences of

Re: [DNSOP] Clarification question: compression pointers always to names earlier in the packet?

As long as we're in UDP, with DNSSEC, and many NS, packetsize in DNS will be a "thing" and revoking label compression pushes to fragments and/or TCP. Personally, I think TCP is fine, and the emergence of long-lived bindings in DNS is fine, and this is a bit overblown as a problem. But, I get

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

How can it go WGLC with section 6 an open question? in every other respect I like the document. Bad Hair and all. I would like to understand if we could work out a way to do traceroute in the codes, with some defined code to ask the DNS resolver to perform a TTL drop on a counter and mark itself

Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

time) > > problem which has since been given a significantly better solution, but so > > long as the workaround appears to be working, people are loathe to put in > > the effort of implementing the actual solution. > > > > sigh… Human nature. > > > > Owen > >

Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

I have said before, but don't know if I still adhere to it, but anyways, here's a question: How *long* do people think a biassing mechanism like HE is a good idea? * is it a good idea *forever* * or is it a transition path mechanism which has an end-of-life? * how do we know, when its at

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

I've read it. I think its cooked. I think we should move to WGLC. I could quibble, but they'd be like tribbles. I think the author should add me to the acknowledgements for NOT forcing tribbles into the document. "This is a poor inference." needed to be used more often. -G On Thu, Sep 6, 2018

Re: [DNSOP] Global DNS architecture changes, "the camel", and so on

I sort of agree. The addressing, a naming function and routing are the three legs. If you do naming right, you can drop addressing and use ephemeral addresses, and if you do routing right you can drop addresses and do ad-hoc. But you need addresses and routing if you want to do without names, so I

Re: [DNSOP] Global DNS architecture changes, "the camel", and so on

I am less sure the UDP/TCP thing reduces to "no" I see no reason any more to assume session cost is too high for a globally deployed DNS. I suspect what DNSOPS and a hypothetical directorate thinks about DNS is less impactful (sorry, hate that word) than what embeds in Android devices.

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

: > > >> On 10 Jul 2018, at 10:22 am, George Michaelson wrote: >> >> Yea, having read things properly and been hit by a cluestick I think >> this is good. >> >> * the RR is a digest over canonicalized state >> >> * there is a simple

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

no in-band DNS dependency to get a zone and check a zone. So functionally, Duanes thing is identical in outcome to PGP signing or other exterior file signatures. -G On Tue, Jul 10, 2018 at 10:05 AM, Wessels, Duane wrote: > George, > > >> On Jul 9, 2018, at 4:36 PM, George Mi

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Jul 8, 2018, at 6:02 PM, George Michaelson wrote: >> >> So how about use of a PGP key which is a payload in TXT signed over by >> the ZSK/KSK so the trust paths bind together? >> >> fetch one DNS record +sigs, check against the TA (which has to be a >> given) and

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

On Mon, Jul 9, 2018 at 11:23 AM, Olafur Gudmundsson wrote: > Olafur > PS: Also for the record I think AXFR is a horrible protocol hack. > PPS: I almost agree with Prof Bernstein that rsync is a better solution, > from an interoperability perspective. AXFR is reductionism/dogfooding of self

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

So if I look at what you said, what I see is "inband, canonicalization is a cost we don't want to bear, to produce a signed product of whole of zone" and "if we accept knowledge of a PGP or other external key as the moment of trust, out of band, disordered but specifically testable as *this file*

Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

Only the zone authority can publish a DNSSEC signed zone. Anyone can claim to publish a view of a non-DNSSEC signed zone. On Thu, Jul 5, 2018 at 7:11 PM, Dick Franks wrote: > > On 3 July 2018 at 16:40, Joe Abley wrote: >> >> On 3 Jul 2018, at 09:11, Matthew Pounsett wrote: >> >> > This is not

Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

I'd like the WG to close on this. It feels to me like we've had useful edit in the call and the document is now stable and ready to move onto the next phase. Ship it. -George On Fri, Apr 6, 2018 at 2:35 AM, tjw ietf wrote: > > After walking through the 168 emails on this

Re: [DNSOP] Terminology: validating resolver

On Tue, Apr 3, 2018 at 12:13 AM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > On 2 Apr 2018, at 17:05, George Michaelson wrote: > >> RFC4035 section 3.2 looks like it has usable words surely? > > > Maybe I'm an idiot, but I see no definition of "validati

Re: [DNSOP] Terminology: validating resolver

RFC4035 section 3.2 looks like it has usable words surely? not from those words, but in my personal opinion, Any resolver which is able to understand and apply the semantic context of DNSSEC signatures over RR should be considered a validating resolver. However, a validating resolver may also be

Re: [DNSOP] Definition of "trust anchor"

This doesn't seem a good fit for the PKI definition of a TA. You can have several TA. any are sufficient to define a trust point to anchor validation. you don't care which. how the path is built, is not the same as where it terminates. top down or bottom up is legal in PKI. -G On Sun, Mar 25,

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-07

isn't it a #define string? or passed in via environment from configure? -G On Fri, Mar 23, 2018 at 11:47 AM, Mark Andrews wrote: > >> On 23 Mar 2018, at 10:08 pm, Warren Kumari wrote: >> >> On Fri, Mar 23, 2018 at 10:07 AM, Mark Andrews wrote:

Re: [DNSOP] Terminology question: split DNS

ally bound it to "which interface did I get the question on" thats subtly different, and more side-like. -G On Mon, Mar 19, 2018 at 6:33 PM, Paul Vixie <p...@redbarn.org> wrote: > > > Ted Lemon wrote: >> >> On Mar 19, 2018, at 6:10 PM, George Michaelson <g...

Re: [DNSOP] Terminology question: split DNS

"A DNS resolver which looks at the client requesting address, and uses this to serve different versions of information about a zone based on which client address or prefix requests it." the concept of "side" is rather limited. split DNS can encompass more than two sides can't it? -George On

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

welcome them. But... its not my draft. I guess .. its "all of us's draft" now. So.. hells yea. Write words. -G On Wed, Jan 31, 2018 at 1:40 PM, Joe Abley <jab...@hopcount.ca> wrote: > Hi George, > > On Jan 30, 2018, at 21:49, George Michaelson <g...@algebras.org> w

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

>The problem you hit was in BIND. To get around it, you simply add "check-names >master warn;" to the options. And with this.. he was good again. So, modulo the implementation cost/consequence, I'm good here. But, if this is detail, then I'm back at 10,000ft: noting the IETF is all about

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

I tested this. you can bind _label onto CNAME but not A/. bind won't serve zones with it. So yea.. I think the change is needed. thats substantful. -G On Wed, Jan 31, 2018 at 10:29 AM, Warren Kumari <war...@kumari.net> wrote: > On Tue, Jan 30, 2018 at 6:44 PM, George Mich

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

I think we're rat holing. I'm not an author on this draft, but I know them both, and I work with one, and I believe the draft is basically in the right space and .. well.. we're rat holing. So, noting my disclaimer of bias, can we .. move on? Is there real matters of substance left on this one?

Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain

| ns.example.ne.jp | in-bailiwick / sibling domain > example.jp | jp | ns.example.com | out-of-bailiwick > > -- > Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > >> From: George Michaelson <g...@algebras.org> >> feels like a concrete example in a.b.

Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain

feels like a concrete example in a.b.c.example.com terms would help define both in-baliwick, and out-of-baliwick, for the cases. On Wed, Dec 13, 2017 at 9:42 PM, wrote: > Thanks. > > terminology-bis-08: > | In-bailiwick: An adjective to describe a name server whose name is

Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel

I support adoption of this work. Its a sensible, simple proposal which has immediate benefit, and can be used by anyone to test the ability of their nominated resolver to recognise specific keys, and their trust state. I believe as a community, at large, we need code deployed into the resolvers

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

Stephane, I don't entirely understand your response. old systems can never understand new code point assignments, or know what to do with it, no proposed change can alter this. Middleboxes dropping unexpected things will hit almost any proposed modification of packets in flight. Basically, I

Re: [DNSOP] Remarks about draft-wkumari-dnsop-internal-00

It's not sensible to presume the action of an independent decision-making body. It's sensible to discuss it, but it should only inform our own process logic, not decide it categorically (I think) I might share your expectation of the outcome, but I would hesitate to reject a draft on a

Re: [DNSOP] Status of "let localhost be localhost"?

A possibly stupid random thought: is there a strong barrier in *all* kernels which enforces 127.0.0.0/8 and ::1 to actually *have* to be local? The 240/4 problem is 5-6 lines of code in *some* UNIX. It wasn't in any sense globally applied. I suspect localhost is somewhat more strongly coded, but

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

my next draft will definitely include "I'd like to thank Mark Andrews for hitting me with a cluestick repeatedly WAIT WAIT WHY IS THE ORCHESTRA STARTING OH MAN" On Wed, Jul 26, 2017 at 10:11 AM, Mark Andrews wrote: > > In message >

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

read, support adoption. suggest that favourite band sections be marked 'RFC-ED REMOVE' because the last time somebody thanked their mother, the backing band, their agent, the producers, the other candidates for award... it wound up on the ietf list and we don't want to go there. I am unsure

Re: [DNSOP] The DNSSEC club and surprises (was Re: New draft: Algorithm Negotiation in DNSSEC)

A fine bit of epistemology lies in the question: is it the same certificate, if you re-issue it with the same keys? No, because it has a different serial. but the crypto doesn't care, its the validation which cares which is a product of the crypto. so validation cares but cryptographic functions

Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption"

Read, support. This is a useful addition to document how to do something. Now, the 'outer' question of the value of reverse-DNS label binding, thats a different conversation. I can well imagine a bunch of bikeshed-painting, but lets focus on this as a technique for specifying programmatic

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

ldw...@gmail.com> wrote: > Hi, > > On one specific point: > >> On Apr 3, 2017, at 9:02 PM, George Michaelson <g...@algebras.org> wrote: >> >> Lastly, I think the IAB note pretty strongly goes to 'we dont do that >> any more' and I think the draft at the bare

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

to the DNS; delegated or not delegated via ICANN; would you reference the IAB document? If not, why not? -George On Tue, Apr 4, 2017 at 11:26 AM, Brian Dickson <brian.peter.dick...@gmail.com> wrote: > In response to the latest comments by Paul Hoffman and George Michaelson, > I'd

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

On Mon, Apr 3, 2017 at 8:13 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote: > On 3 Apr 2017, at 18:02, George Michaelson wrote: > >> The only reference to ICANN delegation process is in an [Ed: note] >> which feels to me to be wrong: its a first class issue, and should

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

off...@vpnc.org> wrote: > On 3 Apr 2017, at 17:27, George Michaelson wrote: > >> isn't this OBE and it's alt.arpa now? > > > No. > >> Serious question btw. I do not think that this document can proceed >> without significant re-drafting to a 2LD if that is t

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

isn't this OBE and it's alt.arpa now? Serious question btw. I do not think that this document can proceed without significant re-drafting to a 2LD if that is the case. G On Sat, Apr 1, 2017 at 3:17 PM, Stephane Bortzmeyer wrote: > On Sun, Mar 12, 2017 at 07:20:55PM -0400, >

Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.

Thank you for a quick, informed and above all open decision Terry. -George On Thu, Mar 30, 2017 at 3:54 PM, Ted Lemon wrote: > Thanks, Terry! I know this wasn't a fun discussion, but it is good to get a > clear answer that sets or expectations, so thanks for that! > >

Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.

sign it with a bad key or bad DS. this goes to SERVFAIL and its NXDOMAIN. -G On Wed, Mar 29, 2017 at 9:48 AM, james woodyatt wrote: > Hi Terry, > > Clarifying questions here... > > On Mar 28, 2017, at 12:32, Terry Manderson > wrote: > > > My summary

  1   2   3   >