[DNSOP] Re: Side Meeting - DNS Load Balancing
I hold that ietf docs are pretty good at normating behaviour seen to be used. Post fact "this is how it is" seems to work. They're pretty terrible most of the time at ending behaviour not seen to be directly harmful to making money. They're functionally useless at wish fulfilment. CDN operators would want to ask a lot of questions. Not all of them would be entirely self interested. G ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
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 Feb 2024, at 15:53, George Michaelson wrote: >> > >> > 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. >> >> Sure there are a lot of places where this should be done. This is going >> to cover DNS. > > > Yup, and although Mark and I have been mulling this for DNS for a number > of years now, the general principle has also been discussed elsewhere (see > the references to greasing) and RFC 8701 describes greasing for TLS. > > We should track that work too, but this draft can focus on the DNS use case. > > Shumon. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 not to what-if the downsides, but I can imagine there would be an initially high rate of failure which causes log flows, threat analysis feeds and some consequent damage. That would have to be a "lesson learned" and then we pass through to a better understanding of which bits in a header are mutable and should not be tested as fixed value fields. Nice, small draft. -G On Tue, Feb 27, 2024 at 10:29 AM Shumon Huque wrote: > > Hi folks, > > Mark Andrews and I have submitted a new draft on 'Greasing Protocol Extension > Points in the DNS'. > > https://www.ietf.org/archive/id/draft-huque-dnsop-grease-00.html > > (datatracker link: > https://datatracker.ietf.org/doc/draft-huque-dnsop-grease/ ) > > We'd like to see if there is interest in working on this. On list and > in-person (IETF119/Brisbane) discussion welcome. > > Shumon (and Mark). > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 it doesn't need to be explicit in this document, its a redundency, and adding language to address this is like patching 8806 as a side effect, which we don't need to do: in fact, it has risks. Better to leave it out. -G On Tue, Jan 9, 2024 at 11:55 AM Tim Wicinski wrote: > > All > > > This starts a Working Group Last Call for draft-ietf-dnsop-rfc8109bis > "Initializing a DNS Resolver with Priming Queries" > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc8109bis/ > > The Current Intended Status of this document is: Best Current Practice > > Please review the draft and offer relevant comments. > > For WGLC, we need *positive support and constructive comments*; lack of > objection is not enough. > So if you think this draft should be published as an RFC, please say so. > > If you feel the document is *not* ready for publication, please speak out > with your reasons. > > > This starts a two week Working Group Last Call process, and ends on: January > 22, 2024 > > thanks > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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, having the definition of this use of NOTIFY wired down for its protocol elements and behaviours, I think thats important. I fully expect the actual endpoint to be OOB. I don't think it has to be in band but I don't mind if there is an RR which handles in-band, but to me that isn't the main point: the main point is knowing its a general expectation I can do this to parent/publisher when I need to, and what protocol it looks like. Maybe I am missing the point. Sure, CDS was all about in-band, but to me, NOTIFY is mechanistically about a HOW not a WHERE. HOW do I format records to make a push event happen. WHERE is between me and my parent. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 lifetimes/validity intervals at large, but you probably need something which can sustain the long delay component here. The absence of repudiation in this model (which was conscious and deliberate as I understand it, rejecting CRLs) means there's no easy mechanism to say "I changed my mind" over long lived things. Long ago, Australia operated a national DNS model which had a 9600 "dns & ntp only, munnari mostly" link behind it, which allowed one node to sync and certify into the root. It wasn't formal, it was self policed, and it pre-dated widescale IP connectivity (from memory, 3 or 4 universities in Melbourne plus the CSIRO had access) -which meant we could get on with using IP in a local context but remain connected to the namespace through a thin long wire. I'm not sure it actually had any advantage over a periodic re-sync from a zone state, other than being 'the IPv4, just a bit constrained' This isn't the only proposal in name to address processes which harks back to HOSTS.TXT, I am sure others have (it may be I have been reading other things in the same space about interplanetary internet) -And maybe the way forward is to focus on the complete zone, and signed states (ZONEMD?) over the complete zone which could establish trust, and not demand new/different TA structures? -G On Mon, Oct 9, 2023 at 5:18 AM Marc Blanchet wrote: > > Hello, > The primary use case of this draft is the deployment of naming > infrastructure on celestial bodies networks, but could be applied for other > use cases. > > Would love to get people reviews and comments. > > Marc. > > Début du message transféré : > > De: internet-dra...@ietf.org > Objet: New Version Notification for > draft-many-dnsop-dns-isolated-networks-00.txt > Date: 8 octobre 2023 à 15:16:10 HAE > À: "Marc Blanchet" > > A new version of Internet-Draft draft-many-dnsop-dns-isolated-networks-00.txt > has been successfully submitted by Marc Blanchet and posted to the > IETF repository. > > Name: draft-many-dnsop-dns-isolated-networks > Revision: 00 > Title:Domain Name System in Mostly Isolated Networks > Date: 2023-10-08 > Group:Individual Submission > Pages:7 > URL: > https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.txt > Status: > https://datatracker.ietf.org/doc/draft-many-dnsop-dns-isolated-networks/ > HTML: > https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-many-dnsop-dns-isolated-networks > > > Abstract: > > This document lists operational methods to enable local DNS name > resolving on an isolated network, where that network have > intermittent reachability to Internet and/or have very long delays, > disabling the real-time query and response flow to the authoritative > name servers on Internet. > > > > The IETF Secretariat > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] what could we do with 15 unused bits of QDCOUNT?
I don't agree. My reasoning is that signals in the first 576 bytes are more likely to pass through non-conforming systems based on length alone. There is also John Scudder's observations on fast-path and slow-path processing: if its inside the state you latch EARLY when you see the packet, its far more likely to avoid CPU stalls and get done in firmware or hardware. (probably not strictly applicable, but I go to "flag early, flag often") But, for other reasons raised by other people, I concur that these bits are excluded from use because we don't have time travel and middleboxes 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.. 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 wish were signalled from client to server. > > > > "I am new code" > > "I am at least not ancient code" > > "I'm the same as that other guy you saw over " > > "I like TCP and want to do a persisting session" > > "tell me if you are doing a|b|c|d" > > "I like chocolate and want a pony" > > > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > > > (I deliberately didn't put this in the draft- post from Ray so as not > > to pollute an objective discussion of what it is or is not the value > > proposition) > > > > clue-stick hits welcome. Avoid the stomach. > > > > -G > > With a maximum length QNAME inside a UDP query packet there are slightly > under a couple thousand bits available for EDNS. Those bits at the end > of the packet are easier to get to, ecosystem-wise, so if those use > cases are worthwhile they should probably be done with EDNS. > > -- > Robert Edmonds ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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. I posit 3 bits would be plenty. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[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 wish were signalled from client to server. "I am new code" "I am at least not ancient code" "I'm the same as that other guy you saw over " "I like TCP and want to do a persisting session" "tell me if you are doing a|b|c|d" "I like chocolate and want a pony" maybe the truth is, we've got 15 bits of zero in the header forever, amen. (I deliberately didn't put this in the draft- post from Ray so as not to pollute an objective discussion of what it is or is not the value proposition) clue-stick hits welcome. Avoid the stomach. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 Michaelson > wrote: > > I know, I could submit these to the PSL website directly. > > > I think anybody can submit anything they want, but the PSL volunteers have > quite a strict set of internal guidelines for what they will accept. See > https://publicsuffix.org/submit/ for some details. I have helped some > TLDs with the github dancing required to maintain their data before and my > experience is that these guidelines are taken seriously. > > The following ccTLD are in ISO3166 but not in the PSL: > > > Many of the domains you mention are in fact included in the PSL but the > policy boundary is not directly below the top-level label. There's a policy > boundary below com.bd and net.bd, for example, but not directly below bd, > and this is reflected in the current list. Not all TLDs have the same > kind of policy boundary (if they did, arguably we would need the PSL). > > Of the remaining domains most are not active, which means in practical > terms there is no policy to publish, so the gap in the PSL seems entirely > accurate. For example bq is present on iso 3166-2 but is not delegated from > the root zone. > > The only TLD from your list that is delegated and doesn't seem to publish > a policy in the PSL is er. It seems hard to find definitive policy about > registration under er in general, not just on the PSL, so again perhaps the > PSL is reflecting reality quite accurately. > > Operationally, much though I dislike the PSL (for entirely subjective > reasons I might add,mostly around governance and ancient history) it > exists, no matter what I think about it. So, given it exists, systems > are coded to behave against it, and not having SOME ccTLD (and I would > posit gTLD) on it, means they don't match as "first class citizens" > the behaviour the PSL brings. > > > Checking the list you included in this message seems to suggest that all > ccTLDs that have policy to publish have already done so. Unless I > misunderstand you, it doesn't seem like there is a problem here to solve. > > > Joe > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] should all ccTLD be on the Public Suffix list?
so some TLD don't. But also some ccTLD are using notation which probably doesn't matter much, but confuses me because it is wildcarded ONLY where other ccTLD put both the bare TLD and the wildcard (as noted before) look, there's nothing to see here. my confusion is not an industry wide problem. ccTLD aside, ICANN has contract levers with gTLD and if there was reason to tweak the lever they would, and thats not "our" job. my concerns with the PSL governance aren't relevant either. I am sure it was purposeful. I don't have to like things for them to provide upsides. -G On Wed, Jul 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 should be on it? > > no. as we learned from delegation-only, some TLDs don't. > > i see ~36mil unique A RRsets in *.family passive dns, ~16mil unique > RRsets, and ~155kilo MX RRsets. > > far fewer in *.museum, but still, present. > > the PSL wasn't created without a reason. > > -- > P Vixie > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[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 the other ccTLD in iso3166 appear to be on it. As well as the usual non-ISO3166 suffixes like EU and UK. I could have asked this on dns-operations, my wondering here is that maybe we need to suggest to ICANN that it's a formalism? Operationally, much though I dislike the PSL (for entirely subjective reasons I might add,mostly around governance and ancient history) it exists, no matter what I think about it. So, given it exists, systems are coded to behave against it, and not having SOME ccTLD (and I would posit gTLD) on it, means they don't match as "first class citizens" the behaviour the PSL brings. I could also understand a pushback "somebody else's business" or "take it up with ICANN directly there's no IETF in this" as well as "the CCTLD self manage, nobody tells them what to do" (the PSL is discussed from time to time here) cheers -George ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 lame "is" (or rather "was" since we're deprecating it) cheers, and thanks for the work on this everyone concerned. -G On Tue, Jul 18, 2023 at 8:40 AM Benno Overeinder wrote: > > Dear WG, > > With the DNSOP interim meeting last June, we reworded the definition of > "lame delegation". This new definition of "lame delegation" has been > shared on the mailing list and included by the document authors in the > latest revision of the rfc8499bis draft, > https://author-tools.ietf.org/iddiff?url2=draft- ietf-dnsop-rfc8499bis-08. > > This one-week Working Group Last Call is only about the definition of > "lame delegation". As mentioned above, the wording is the result of the > interim meeting, where it was identified that the original definition of > "lame delegation" does not cover current operational issues and that > more precise terms are preferred. > > We believe the current wording reflects the views shared on the mailing > list over the past two months, and we ask for confirmation. If there > are strong objections to the current definition in revision -08, we > return to the original rfc8499 definition. Regardless of the outcome, > after this WGLC the document will be forwarded to the IESG for publication. > > This WGLC will end on Monday, 24 July. > > Best regards, > > Benno > for the DNSOP co-chairs > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 the subject is the NS which is listed as authoritative but isn't serving. OK so you can qualify "lameness" to "the zone is lame" or "the zone has some lame NS" or "this NS is lame for the zone" -But they have different subjects and objects. what is "this" in each case? different. And not serving has (at least) two forms: you respond to 53 but reply incoherently if at all about the zone, and you aren't even responsive on 53. I can believe there are more. The objective is to fix it. You are either talking to the parent zone delegates to get something changed in the parent zone, or to the zone NS admin to get something changed at the NS, or to network technicians about why something along the path isn't working for you. So thats 3 cases at least. Yet, we all seem to call this "lame" for some purposes. At least 2x who talked to, at least 2x forms, and at least 2x subjects but one Objective: -- fix it. I don't think we've cohered on a meaning. I respect Paul Vixies intent in giving clear origination of the term to Mark, but I do not agree the term means now what he said decades ago, its clear we don't (in this mail thread) really have a unitary meaning. If we did we wouldn't be here. I don't see how a single paragraph statement without OR ... alternates is going to cover what people patently have been saying "is lame" for some time, not aligning to a single meaning. I liked the proposed paragraph because it had the ".. or not at all" -And yet some people seem determined to say thats the "wrong" bit on the definition. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 > > I like the idea if something goes awry in the responses I am seeing I > > can ask the authority to tell me what SOA serial I should expect to > > see, that has the response state they're giving me for the specific > > query. Thats distinct from ZONEMD which is a DNSSEC signed state of an > > entire zone (assuming it can be done) which is a different class of > > check on zone state related to serial. I like both. They're different. > > That said, you COULD point to ZONEMD in this one in the security > > considerations, but I wouldnt make it normative. It's just another way > > to check the state of a zone. > > > > You're right that we can better state the differences with ZONEMD. > What do you think of adding a paragraph like this in the security > considerations? > >"Please note that ZONEVERSION option can not be used for checking >the correctness of an entire zone in a server. For such cases, the >ZONEMD record [RFC8976] might be better suited at such task. >ZONEVERSION can help identify and correlate a certain specific >answer with a version of a zone, but it has no special integrity or >verification function besides a normal field value inside a zone, as >stated above." > > Thanks, > > Hugo > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 wide to encompass "that FQDN didn't actually resolve" for a listed NS. As it stands it seems to terminate in a belief you have something to ask. It's equally lame to be pointed to this.name.hasnt.been.delegated.alt. as an NS Irrespective I prefer 2). I don't like the dangling fate of 1) I think the lack of agreement is only conditionally true: I think we could reach consensus on 2) if we tried a bit harder. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 really clear and straightforward. It's a debug tool. It isn't going to be something I expect to use, but I like the idea if something goes awry in the responses I am seeing I can ask the authority to tell me what SOA serial I should expect to see, that has the response state they're giving me for the specific query. Thats distinct from ZONEMD which is a DNSSEC signed state of an entire zone (assuming it can be done) which is a different class of check on zone state related to serial. I like both. They're different. That said, you COULD point to ZONEMD in this one in the security considerations, but I wouldnt make it normative. It's just another way to check the state of a zone. The non-transitive thing is about the only point of "well" -but its unsigned data: how could you trust it, if you can't verify through a third (transiting) party? And the draft says this: it's undefined behaviour. I truly think this is that very rare bird: "looks good to me ship it" in 2 WG adopted draft edits. On Thu, Apr 27, 2023 at 1:08 PM Suzanne Woolf wrote: > > Colleagues, > > > This email begins a Working Group Last Call for > draft-ietf-dnsop-zoneversion-02 > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). > > If you've reviewed this document and think it's ready for publication, please > let us and the WG know, by responding on-list to this message. We > particularly need to hear from implementers and operators whether this EDNS > option is implementable and useful. > > If you don't think it's ready, and have specific concerns or suggestions, > please let us know about those too. > > The Last Call will be two weeks, ending on Thursday 11 May. > > Thanks to everyone who's offered comments and suggestions on the draft to > date. > > > Suzanne, Tim, and Benno > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 definition quickly. (I'd be delighted if that wasn't the case btw) -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 ITU asking "the IETF" for feedback on > an IP-related protocol document in 4 weeks.) > > As I’m sure both Harald and Warren can attest, ICANN processes, particularly > those for which a public consensus statement is the desired outcome, tend to > take a teensy bit longer than 4 weeks. Also, given how long it has taken to > get the -alt-tld draft out the door of IETF processes, 4 weeks might be seen > as a bit hypocritical. > > What’s the desired outcome here? The only possible outcome I can imagine that > could come from a 4 week notice period would be for individual entities who > happen to participate in/around ICANN to provide feedback, not for “ICANN” > (whichever facet you might be envisioning) to comment. Is that sufficient? > > Regards, > -drc > > > On Mar 7, 2023, at 10:09 AM, Rob Wilton (rwilton) > > wrote: > > > > Hi, > > > > I wanted to thank the WG, chairs, and authors, for their work and patience > > with me on the alt-tld draft and to let the WG know of the next steps. > > > > Warren and Paul have posted an updated -22 version that addresses my AD > > review comments, and hence I will start a 4-week IETF LC on this version > > shortly (i.e., hopefully in the next couple of days - as soon as the > > liaison statement is good to go). > > > > Wes, Mirja, and the DNSOP chairs, and Harald have helped me craft a liaison > > statement to send to ICANN once the LC has started (which will be sent from > > OPS Area) informing them of the progress of this document, hence also > > providing an opportunity for comments via the standard IETF LC process. > > The extended 4-week IETF LC is to ensure that ICANN have enough time to > > review the document and provide any feedback that they may have. > > > > My hope, and expectation, is that the document will then following the > > standard IETF document approval and publication process. > > > > Regards, > > Rob > > > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft: Compact Lies/Denial of Existence in DNSSEC
My opposition is philosophical and practical. the philosophical part, is that this is a SIGNED ASSERTION by the zone authority. I don't think anything the zone authority says under a signature should be called a lie, because the basis of verification is that its exactly what was intended to be said about the state of the zone. its incoherent, its potentially confusing, it needs to be understood, sure. but I don't see this as a lie. the practical is that I think the IETF/OPS tendency to enjoy "puns" causes huge confusion outside the cognoscenti. The re-use of the word "peer" for instance has caused significant dismay to people in policy or finance space who don't understand that a BGP peer does not mean necessarily a peering zero-cost sum arrangement at layer 8 and 9 (money). -If we use "lie" this freely, then when we want to distinguish these signed lies from the intermediary altering payload on-the-fly we're going to have a problem of comprehension. Having said that, I think I feel like a bit of a party pooper. What in Australia would be called a "wowser" It's not a big deal btw. I'm not going to go to the AD and complain about it or make a fuss at WGLC. I just think.. its the kind of language which may not be helpful in the longer term. cheers George On Thu, Mar 2, 2023 at 7:33 AM Shumon Huque wrote: > > Hi folks, > > We've posted a new draft describing the former "Black Lies" mechanism > for authenticated denial, now renamed as "Compact Lies". > > https://datatracker.ietf.org/doc/draft-huque-dnsop-compact-lies/ > > We are hoping to discuss it here and at IETF116, and see if there is > interest in adopting the work and publishing it. We feel that it deserves a > stable published specification since it is now one of the dominant forms > of authenticated denial deployed amongst the commercial online signers > today (notably Cloudflare, NS1, and Amazon Route53). > > The draft includes the NXDOMAIN/Empty Non-Terminal distinguisher > mechanism 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 separate email thread shortly. This thread can be > used for general comments on the topic of the draft. > > George Michaelson, in private email to me, has expressed the view > that we shouldn't be calling these mechanisms "Lies" any more (I'm > sure he will elaborate if he is inclined). I'm personally okay with that, and > if > there is agreement, we could just call this Compact Denial of Existence, > and discard the "Lies" meme. > > Shumon > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
Oh, I assumed Ted was moving to a formalism which explicitly authorises QDCOUNT > 1 in the public space, and leverages it. If we're not heading there, and there is only a document heading to QDCOUNT is 1 and evermore shall be so, there's no conflict. -G On Thu, Feb 23, 2023 at 10:55 AM 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 I know. > > Ted pointed out a DNS implementation in OpenThread that is based on a > different interpretation of 1035 than (I think) the more usual understanding > reflected in DNS implementation in use in the public DNS. The purpose of this > draft is to highlight some problems with that interpretation and to propose a > consensus interpretation of 1035 (a clarification) so that other people might > avoid them. > > Implementations are free to make whatever choices they want regardless of > what any working group says. OpenThread's approach might work perfectly well > in a constrained environment where the DNS servers receiving queries with > QDCOUNT > 1 are built to suit IoT devices' particular requirements and > assumptions. That doesn't make it a good idea for the protocol in general. > > This draft is not about OpenThread's particular situation; it's about the > base protocol. > > I don't see any conflict, here. > > > Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 both together, most of the time, to come to understanding about this? I'd suggest the existence of oppositional drafts (by intent, in no sense do I see this as personal) -the WG adoption question is moot: we probably need to adopt a problem statement if not the two specifics. Is there room to unify? (I know that may be nonsensical for drafts which oppose intent) I'm asking, because I really hope we can avoid the inevitable appeal process. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 look for it, thats just a cost, I admit. But the question would stand: if we had a way to tell the delegate where the zone cut was above them, would it be useful? I think it has to be authoritative: it has to be signed so it can't be lied about. cheers -G On Thu, Dec 1, 2022 at 3:34 PM Shreyas Zare wrote: > > > On 11/30/2022 6:16 AM, Mark Andrews wrote: > > On 30 Nov 2022, at 00:07, Joe Abley wrote: > > On Tuesday, November 29th, 2022 at 13:37, Peter Thomassen > wrote: > > At the IETF a few weeks back, Johan and I felt a sudden > enlightenment when it occurred to us that the same approach > could be used to reduce scanning cost for CDS/CSYNC scans and > the like, while maintaining low update latency. In fact, the > NOTIFY spec already does allow sending NOTIFY message of other > types. So, we not use that for hinting beyond SOA? > > I have wondered aloud about reusing NOTIFY for other purposes in the past > too. In fact I seem to remember a certain tall Swede referring to > draft-jabley-dnsop-dns-flush as abolutely the worst idea he had ever heard > of, a review which I continue to wear as a badge of pride. > > One question occurs to me after reading your draft: you suggest in a couple > of places that it's easy for a nameserver that is authoritative for a child > zone to know the name of the parent zone. How? > > For example, if a nameserver serves the zone a.b.c.d.child, how does it > determine whether the parent zone is the root, a, a.b, a.b.c or a.b.c.d? It > needs to know in order to find the SRV (or whatever) records that point to > the appropriate NOTIFY targets in the case where the parent zone operator > signals the target. Does it send multiple queries? Does it confirm the > existence of a zone cut in each case by looking for secure delegations or SOA > RRs or both? It seems important to get this right. > > Remove the left most label and query for the SOA record. If you get a SOA > record back in the answer you have the parent zone. If you get a CNAME back > remove one more label and repeat. If you get a NODATA response look in the > authority section for the negative cache SOA record. If it is not present > remove one label and repeat. nsupdate has been doing this for 2 decades now > to determine the enclosing zone for UPDATE requests. There is absolutely no > reason why authoritative servers can’t make such queries all by themselves. > They already make queries to obtain the address of nameservers to determine > where to send NOTIFY messages. > > For a signed zone, finding the parent can be done by resolving for DS with > DNSSEC validation. The name server that returns DS is one of the > authoritative servers for the parent and the RRSIG in the response tells the > parent zone in the Signer's Name. The same name server can then be queried > for SOA to find MNAME for the parent zone. > > Regards, > Shreyas Zare > Technitium > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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?)
Yes, I was both factually and technically incorrect. The best kind. No.. wait.. Your point is well made and important. Nothing is "moving" here and whats happening is IETF Is getting out of being in the space. -G On Wed, Oct 26, 2022 at 11:13 AM David Conrad wrote: > > 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 > https://datatracker.ietf.org/doc/draft-davies-int-historic/. I’m unsure why > you think .INT is moving. Kim can correct me if I’m wrong, but to clarify, > the processing of .INT is not moving: it is and always has been handled by > the IANA team and it will continue that way. The only thing that is changing > is removing the historical “international databases” delegations created when > .INT was (according to RFC 1591) for “organizations established by > international treaties, _or international databases_” (Emphasis added). The > IAB doc from 2000(!) > https://web.archive.org/web/20090822012543/http://www.iab.org/documents/docs/iab-arpa-stmt.txt > (didn’t bother trying to find it on the IAB website — the link on Wikipedia > is wrong) might be illuminating. > > Regards, > -drc > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 anything other than A and > records, you're on your own. The switch to .onion doesn't use > nsswitch, but rather something a couple of levels up in a socket > proxy. > > If people want to splice their stuff into this corner of the domain > name space it's up to them to figure out how to make it work. Said less directly that would be the intent of my proposed sentence or paragraph: "how this works and consequences for other name spaces is not a DNS consideration" but with an element of "... but we're pretty sure there are heaps of problems coming" G > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 > > up to each non-DNS thing to choose which if any of the versions it > > uses and it how it interprets them. > > That feels best to me. > > --Paul Hoffman I don't see how this works in practice for the consequence of control moving to nsswitch.conf, and like processes. This feels like it moves the problem from standards space, to PBCK: Users are going to stuff this up because the difference between AlT and alT is moot to many people. I also don't see how this is going to work for applications-space, given that two app developers in GNS or other spaces may make different interpretations of meaning. I also don't know what the right answer is. I just think this makes as big a problem as it solves, moving the hole around basically. (maybe not helpful) Does this need words which go to the problem? The lack of certainty around ASCII case is a problem which non-DNS uses of .alt will have to confront and manage, the DNS does not constrain the problem, Something like that? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 do I remove gns.alt before resolving? Steven's "what is in SubjectAlternateName and SNI" is a good one too. I keep harping on about the omnibar. Start at the omnibar and a URL and tell me what happens! G On Fri, 19 Aug 2022, 12:18 pm Ben Schwartz, wrote: > > > On Mon, Aug 15, 2022 at 7:36 PM Stephen Farrell > wrote: > >> >> Hiya, >> >> On 16/08/2022 00:22, Paul Wouters wrote: >> > it’s a whole new gold rush. >> I don't get that. The thought experiment(*) is a putative >> .alt setup with FCFS registration for 2LD equivalents and >> where recursives and all DNS servers are expected to barf >> on queries for such names one way or another. I don't see >> what'd attract many people to register names there myself >> but maybe I'm naive. What'd be the attraction? >> > > Perhaps you haven't been following the W3C DID process [1]? The > "registrable .alt" proposal closely resembles the functionality of the DID > "method" system, and you can see the registrations that have poured in > there [2]. I note that some of the registered names already raise some > notable potential for trademark collision or user confusion. > > I agree with Paul Wouters' analysis of this problem space. I would add > that the main functionality of "registrable .alt" is already available by > simply registering the desired names in any open, registrable TLD such as > ".net". I question whether any perceived benefits over the existing DNS > registry system would justify the Very Large Can of Worms that the IETF (or > IANA) would have to manage. > > I haven't fully grasped the DID system yet, but it seems to add a new > meta-namespacing point under a new URI scheme. This strikes me as far more > architecturally sound than trying to claim that a certain slice of domain > names are both unresolvable in the DNS and yet presumptively safe to use in > all the myriad URI schemes and other subsystems that make use of domain > names today. > > Also, I think the mental model of a "resolution plugin" needs more > attention, as it appears to presume the existence of an abstract interface > that does not exist. For example, apps that use DNS increasingly rely on > specific RR Types (e.g. SRV, HTTPS, SSHFP). Shall we demand that all .alt > registrations maintain the full semantics of every current and future DNS > RR Type? > > > [1] https://en.wikipedia.org/wiki/Decentralized_identifier > [2] https://w3c.github.io/did-spec-registries/#did-methods > > >> >> Ta, >> S. >> >> (*) To be clear, I'd have no objection to somewhat more >> onerous registration rules, like RFC required or whatever >> so the above is just trying to understand what makes you >> think there'd be enough registrations to be a problem in >> that particular setup. >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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. (presumably, the remaining F.Q in the FQDN if DN is now .alt So where I was asking "why aren't we talking about mechanisms to do this in omnibar and local control file like nsswitch,conf" you're saying "given these alternate mechanisms exist, how can we assert a global name which can identify itself as being addressed to a specific mechanism for name lookup" In hypothesis, in this model, ALL FQDN we have "now" are in fact FQDN.dns.alt ? The dns.alt being assumed, and not necessary in the default DNS case? I ask, because NOT grandfathering in the current name scheme into a new name scheme (as a child/grandchild) invites problems. If the dns.ALT name is "reserved" then, there can be no confusion in the mechanisms which do ALT service parsing. Basically, "if you do .alt, and if the 2lD under alt become a registry of namespaces/services then you MUST reserve dns.ALT" -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 done in another mechanism. (telling people to move along) but deprecation as BCP, I get. re-using codepoints. Just no, until we have to. decades off. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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:
> >-=-=-=-=-=-
> >
> >as someone who looks at lots of caching resolver logs, you could add .local
> >to this.
> >But even those query loads are not what I consider a problem .
>
> It's not the query loads, it's the data leakage. I gather that the stuff
> that leaks out to public DNS .CORP queries is quite amazing.
>
> R's,
> John
>
> >On Sun, Aug 14, 2022 at 11:06 PM John Levine wrote:
> >
> >> It appears that Stephen Farrell said:
> >> >Works for whom? I think it's entirely possible for the GNU
> >> >people to come up with something they think works that does
> >> >not break anything. Personally, I'm not convinced they're
> >> >right about the first part, but I'm happy enough about the
> >> >second.
> >>
> >> Depends how you feel about .GNS queries escaping into the
> >> real DNS when they don't anticipate all of the ways people
> >> will use their stuff.
> >>
> >> Dunno if they think that's a problem ("you need to configure
> >> your software right") but I am pretty sure that people who
> >> have seen what leaks from .CORP and .HOME believe it would be
> >> a big problem.
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
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 moves from a tech governance space to a vendor decision in 3-6 months. At which point, the additional TA and equivalence to the public suffix list is strong. We're lucky we don't seem to have a vendor who wants to try it, because logistically it would be extremely simple. My point is that gethostbyname() itself is subject to code if/then/else decisions, so the idea names are gated by protocol or functional API spec is really moot. It's a soft agreement only. My own hosts (laptops) still appear to honour /etc/hosts before DNS. I used this in China for gfc reasons. So local override is also strong in this. Would it be a tragedy if unitary namespace ideas die? Would it be a tragedy if a single dominant vendor had a switch? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 https://www.ietf.org/mailman/listinfo/dnsop
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 the value of a unitary namespace as a commons probably always transcended the DNS specifically. We're just in denial what "it" is that we're fighting to defend. DNSSEC made this perhaps more focally clear: the specific value here is (in my opinion) in "which TA do you respect" and how that goes to "which name do you believe" which in this case goes to "which namespace do you prefer, deciding which names to accept" The unitary namespace belief, goes pretty rapidly to "how many distinct, independently managed TA do you want to respect proving names" as a cross product with "when, in which order, and why, and what do you do if they collide or disagree" If GNS is glued into DNS as a sub-arc over a label we understand, the possibility of some unity, fusion of purpose exists. If it squats, or is pushed aside, then that possibility disappears. To me, thats the problem. Not that we're finding this is ugly, or we like or dislike a reserved label like this, or want to never invoke the method we documented to do this thing, or hate ICANN or a hundred other things: its the loss of fusion of behaviour, if we don't come to some sense of agreement in what names are, respecting locators (and addresses) -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 your notes were helpful, a good write up of the "pick the least worst" choices we've arrived at. I increasingly tend to think if somebody in a public interest space had the $ and invested the cost of delegating via ICANN process and handed it over for this purpose to a registry, it would avoid all the pain of trying to document a special-use: Simply get the delegation, burn the $200,000, meet the ongoing opex, and turn it into the space through external process compliance. Basically, the IETF has two problems: it's trying to invoke its rights to request a (non)delegation against its better wishes, and it can't entirely agree (achieve consensus?) inside itself on the wisdom of doing it. Getting it through an external application outside of IETF decision logic and then bringing it into the IETF might be easier, if not cheaper. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 a sign of a problem which demands a different kind of document, not an ISE document. Possibly its an IAB document about the view of the integral namespace and process boundaries around delegation, non-delegation and reservation as they intersect with protocol and operations. Also no-hats. I'm partisan in this, but I think the process question is distinct from the actual topic On Tue, Aug 2, 2022 at 11:30 AM Paul Wouters wrote: > > On Aug 1, 2022, at 08:31, Independent Submissions Editor (Eliot Lear) > wrote: > > > > I do not think the ISE should ignore or be a workaround for RFC 6761 Special > Use Domains. There any many problems with its application and its lack of > application but adding the ISE as a third party along with the IETF and ICANN > doesn’t make this problem easier. > > Alternate names spaces want a “real name”, so either their name or their > mapping will “squats” on the DNS namespace. They won’t use .alt or ._alt > just like they aren’t using alt.onion or gns.onion. > > Paul (as individual) > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 uplift of the credentials for a specific NS instance "inside" any given sub-delegation demands that parent space itself be signed, and that they offer some mechanism to allow NS instances to associate their info with the record. Its the classic "how do I make sure my registrar follows spec and supports this" but instead of being about gTLD and ccTLD its moved into the un-regulated in-addr and ip6 .arpa subspaces, where the registrar in question is an address delegate. Outside of the people who already have mechanisms to do things (the gTLD and ccTLD and the big players and historically vested ISPs and tier-1s) I hazard that few DNS lie in self managed integral address ranges, and most DNS lies in managed, rented, sub-allocated address space. -George On Wed, Jun 22, 2022 at 1:29 PM wrote: > > > > On 22 Jun 2022, at 00:07, John Levine wrote: > > It appears that said: > > -=-=-=-=-=- > > > Hi. > > During a meeting today of ROW (https://regiops.net), the I-D on CDS > bootstrapping by using a DNSSEC-signed name at name server > zone > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/) was > discussed. > In that discussion, it was mentioned that the current draft only supports > out-of-bailiwick name servers; I replied that the > same principle could be applied to in-bailiwick name server by usage of the > reverse DNS zones for IPv4 and IPv6. > > > Urrgh. In principle, you can put anything you want in a reverse zone. > (Send mail to jo...@18.183.57.64.in-addr.arpa. and it'll work.) > > > That's my recollection as well, but as the saying goes, code is law. Although > in this case only registry/registrar and DNS operator are required to > interoperate for the bootstrapping process. > > In practice, I doubt that enough reverse zones are signed or that the > provisoning crudware that people use for reverse zones would work > often enough to be worth trying to do this. I did some surveys of > zones and found that in-bailiwick NS are quite uncommon, only a few > percent of the ones in large gTLDs. > > > I don't expect the IP space used for DNS servers to be managed thru an IPAM > system of sorts. But if one is used, it's unlikely they provision a zone-cut > as required in the draft. > > The prevalence among the overall DNS system is indeed low, but I wonder what > % this represents within services that allow all of DNSSEC, CDS Bootstrapping > and in-bailiwick DNS servers, like Business and Enterprise plans in > Cloudflare: > https://developers.cloudflare.com/dns/additional-options/custom-nameservers/ . > > > Or if supporting this type of DNS servers can help the adoption of this draft > for the 99.9% use case of out-of-bailiwick servers. If not, we could be > adding a new piece to the DNS Camel... > > > > Rubens > > > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 situation in which a failure to include sibling glue leads to a > resolution failure is when there is a sibling glue cyclic dependency. e.g.: > > bar.test. 86400 IN NS ns1.foo.test. > bar.test. 86400 IN NS ns2.foo.test. > > foo.test. 86400 IN NS ns1.bar.test. > foo.test. 86400 IN NS ns2.bar.test. > > A few months back I analyzed the zone files available to me via CZDS for > sibling glue. Out of some 209,000,000 total delegations, 222 of them had > only sibling NS records in a cyclic dependency as above. The domains > ADOBE.NET and OMTRDC.NET is one real-world example. > > The arguments for making sibling glue a MUST are: > > 1. accommodates (the 0.0001% of) domains with cyclic sibling glue. > > 2. simpler to specify, don’t need differing requirements for in-domain and > sibling glue. > > The arguments against are: > > 1. domains with cyclic sibling delegations should be considered “broken” and > not expected to work, perhaps similar to TsuNAME-style external delegation > cycles. > > 2. increases response sizes, truncation probability, and amount of TCP. > > > DW > > > > > > On Oct 11, 2021, at 4:51 PM, Wessels, Duane wrote: > > > > Dear DNSOP, > > > > Changes to this draft from the previous version are as follows: > > > > * Clarified scope to focus only on name server responses, and not > > zone/registry data. > > * Reorganized with section 2 as Types of Glue and section 3 as > > Requirements. > > * Removed any discussion of promoted / orphan glue. > > * Use appropriate documentation addresses and domain names. > > * Added Sibling Cyclic Glue example. > > > > I'd say we still do not have consensus on treatment of sibling glue. > > Section 3.2 currently has the strict requirements with optional more > > lenient requirements in [square brackets]: > > > > 3.2. Sibling Glue > > > > This document clarifies that when a name server generates a referral > > response, it MUST [SHOULD] include available sibling glue records in > > the additional section. If all sibling glue records do not fit in a > > UDP response, the name server MUST [is NOT REQUIRED to] set TC=1. > > > > > > DW > > > > > >> On Oct 11, 2021, at 4:30 PM, internet-dra...@ietf.org wrote: > >> > >> Caution: This email originated from outside the organization. Do not click > >> links or open attachments unless you recognize the sender and know the > >> content is safe. > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> This draft is a work item of the Domain Name System Operations WG of the > >> IETF. > >> > >> Title : Glue In DNS Referral Responses Is Not Optional > >> Authors : M. Andrews > >> Shumon Huque > >> Paul Wouters > >> Duane Wessels > >> Filename: draft-ietf-dnsop-glue-is-not-optional-03.txt > >> Pages : 9 > >> Date: 2021-10-11 > >> > >> Abstract: > >> The DNS uses glue records to allow iterative clients to find the > >> addresses of nameservers that are contained within a delegated zone. > >> Authoritative Servers are expected to return all available glue > >> records in referrals. If message size constraints prevent the > >> inclusion of all glue records in a UDP response, the server MUST set > >> the TC flag to inform the client that the response is incomplete, and > >> that the client SHOULD use TCP to retrieve the full response. This > >> document updates RFC 1034 to clarify correct server behavior. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-glue-is-not-optional/ > >> > >> There is also an HTML version available at: > >> https://www.ietf.org/archive/id/draft-ietf-dnsop-glue-is-not-optional-03.html > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-glue-is-not-optional-03 > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> > >> ___ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 "top") *EXACTLY* what specific language they think we need here. Say the text. All of it (that you want to discuss) as you want it to be in the document. Even if it becomes repetitious, I am struggling to maintain context over the words and what they mean, under the latest edit. cheers -G On Thu, Dec 16, 2021 at 10:09 AM Tim Wicinski wrote: > > > (no hats) > > I feel that "might be useful" leaves the definition still ambiguous. > > I like Paul V's additions on where the glue must reside, and noting that it > will be passed along with transfers. > > tim > > > > > On Wed, Dec 15, 2021 at 6:56 PM Wessels, Duane > wrote: >> >> For me “necessary” is an important distinction and “might be useful” is too >> broad or ambiguous. I have a hard time reconciling the idea that glue is >> not optional with the idea that it might be useful. >> >> DW >> >> >> > On Dec 15, 2021, at 3:18 PM, Ben Schwartz >> > wrote: >> > >> > >> > >> > I like this definition. However, I think it would be clearer to say >> > "useful" instead of "necessary". >> > >> > On Wed, Dec 15, 2021 at 1:18 PM Wessels, Duane >> > wrote: >> > Despite what the subject line says, I’d like to follow up on the >> > discussion about glue from today’s interim meeting. >> > >> > First, I think the definition of glue given in RFC 2181 is problematic in >> > a number of ways. It is overly broad (e.g., "any record ... that is not >> > properly part of that zone” and "any other stray data that might appear”). >> > It essentially says that all non-authoritative data is glue, including >> > NS, which is wrong IMO. >> > >> > If we can ignore what 2181 says, then the question is whether or not glue >> > is limited only to addresses. Historically it has only meant addresses, >> > since those address RRs were required for zones with in-domain name >> > servers. There are some new proposals in DPRIVE to publish more record >> > types in parent zones and have them considered as glue. This has obvious >> > implications server behavior given the glue-is-not-optional draft. >> > >> > On one hand I think it would be a lot simpler to just say that only >> > address records can be glue. But I’m not sure that is defendable given >> > the directions things are going. Here’s a definition of glue that I came >> > up with: >> > >> > Glue is non-authoritative data in a zone that is transmitted in the >> > additional section of a referral response on the basis that the data might >> > be necessary for resolution to proceed at the referred name servers. >> > >> > I also feel like we might be heading in a direction where there would need >> > to be a registry or some standardization of which RR types can be treated >> > as glue. >> > >> > DW >> > >> > >> > ___ >> > DNSOP mailing list >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 address this whole topic again and start fixing the identified issues as > well as tackling the larger "what is a namespace, and how do multiple > resolution systems co-exist?!" topic. > > > > Who's with me? > > If we have the support of the Area Director to work on and finish this > work, I'm definitely up for it, particularly if it doesn't bork the current > queue of work in DNSOP. > > --Paul Hoffman___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 fetch); but > if there's ever been explicit protocol requirement of this, I have forgotten > it. Sorry, but I think this is just an over-reach. There is no necessary reason for a single information model to break. It is about how you do it. The problem of course is transitive links in the tree from one state (signed) to the other (unsigned) and back again, and associated meta data. Arguably, its one information model, one cache, but the DO bit flagging limits what answers you can tell people and you have to reply with SERVFAIL for information you hold, even though you know the next query might well be for the same info without DO force. It may well be logistically simpler to run two caches, but this statement seems to me to be over-stating things. G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 a substantial problem. But then.. the only way out is to BE DNSSEC aware. There's not much choice. I'm not convinced this "glue doesn't have to be validated" thing is true, but the problem latent in this is the recursive time/compute cost of chasing all out-of-baliwick data, to verify its status in DNSSEC. Love to hear other people's POV on this. Maybe it is a false meme on my part? Maybe glue HAS to be checked and validated, no matter what? -G On Wed, Jul 28, 2021 at 2:16 PM John Levine wrote: > > It appears that Paul Wouters said: > >On Tue, 27 Jul 2021, John R Levine wrote: > > > >> Well, OK. How about this? > >> > >> foo.example NS ns.bar.example > >> ns.foo.example 2001:0DB8::000b::1 > >> > >> bar.example NS ns.abc.example > >> ns.bar.example 2001:0DB8::000b::2 > >> > >> abc.example NS ns.def.example > >> ns.abc.example 2001:0DB8::000b::3 > >> > >> def.example NS ns.foo.example > >> ns.def.example 2001:0DB8::000b::4 > >> > >> (I would have gone all the way to ns.xyz.example but it's tine for bed > >> here) > >> > >> We don't try to make NS loops work across zones, so I don't see the point > >> of > >> sorta kinda trying to make them work sometimes. > > > >You still mis thepoint. In the case of def.example needing > >ns.foo.example, the server can just check if it has glue for > >ns.foo.example. It does, so it returns it. It is not going to > >check whether or not this is a silly loop to .xyz.example or > >beyond. There is no point in knowing that. It has an NS record > >pointing to X. It has a glue record for X. So it includes the glue > >record X. > > OK, so I ask for foo.example and I get > > ; answer > foo.example NS ns.bar.example > ; additional > ns.bar.example 2001:0DB8::000b::2 > > Does it check that's the right value for ns.bar.example? How about with > DNSSEC? I suppose > > I still don't see the benefit of trying to make some loops work when we know > that we > can't make cross-zone loops work. > > R's, > John > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 overdue. so +1 to ship -G On Mon, Apr 19, 2021 at 9:17 AM Suzanne Woolf wrote: > > Dear colleagues, > > > This message starts the Working Group Last Call for > draft-ietf-dnsop-tcp-requirements > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/) > > Since this draft has not been recently discussed in the WG, we figure people > might need to swap it back in, and we’re requesting BCP status. So the WGLC > will end in three weeks (instead of the usual two), on 3 May. > > Substantive comments to the list, please. It’s fine for minor edits to go > direct to the authors. > > We’d like to advance this but it needs some active support, so we need to > hear from folks who have found it useful, especially implementers. > > > Thanks, > Suzanne > For the chairs > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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" -otherwise, you cannot say you are primed in the RFC sense. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 that you have the information, now how you get it or how it comes into your resolver. The distinction between shipped states of the root.hints and the actual live mappings of the domain labels inherent in it, to addresses (if you like) I can bypass the hints file ,and use SQL to update my root mapping. I think the intent of "priming" is that you then populate the information from 'inside' DNS. But, again, its only advisory, its not standards enforced is it? I can populate my continuing knowledge of the state of the DNS at the root, or anywhere else, in any mechanism I like. I could periodically FTP the zone files from places, and populate my resolver cache state from these. I could basically "never" forward DNS queries high in the tree, if I felt like making my server do that. Am I "not primed" if I do this? (this mechanism wouldn't support authenticated denial of arbitrary labels, as an example) -G On Fri, Aug 7, 2020 at 12:42 AM Paul Hoffman wrote: > > On Aug 6, 2020, at 4:08 AM, Andrew McConachie wrote: > > > > What does it mean for a resolver to be primed, or for a resolver to not be > > primed? For example, is a resolver considered primed only if it has all > > root server names and IP addresses? 50%? At least 1? > > Excellent questions, two that the WG can certainly consider. Note that it > *is* two questions, the root server names and the associated addresses. > > From the text you quote: > > > Priming is the act of finding the list of root servers from a > > configuration that lists some or all of the purported IP addresses of > > some or all of those root servers. A recursive resolver starts with > > no information about the root servers, and ends up with a list of > > their names and their addresses. > > RFC 8109 indicates that priming means knowing the full set of names and the > full set of addresses. > > > If that were true it would be impossible for the resolver to find anything. > > It definitely starts with some information about the root servers. Maybe > > change "no information" to "this information". > > This distinction is important. A resolver starts with no actual information, > but only meta-information: where to get the actual names and addresses for > the root server. Is there a better way to say this in the -bis document? > > --Paul Hoffman___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 "platform", which is > increasingly being used to identify Internet-wide global companies that > provide multiple consumer services. "Platform resolver" would also convey the > idea that these resolvers are going to be distributed and ubiquitously > available. "Cloud resolver" could have a similar meaning. > > But, as for any terminological bikeshedding effort, you cannot force others > to use the "most correct" term, so it's possibly just a waste of time. You make a useful important point here: an "open resolver" is the superset of "deliberate" and "abused" ones. The concept here is that the intent is deliberate, we need some way to say so. if the intent is not there and is being abused we need some way to say so. I started typing this as "good" and "bad" but we know not everyone believes open public resolver services deliberately deployed ARE a public good, all the time. So I went to deliberate and abused, because there is "I do this by intent" and "it is being done by accident" -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 > actually hinted this was the probable direction, and I think we can > say categorically the dictionary doesn't need updating because there > isn't a sense this concept needs defining in this context within this > WG. > > Many thanks > > -George (not Kuo. Btw, there are five georges at APNIC. hash > collisions happen all the time) > > On Fri, May 22, 2020 at 2:02 PM Davey Song wrote: > > > > IMHO, public DNS is not a technical jargon which needs a DNS terminology > > RFC to record (it collects all DNS definition and terms from other DNS RFC). > > > > The term "Public DNS" or "Public DNS service" belongs to the scope of how > > people provide and operate DNS services to their best interests. There are > > many similar terms, such as Cloud DNS, Dynamic DNS, DNS firewall, and > > many 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 > >> 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 the functional role of a recursive, > >> but to the public, yet somehow not the bad one of an open DNS resolver > >> being abused to do DDoS: its the conscious service offering of a > >> recursive/cache/forwarder in the public view, a declared intent. > >> > >> A Google search lists (some of) them by name and IP. > >> > >> I asked "Dr Johnson" (Paul Hoffman) why it was not in his dictionary, > >> and he said he is but the humble scribe, and words appear in the > >> dictionary when he is directed. > >> > >> What does the WG feel? The definitions of the "elements" of a public > >> DNS service are of course defined. But not (I feel) the "collected > >> whole" which most definitely exists, out there. > >> > >> (if anyone feels this is adequately defined, please correct me and share a > >> URL) > >> > >> -George > >> > >> ___ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] definitions of "public DNS Service"
Thank you all for the responses. This has been very interesting. Paul actually hinted this was the probable direction, and I think we can say categorically the dictionary doesn't need updating because there isn't a sense this concept needs defining in this context within this WG. Many thanks -George (not Kuo. Btw, there are five georges at APNIC. hash collisions happen all the time) On Fri, May 22, 2020 at 2:02 PM Davey Song wrote: > > IMHO, public DNS is not a technical jargon which needs a DNS terminology RFC > to record (it collects all DNS definition and terms from other DNS RFC). > > The term "Public DNS" or "Public DNS service" belongs to the scope of how > people provide and operate DNS services to their best interests. There are > many similar terms, such as Cloud DNS, Dynamic DNS, DNS firewall, and many > 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 >> 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 the functional role of a recursive, >> but to the public, yet somehow not the bad one of an open DNS resolver >> being abused to do DDoS: its the conscious service offering of a >> recursive/cache/forwarder in the public view, a declared intent. >> >> A Google search lists (some of) them by name and IP. >> >> I asked "Dr Johnson" (Paul Hoffman) why it was not in his dictionary, >> and he said he is but the humble scribe, and words appear in the >> dictionary when he is directed. >> >> What does the WG feel? The definitions of the "elements" of a public >> DNS service are of course defined. But not (I feel) the "collected >> whole" which most definitely exists, out there. >> >> (if anyone feels this is adequately defined, please correct me and share a >> URL) >> >> -George >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[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 the functional role of a recursive, but to the public, yet somehow not the bad one of an open DNS resolver being abused to do DDoS: its the conscious service offering of a recursive/cache/forwarder in the public view, a declared intent. A Google search lists (some of) them by name and IP. I asked "Dr Johnson" (Paul Hoffman) why it was not in his dictionary, and he said he is but the humble scribe, and words appear in the dictionary when he is directed. What does the WG feel? The definitions of the "elements" of a public DNS service are of course defined. But not (I feel) the "collected whole" which most definitely exists, out there. (if anyone feels this is adequately defined, please correct me and share a URL) -George ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones
yes. well finessed! keep the SHOULD relax the non-normative language is fine. and I understand not wanting to work on this regarding TTL and meaning against RR. as I said, support adoption. this is good work. its implemented. -G On Tue, May 12, 2020 at 11:07 PM Willem Toorop wrote: > > 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 be authenticated using TSIG > > [RFC2845]." > > > > The use of a categorical *absolutely* and SHOULD is jarring. If this > > is really categorical, the normative enforcement needs to be stronger > > maybe? > > Agree, how about replacing "it is absolutely essential" with "it is key"? > > > I also wondered why the TTL of the RR is not held to be meaningful. It > > felt like there is an opportunity to use this field but thats quibble, > > the document as-is defines it as 0 and thats ok, if perhaps missing an > > opportunity to use a field close to the zone being catalogued for some > > purpose. > > We're staying away from actual configuration properties in this draft on > purpose. TTL could be used to mean something in the dynamics of adding > & removing of zones itself, but it feels a bit fragile to do that to be > honest - we might exclude (or make more difficult) certain setups where > the catalog could not be used by or from the authoritative nameserver > directly. > > -- Willem > > > > On Tue, May 12, 2020 at 3:42 AM Tim Wicinski wrote: > >> > >> > >> All, > >> > >> As we stated in the meeting and in our chairs actions, we're going to run > >> regular call for adoptions over next few months. > >> We are looking for *explicit* support for adoption. > >> > >> > >> This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > >> > >> The draft is available here: > >> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > >> > >> Please review this draft to see if you think it is suitable for adoption > >> by DNSOP, and comments to the list, clearly stating your view. > >> > >> Please also indicate if you are willing to contribute text, review, etc. > >> > >> This call for adoption ends: 25 May 2020 > >> > >> Thanks, > >> tim wicinski > >> DNSOP co-chair > >> > >> > >> > >> ___ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > > > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 is really categorical, the normative enforcement needs to be stronger maybe? I also wondered why the TTL of the RR is not held to be meaningful. It felt like there is an opportunity to use this field but thats quibble, the document as-is defines it as 0 and thats ok, if perhaps missing an opportunity to use a field close to the zone being catalogued for some purpose. On Tue, May 12, 2020 at 3:42 AM Tim Wicinski wrote: > > > All, > > As we stated in the meeting and in our chairs actions, we're going to run > regular call for adoptions over next few months. > We are looking for *explicit* support for adoption. > > > This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones > > The draft is available here: > https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 25 May 2020 > > Thanks, > tim wicinski > DNSOP co-chair > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 validate" baldly basically says "will always be zero" to me -Which I think is what you're saying! _G On Mon, Sep 9, 2019 at 3:04 PM Shane Kerr wrote: > Duane, > > On 2019-09-06 02:01, Wessels, Duane wrote: > > > > With this version the authors feel that it is ready for working group > last call. > > Sorry for a late comment, but I decided to give this one thorough last > read-through. > > I'm a little concerned that the way the Reserved field is described may > make adoption of later versions of ZONEMD difficult. The relevant text: > > 2.1.3. The Reserved Field > > The Reserved field is an 8-bit unsigned integer, which is always set > to zero. This field is reserved for future work to support efficient > incremental updates. > . > . > . > 4. Verifying Zone Message Digest > . > . > . > 7. The Reserved field MUST be checked. If the Reserved field value > is not zero, verification MUST NOT be considered successful. > > > The question is, what can a zone producer do to support both this > version of ZONEMD as well as a new version? Adding a non-zero Reserved > ZONEMD value will break any implementation using this specification. > > I think what would be ideal is for non-zero Reserved values to be ignored.. > > If we treat non-zero Reserved the same as unknown algorithms (that is, > using placeholders) will that be okay? It may complicate generating > compatible ZONEMD in future ZONEMD implementations. With the envisioned > incremental version I think it will be fine; if you want both a > full-zone and incremental ZONEMD then it will indeed be complicated, but > I think probably few zones will need that. I have no idea whether using > the placeholder technique will work for more weird and wonderful later > versions. > > I suppose it is okay to reject the use case and not worry about > compatibility, since we expect the incremental version to be used mostly > for large zones where the current ZONEMD simply won't work... 🤔 > > Cheers, > > -- > Shane > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter
despite my comments at the microphone, +1 for adoption. I think this is good work and should be closed out. "and I still don't like do53" -G On Fri, Aug 2, 2019 at 2:09 AM Tim Wicinski wrote: > > > Back in 2014, we started with "DNS Terminology" which became RFC7719 > Then In 2016, this became a BCP version of "DNS Terminology" which is now > RFC8499 > > Now, in 2109, there is a request to include additional terms to reflect > the new transports DNS is being used over.There is still discussion over > whether all these terms make sense, but the underlying need exists. > > This starts a Call for Adoption for draft-hoffman-dns-terminology-ter > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology-ter/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 15 August 2019 > > Thanks, > tim wicinski > DNSOP co-chair > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 backronym and we are now moving from a terminology to an emerging AI aware ontology of phoneme-building. Can we stick to acronyms which really exist? Is this in a document of substance and I missed something? (very possible) A dictionary model I like (btw) is to show the earliest published use of the form, to set its context and definitions as they emerge. -G On Thu, Jul 25, 2019 at 10:37 AM Tony Finch wrote: > > Paul Wouters wrote: > > > > I dislike Do53, because then we should really have Do53-over-TCP as DoT > > and Do53-over-https as DoH. If we call it "DNS-over-TCP" than really > > what we are doing is running (classic) DNS over TCP, and we shouldn't > > midway the discussion rename "DNS" to "Do53". > > These abbreviations are about identifying the transport that is being used > for the DNS messages. One problem with Do53 is that it isn't specific > about the transport, because it covers both UDP and TCP. But it's a handy > abbreviation for DNS over traditional transports. It doesn't identify DNS > as a whole, just the framing of DNS messages in UDP and TCP. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > a just distribution of the rewards of success > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 the least difficult ones. If > this is fundamentally the data governance issue that I think it is, I think > it would make a lot more sense to align exactly with what is happening in > RDAP, treating self-publication as a new profile and DNS as a possible > transport. If there's data to publish, thinking about transport afterwards > seems far more sensible than inventing a transport and hoping that the data > will follow. > > RDAP profiles are not being discussed in the IETF. I think this is a feature. > Wrong: https://tools.ietf.org/html/draft-harrison-regext-rdap-jcard-profile-00 (admittedly it's the profile for JCARD in RDAP, but in any case there is a convergeance/profile/conformance discussion happening amongst the RIR at least, regarding RDAP data. We're fully deployed) -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 think this is an accurate characterisation of the situation. But having said that, I think the lack of capabilities signalling in DNS, compared to say SMTP or HTTP is a huge problem, and since we have it in those protocols, I feel we have a basis to suggest there is not a blanket ban on this kind of thing in the model. Because of the massive lack of information about elements of the system, the lack of signalling is actually causing a problem. Thats distinct from the hypothetical privacy breach which I acknowledge is a fear, but its a fear which has to be balanced by the problem space we're in. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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: > > > The chairs feel the document has been updated to address > several issues raised from the last meeting, including > some implementations. > > If there is pushback during this call for adoption, we can > take the topic up in Prague. > > This starts a Call for Adoption for draft-wessels-dns-zone-digest > > The draft is available here: > https://datatracker.ietf.org/doc/draft-wessels-dns-zone-digest/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 24 March 2019 > > Thanks, > tim wicinski > DNSOP co-chair > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 relegate discussions about the loss of operator control over the > RDNS control plane > > > Although it’s certainly true that DNS is used as a control plane by many > operators, there is no standard “RDNS control plane.” If you think there > should be, that’s something that the IETF could conceivably work on, but it’s > not something that the DoH working group is obligated to treat as a standard > use of DNS. And I don’t think it’s a topic on which there is consensus in > the IETF. > > The problem with the discussion we’ve been having about DoH and how it > affects your “RDNS control plane” is that we’re talking past each other, not > that the discussion should be had elsewhere. It’s fine for there to be a > discussion, but if there is going to be a discussion, participants need to > engage constructively, and not just fling slogans at each other. > > > ___ > Doh mailing list > d...@ietf.org > https://www.ietf.org/mailman/listinfo/doh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 DNS on UDP more reliable I understand your concern, but I think its cart-before-horse stuff. We *want* shorter crypto sigs. and we *want* more reliable behaviour in unexpected circumstances. We can't get there, without another keyroll. probably two more. -G On Wed, Oct 31, 2018 at 9:40 AM Mark Andrews wrote: > > Name server vendors have NO CONTROL over when down streams pick up changes. > We would like OS vendors to pick up maintenance release sooner than they do. > It would reduce the amount of time we spend diagnosing already fixed issues. > We spend the time back porting fixes so people can have stable interfaces > and fixed code. The more maintenance releases installed the better the bang > for buck that work achieves. > > > On 31 Oct 2018, at 9:38 am, Dr Eberhard W Lisse wrote: > > > > Mark, > > > > but would regular rolls not put vendors into a 'habit' of getting > > updates onto their package managers? > > > > el > > > > On 2018-10-30 23:31 , Mark Andrews wrote: > >> Ultra frequent key rolls are not necessary. It takes years the latest > >> releases of name servers to make it into shipping OS’s. The last KSK > >> worked so well in part because there was a large amount of time > >> between publishing the new KSK and using the new KSK. This allowed > >> name server vendors to publish releases with the new KSK and for those > >> release to make it into some OS releases. > >> > >>> On 30 Oct 2018, at 10:05 pm, Tony Finch wrote: > >>> > >>> Steve Crocker wrote: > >>> > I had advocated early and frequent rollovers for precisely the > reason: keep doing it until it’s easy, so we’re in strong agreement. > >>> > >>> Yes, I would like to see annual rollovers. Keep that hinge greased > >>> :-) > >>> > >>> Tony. > > > > -- > > Dr. Eberhard W. Lisse / Obstetrician & Gynaecologist (Saar) > > e...@lisse.na/ * | Telephone: +264 81 124 6733 (cell) > > PO Box 8421 / > > Bachbrecht, Namibia ;/ > > > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 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 not understanding what we are doing expose me to
> high consequence risk")
>
> Some significant players in DNS conversations have been remarkably
> oppositional to instrumenting the protocol.
>
> I think on balance the question "can your resolver survive the KSK
> roll" is not a massive invasion of privacy, is not a huge impost on
> providers of DNS service, does not interfere with implied rights to
> privacy. We should have better knowledge. We should instrument the
> resolver. The protocol. We should not be forced to do ludicrous things
> to find this out, it should be as innate as the telnet capability
> negotiation, or the HTTP client/server capability negotiation. We know
> how to do these things.
>
> I am statist. I do not pretend states don't exist. I am not a
> libertarian, I am not trumpeting DNS as a tool for individual liberty.
> DNS is a useful functional element which now has consequence when it
> doesn't operate correctly.
>
> We've walked a long way into an industry self-regulation outcome which
> I feel is as consequential as 250v or 50hz, both of which are defined
> parameters with variances and tolerances which people in the
> electricty supply industry have to respect, to remain protected by
> public liability insurance. We should consider the public DNS in the
> same light: If we want to avoid opprobrium over mis-steps in operating
> the root of the DNS, we should adopt a rational posture akin to the
> ones in Power, Water, Sewerage, because thats what we are: a public
> utility function. With public utility liability questions.
>
> Rightly or wrongly DNS is a critical service, which has potential for
> wide impact which is not good. It didn't (this time) at scale, in as
> much as nobody has come forward to say it did: The assumption there
> has been *no* damage, or *no* loss of service feels to me wrong. I am
> (as a gambling man) confident it was low, in as much as 2.3b users
> didn't rise up and grab pitchforks. I bet it was big enough (remember,
> 0.001 of 2.3b is 23,000) that you'd fill an auditorium.
>
> Is 1 in 1000 an acceptable damage rate? is 99.999% unaffected ok? Why
> is 98% not ok? or 97%? Where IS the acceptable damage boundary? Who
> gets to say what will be tolerated as loss in the DNS system, for what
> period of time?
>
> If we want to "plan" for rolls, I think we should stop allowing "not
> on my server" to impede DNS protocol design which would provide
> un-ambiguous signal of capability in the field. And "not in my
> protocol" too. If you offer a service like 8.8.8.8 or 9.9.9.9 or
> 1.1.1.1 you should be in a position of community obligation to be
> completely clear what your posture is towards KSK roll, algorithm
> roll. If you can't support it, you should say so. If that means people
> are advised to TURN YOU OFF that needs to be understood.
>
> If we want to perform algorithm roll, get stand-by keys, we should be
> prepared to argue for the changes which make it easier to do these
> things.
>
> -George
> On Tue, Oct 30, 2018 at 10:29 AM Steve Crocker wrote:
> >
> > I had advocated early and frequent rollovers for precisely the reason: keep
> > doing it until it’s easy, so we’re in strong agreement.
> >
> > Yes, this one actually went smoothly but there was some tension. Aside
> > from any specific improvement, reducing the tension and sense of drama is
> > mainly what I had in mind.
> >
> > Thanks,
> >
> > Steve
> >
> > On Mon, Oct 29, 2018 at 8:23 PM Joe Abley wrote:
> >>
> >> Hi Steve,
> >>
> >> There will always be the potential for tension between the desire to
> >> perform measurement and the need for privacy. In this case it seems to me
> >> that a well-intentioned and competent authority, supported by a
> >> well-intentioned and occasionally-coherent community has a plausible and
> >> sensible desire to understand the configuration of resolvers. I imagine
> >> others might see things differently, however. I suspect that having a
> >> clean signal that can be relied upon is going to at least change th
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 not understanding what we are doing expose me to
high consequence risk")
Some significant players in DNS conversations have been remarkably
oppositional to instrumenting the protocol.
I think on balance the question "can your resolver survive the KSK
roll" is not a massive invasion of privacy, is not a huge impost on
providers of DNS service, does not interfere with implied rights to
privacy. We should have better knowledge. We should instrument the
resolver. The protocol. We should not be forced to do ludicrous things
to find this out, it should be as innate as the telnet capability
negotiation, or the HTTP client/server capability negotiation. We know
how to do these things.
I am statist. I do not pretend states don't exist. I am not a
libertarian, I am not trumpeting DNS as a tool for individual liberty.
DNS is a useful functional element which now has consequence when it
doesn't operate correctly.
We've walked a long way into an industry self-regulation outcome which
I feel is as consequential as 250v or 50hz, both of which are defined
parameters with variances and tolerances which people in the
electricty supply industry have to respect, to remain protected by
public liability insurance. We should consider the public DNS in the
same light: If we want to avoid opprobrium over mis-steps in operating
the root of the DNS, we should adopt a rational posture akin to the
ones in Power, Water, Sewerage, because thats what we are: a public
utility function. With public utility liability questions.
Rightly or wrongly DNS is a critical service, which has potential for
wide impact which is not good. It didn't (this time) at scale, in as
much as nobody has come forward to say it did: The assumption there
has been *no* damage, or *no* loss of service feels to me wrong. I am
(as a gambling man) confident it was low, in as much as 2.3b users
didn't rise up and grab pitchforks. I bet it was big enough (remember,
0.001 of 2.3b is 23,000) that you'd fill an auditorium.
Is 1 in 1000 an acceptable damage rate? is 99.999% unaffected ok? Why
is 98% not ok? or 97%? Where IS the acceptable damage boundary? Who
gets to say what will be tolerated as loss in the DNS system, for what
period of time?
If we want to "plan" for rolls, I think we should stop allowing "not
on my server" to impede DNS protocol design which would provide
un-ambiguous signal of capability in the field. And "not in my
protocol" too. If you offer a service like 8.8.8.8 or 9.9.9.9 or
1.1.1.1 you should be in a position of community obligation to be
completely clear what your posture is towards KSK roll, algorithm
roll. If you can't support it, you should say so. If that means people
are advised to TURN YOU OFF that needs to be understood.
If we want to perform algorithm roll, get stand-by keys, we should be
prepared to argue for the changes which make it easier to do these
things.
-George
On Tue, Oct 30, 2018 at 10:29 AM Steve Crocker wrote:
>
> I had advocated early and frequent rollovers for precisely the reason: keep
> doing it until it’s easy, so we’re in strong agreement.
>
> Yes, this one actually went smoothly but there was some tension. Aside from
> any specific improvement, reducing the tension and sense of drama is mainly
> what I had in mind.
>
> Thanks,
>
> Steve
>
> On Mon, Oct 29, 2018 at 8:23 PM Joe Abley wrote:
>>
>> Hi Steve,
>>
>> There will always be the potential for tension between the desire to perform
>> measurement and the need for privacy. In this case it seems to me that a
>> well-intentioned and competent authority, supported by a well-intentioned
>> and occasionally-coherent community has a plausible and sensible desire to
>> understand the configuration of resolvers. I imagine others might see things
>> differently, however. I suspect that having a clean signal that can be
>> relied upon is going to at least change the extent to which client
>> infrastructure is private.
>>
>> Your last paragraph caught my eye, though. It could be argued that the
>> rollover that just completed was straightforward, at least from a technical
>> perspective. The delays, uncertainty, concern and unfulfilled doomsaying
>> were the things that made it difficult. (It's easy to load that last
>> sentence so that the concern looks ridiculous given the outcome; I am fully
>> aware that the hyperbole would be the thing that looked ridiculous if things
>> had turned out differently.)
>>
>> To what extent does a regular and frequent cadence of key rollovers obviate
>> the need for concern? It seems to me that at some point down the road if a
>> key roll breaks someone's network, it's going to be much easier to point the
>> finger at the
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 reminded by people just how long, deep and *old* the CPE embedded DNS footprint is. Which believes UDP at 512 is a "thing" So basically, yes: you can turn it off. But. Is it wise? -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 into the chain, which would help uncover resolver chains. With IANA registry requests, I may be wrong here, but I thought we had some (boilerplate?) language about how IANA is asked to operate the registry: what criteria judge acceptance. Is it like the OID and basically open (hair oil) slather, or is it only at WG RFC documented request? -G On Wed, Oct 24, 2018 at 4:42 PM Tim Wicinski wrote: > > > Hi > > We've been talking with the authors of Extended Error and now that > they've gotten around to updating the document, and the chairs > feel it is ready for Working Group Last Call. > > We're going to kick this WGLC off this week and run it through IETF103. > This will give folks time during the meeting to bring up any issues > they may have there. > > > This starts a Working Group Last Call for draft-ietf-dnsop-extended-error > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ > > > The Current Intended Status of this document is: Standards Track > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > If someone feels the document is *not* ready for publication, > please speak out with your reasons. > > This starts a two+ week Working Group Last Call process, > and ends on at the end of IETF 103: 9 November 2018 > > thanks > tim > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [v6ops] New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt
I'm not speaking for Owen. I'm speaking for myself. I asked a question. Is this really a long-term defensible thing to do? Do we want HE forever? run a race? thats fine. But, as the thread here notes, the second-by-second conditions which leads one TCP to return SYN-ACK before another can be volatile. run a race, but bias the race towards the one you like? oky.. But once we're beyond a world where the V6 needs the bias, for anyone stuck on the vestigial 4-is-better space, this means they incurred *additional* connection penalty. wheres the control knob? now we're talking about tuning the bias, weighting the sum, tumbling the dice. I thought it was a crap shoot anyway... -G On Wed, Sep 26, 2018 at 3:24 PM Joe Abley wrote: > > What better idea did you mean? > > Being able to select a protocol based on what works best for the > end-user does not seem like a terrible end-state for the end-user, > short- or long-term. > > > On Sep 25, 2018, at 21:25, Owen DeLong wrote: > > > > It was never a good idea. It was a necessary evil (kind of like NAT in that > > regard) to expeditiously deal with a somewhat tenacious (at the 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 > > > > > >> On Sep 25, 2018, at 19:58 , George Michaelson wrote: > >> > >> 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 end-of-life? > >> > >> I used to love HE. I now have a sense, I'm more neutral. Maybe, we > >> actually don't want modified, better happy eyeballs, because we want > >> simpler, more deterministic network stack outcomes with less bias > >> hooks? > >> > >> I barely register if I an on v4 any more. I assume I'm on 6 on many > >> networks. This is as an end-user. I guess if I am really an end user, > >> this belief I understand TCP and UDP is false, and I should stop > >> worrying (as an end user) > >> On Wed, Sep 26, 2018 at 12:49 PM Davey Song wrote: > >>>> > >>>> But in the general case the network cannot. > >>>> Think host multi-homing. > >>> > >>> > >>> Yes or no. > >>> > >>> Generally speaking the races of IPv6 and IPv4 connections on both network > >>> and client are going to be suffered by netowrk dynamics, including > >>> Multi-homing, route flaps, roaming, or other network falilures. > >>> Extremely, a client can get a better IPv6 connection in one second (when > >>> IPv6 win the race), and lose it in next second. In such case, more > >>> sophisticated measurement should be done(on client or network) , for a > >>> longer period, on statistics of RTT and Failure rate, or combinations of > >>> them. But in IMHO, the assumption of HE is relatively stable network for > >>> short exchange connections. The dynamics exits but relatively rare or no > >>> notable impact on HE. So I see no such discussion in RFC8035. > >>> > >>> Davey > >>> ___ > >>> DNSOP mailing list > >>> DNSOP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dnsop > >> > >> ___ > >> v6ops mailing list > >> v6...@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > > > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 end-of-life? I used to love HE. I now have a sense, I'm more neutral. Maybe, we actually don't want modified, better happy eyeballs, because we want simpler, more deterministic network stack outcomes with less bias hooks? I barely register if I an on v4 any more. I assume I'm on 6 on many networks. This is as an end-user. I guess if I am really an end user, this belief I understand TCP and UDP is false, and I should stop worrying (as an end user) On Wed, Sep 26, 2018 at 12:49 PM Davey Song wrote: >> >> But in the general case the network cannot. >> Think host multi-homing. > > > Yes or no. > > Generally speaking the races of IPv6 and IPv4 connections on both network and > client are going to be suffered by netowrk dynamics, including Multi-homing, > route flaps, roaming, or other network falilures. Extremely, a client can get > a better IPv6 connection in one second (when IPv6 win the race), and lose it > in next second. In such case, more sophisticated measurement should be > done(on client or network) , for a longer period, on statistics of RTT and > Failure rate, or combinations of them. But in IMHO, the assumption of HE is > relatively stable network for short exchange connections. The dynamics exits > but relatively rare or no notable impact on HE. So I see no such discussion > in RFC8035. > > Davey > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 at 5:14 PM Shane Kerr wrote: > > All, > > On 2018-09-05 20:45, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Domain Name System Operations WG of the > > IETF. > > > > Title : Reverse DNS in IPv6 for Internet Service > > Providers > > I think that the WG chairs should move this document to WG last call. > > Cheers, > > -- > Shane > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 kind of see this as a triumverate we're grown into now (obviously there are other legs, like security, which we always cut away in launch and then miss. three legged stools are not stable...) But that said, I see this other dimension. we don't run r* commands any more. We don't run UUCP any more. Things which feel baked in turn out to be ephemeral to the core function. So name functions? Up where Brian Trammell is writing drafts? Sure. we need that. What underlying protocol it maps to, Thats a big statement. I don't buy that forever more amen it maps to UDP. If somebody makes DOI work over ICMPv6, I could believe in 25 years we'd migrate to bootstrap of DOI via ICMPv6 and be out of the DNS moment entirely. As it stands, almost all bootstrapp-y application phases accept address literals sorry [address:literals] somehow. Names are only a convenience function, set against routing. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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. de-facto, the world runs on session mediated services. BGP has a session. QUIC is a session with IP address agility. DNS over HTTthing is a session. So there is no necessary end to simple UDP dns, but I suspect over time, most "edge" DNS queries by volume and device, will move to another protocol layer. In email, we used to behave like SMTP was all there was (the ironies, given how many sendmail configs drove DECnet or UUCP or ACSnet or BITNET mail..) We now recognise MTA, MUA, MDA and we live with SMTP/TLS IMAP and POP. Oh, and gmail... On Tue, Aug 21, 2018 at 4:08 AM, Paul Vixie wrote: > > > Andrew Sullivan wrote: > >> >> >> I guess, therefore, I want to ask whether long-standing assumptions >> about the DNS are still true: >> >> • Is the stub::full-service resolver::auth server model just over? > > > no. > >> • Do we think resolution context needs signal? If so, how? > > > yes. DTLS or DOT or DNS Cookies should be the norm, to provide session > context, and make spoofing of responses or of request IP addresses less > trivial. > >> • Is the age of the stub coming to an end? > > > no. > >> • Do we need something like "submission port for DNS", so that >> large concentrated systems can protect themselves and still >> provide service to important resolvers? > > > no. > >> • Does TCP need to become the norm (particularly for the above use >> case)? > > > no. > >> • How can we explain these changes to others working on network >> systems? > > > better documents. it's rare any more to separate concepts and facilities > from the specification itself. that should be common. > >> • Do we have an appropriate venue to discuss these issues, on the >> presumption that they're not really operations issues? > > > no. right now DNS is whatever anybody wants it to be. for example, ECS. > there is no way to say, "this is a bad idea, and won't be standardized." > there cannot be a way to do this, inside the ietf as it is. last time this > was done it was by a "DNS Directorate" put together for that sole purpose, > and it was extremely controversial -- won't scale. > > -- > P Vixie > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Incremental zone hash - XHASH
The intent (to me at least) is to be able to use exterior fetch, *not* DNS, to source this as a file. curl. wget. ncftp. rsync. the "thing" is a file object. It almost certainly is in near-canonical sort order already. Its a stream of characters, probably in bind-normal form. If you can compute the path through the labels and the chain of NSEC regions and the expected hadda-yadda-dadda.. you don't *need* a digest. If you have a digest, and its already in near canonical order, then *cost* to compute "is the file exactly as the publisher wrote it" is low. And, since its a signature under the ZSK, its not just "its as the publisher said" its "the publisher knows the ZSK" which is strong enough to say: "just load it" So, I ask: is this incremental method applicable to this model? Sure, works for giant zone. What about a root zone? Do I need this? Also.. glue. -G On Fri, Jul 20, 2018 at 6:31 AM, Mark Andrews wrote: > Rather than having a full zone hash this can be done as a chain > of hashes (XHASH). > > The XHASH would include all records at a signed name (where a signed > name is NOT an NSEC3 name) up until the next signed name (where a > signed name is NOT a NSEC3 name) in DNSSEC order similar to ZONEMD. > If there is a NSEC3 record and its RRSIGs in this range it is included > in the hash computation. Where a NSEC3 record matches the name of a > record that exists in the zone it is hashed with that name. The record > type appears at both top and bottom of zone similar to NS. > > The chain is only deemed to be complete if there is a hash record at > the zone apex. This allows for incremental construction and destruction > of the XHASH chain similar to the way the presence of NSEC at the zone > apex indicates that chain is complete. > > If there are records that are not at or under the zone apex they are included > in the final XHASH of the zone sorting from the zone apex to the end of the > namespace then from the start of the namespace to the zone apex. Such records > at not normally visible to queries other than AXFR/IXFR. AXFR/IXFR permit > such > records. > > XHASH would allow for UPDATE to incrementally adjust the chain without > having to hash the entire zone at once. > > XHASH would allow for a slave server to verify a zone is still complete > after a IXFR by just checking the areas of the zone impacted by the IXFR. > > e.g. > > example.com SOA > example.com NS ns.example.com > example.com DNSKEY … > example.com NSEC a.example.com NS SOA RRSIG NSEC DNSKEY XHASH > example.com XHASH … > > a.example.com NS ns.a.example.com > a.example.com NSEC b.example.com NS RRSIG NSEC XHASH > a.example.com XHASH … > ns.a.example.com A … > > b.example.com NS ns.b.example.com > b.example.com NSEC ns.example.com NS RRSIG NSEC XHASH > b.example.com XHASH … > ns.b.example.com A … > > ns.example.com A … > ns.example.com … > ns.example.com NSEC example.com A RRSIG NSEC XHASH > ns.example.com XHASH … > > Each of the groupings shows which records plus RRSIGs that are > included in the XHASH calculation. > > To prevent removal/introduction of RRSIGs of XHASH records a DNSKEY > flag bit is be needed to indicate which RRSIG(XHASH) should/should not > be present once the chain is complete. The same applies to RRSIG(ZONEMD). > > Verification of a AXFR would be slightly slower than with ZONEMD as there > are more RRSIG records to be processed, > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
What I want is the nexus of OOB "file" form zone download and integrity check which is cheap to implement signer and receiver. I was on PGP. Duane has taken me to an RR which is a sequenced, canonicalized digest, which then is under the ZSK sign of the zone. For the root, it feels doable. For Com, nothing but a cipher-block-chain model of intermediates is going to scale but a single file download and integrity check was always going to fail there. I know you're talking in-band download: I am targetting out of band "file" download. Its a model. It works. Its useful. The least dependencies and easiest path is what I seek, Olafur drove to a new keying regime and external signatures. Duane has taken me back to "you can use what you have, if you will canonicalize the file to make the RR for a digest" -G On Tue, Jul 10, 2018 at 12:01 PM, Mark Andrews wrote: > > >> 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 method to take zone, re-canonicalize (its the >> DNSSEC order) and check the digest >> >> * since the RR is covered by the ZSK signing, the entire zone is >> understood to be in the state the publisher had when they made the >> digest. >> >> * if you download a zone file, with this RR, you can re-canonicalize >> and check easily. >> >> You have to have a DNSSEC ta over the keys used come what may, but >> this looks like a mechanism which given an out of band TA has 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 > > The problem with what is currently there is that it requires the *entire* > zone to walked on every dynamic update to recompute the hash. That has > always been the primary objection to SIG(AXFR). > > We can do the hashing (and signing) on much smaller increments. > > We could sign each RRset that is not already signed (GSIG) in the zone and > introduce a glue NSEC like record (GSEC) to prevent those RRsets being > removed. > > We could hash larger collections of RRsets but smaller than a the whole zone. > That is what XSIG that I proposed earlier does. It hashes the currently > unsigned zone data and prevents its removal from the zone. I don’t care if > it is XSIG or XHASH which is then signed. Mathematically they are the same. > This mechanism works with OPTOUT and NSEC3 as well as NSEC but does require > the unsigned delegations to be hashed if enabled. > > Mark > > > >> On Tue, Jul 10, 2018 at 10:05 AM, Wessels, Duane >> wrote: >>> George, >>> >>> >>>> On Jul 9, 2018, at 4:36 PM, George Michaelson wrote: >>>> >>>> There's arguments both sides about cross signing, counter signing and >>>> independent self-signing. If you want to promote out of band zone >>>> exchange, it has to be signed. The key it signs with is immaterial if >>>> you either direct knowledge of the PK in a PKI, or accept a trust >>>> anchor relationship over it, or a web of trust. >>> >>> I'm not here to promote out-of-band distribution, but I think its going >>> to happen (especially for the root zone) and I want something that works >>> just as well for in- and out-of-band distribution. >>> >>> I think it makes sense that name server software, whether recursive or >>> authoritative, can use a technique like this to verify zone data, whether >>> it is loaded from disk or received over the network. >>> >>> The key may be immaterial, but I think the barrier to implementation is >>> much lower if it can be done with what we already have (DNSSEC) rather than >>> having to drag something like PGP in. >>> >>> >>> >>>> So do you prefer (for instance) that the ZSK be used outside of DNSSEC >>>> to sign a detached signature over the file, irrespective or content >>>> order, if the file is to be made available? >>> >>> Sorry I don't quite follow. What we're suggesting is not a signature over >>> the file/data, but a hash over the data, which in turn can be signed. >>> >>>> Because if you basically >>>> prefer its *not signed* for this mode of transfer, you've stepped >>> >>> For me the mode of transfer is irrelevant. My goal is to secure the data, >>&g
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
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 method to take zone, re-canonicalize (its the DNSSEC order) and check the digest * since the RR is covered by the ZSK signing, the entire zone is understood to be in the state the publisher had when they made the digest. * if you download a zone file, with this RR, you can re-canonicalize and check easily. You have to have a DNSSEC ta over the keys used come what may, but this looks like a mechanism which given an out of band TA has 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 Michaelson wrote: >> >> There's arguments both sides about cross signing, counter signing and >> independent self-signing. If you want to promote out of band zone >> exchange, it has to be signed. The key it signs with is immaterial if >> you either direct knowledge of the PK in a PKI, or accept a trust >> anchor relationship over it, or a web of trust. > > I'm not here to promote out-of-band distribution, but I think its going > to happen (especially for the root zone) and I want something that works > just as well for in- and out-of-band distribution. > > I think it makes sense that name server software, whether recursive or > authoritative, can use a technique like this to verify zone data, whether > it is loaded from disk or received over the network. > > The key may be immaterial, but I think the barrier to implementation is > much lower if it can be done with what we already have (DNSSEC) rather than > having to drag something like PGP in. > > > >> So do you prefer (for instance) that the ZSK be used outside of DNSSEC >> to sign a detached signature over the file, irrespective or content >> order, if the file is to be made available? > > Sorry I don't quite follow. What we're suggesting is not a signature over > the file/data, but a hash over the data, which in turn can be signed. > >> Because if you basically >> prefer its *not signed* for this mode of transfer, you've stepped > > For me the mode of transfer is irrelevant. My goal is to secure the data, > not the transfer. > >> outside the model: you now demand the file is checked on load, element >> by element, against the TA, rather than being integrity checked by a >> MAC signed by the issuer, which permits eg direct binary loadable, or >> other states. > > We're not demanding anything (MAY/SHOULD vs MUST) but what we propose is, as > you say, MAC signed by the issuer. > > DW > > >> >> -G >> >> On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane >> wrote: >>> >>>> 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 then.. >>> >>> Currently in the zone digest draft DNSSEC is not mandatory. That is, the >>> zone >>> needn't necessarily be signed and a receiver need not perform the >>> validation if >>> they don't want to. >>> >>> Even without DNSSEC the digest gives you a little protection from >>> accidental corruption. But not from malicious interference of course. >>> >>> It seems kind of silly to me to double up on public key cryptosystems. We >>> already have keys attached to zones and software that generates and >>> validates signatures. >>> >>> DW >>> > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
There's arguments both sides about cross signing, counter signing and independent self-signing. If you want to promote out of band zone exchange, it has to be signed. The key it signs with is immaterial if you either direct knowledge of the PK in a PKI, or accept a trust anchor relationship over it, or a web of trust. So do you prefer (for instance) that the ZSK be used outside of DNSSEC to sign a detached signature over the file, irrespective or content order, if the file is to be made available? Because if you basically prefer its *not signed* for this mode of transfer, you've stepped outside the model: you now demand the file is checked on load, element by element, against the TA, rather than being integrity checked by a MAC signed by the issuer, which permits eg direct binary loadable, or other states. -G On Tue, Jul 10, 2018 at 7:47 AM, Wessels, Duane wrote: > >> 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 then.. > > Currently in the zone digest draft DNSSEC is not mandatory. That is, the zone > needn't necessarily be signed and a receiver need not perform the validation > if > they don't want to. > > Even without DNSSEC the digest gives you a little protection from accidental > corruption. But not from malicious interference of course. > > It seems kind of silly to me to double up on public key cryptosystems. We > already have keys attached to zones and software that generates and validates > signatures. > > DW > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 supporting protocols. Some people hate the idea of outside dependencies. You see this in TLS, not wanting to dive into DANE and DNS derived keying materials. Please, not rsync. I live in another domain where rsync is used, and its horrible. HTTPS is fine I think. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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* is signed by *known key* is workable. wow. Firstly, I thought canonicalization was a given: we have definitions of canonical zone order for other reasons (NSEC*) don't we? secondly, I absolutely (and no sarcasm implied or intended, I really mean it) applaud the pragmatism. If we can move to a world which accepts the root is a resource which can routinely be fetched out of band, validated out of band, and then locally bound to a DNS server, we've probably moved on. in-band is great. but, sometimes, its really hard. 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 then.. -G On Mon, Jul 9, 2018 at 10:28 AM, Olafur Gudmundsson wrote: > > > On Jun 22, 2018, at 6:58 AM, Petr Špaček wrote: > > On 21.6.2018 22:31, Hugo Salgado-Hernández wrote: > > On 22:09 21/06, Shane Kerr wrote: > > Dne 1.6.2018 v 12:51 Shane Kerr napsal(a): > > Hmm, can you share some details about your experience? > Did you find out when the data corruption took place? > a) network transfer > b) implementation bugs (e.g. incorrectly received IXFR) > c) on disk > d) some other option? > > > I don't know. I have seen incorrectly transferred zone files both in > BIND > and NSD slaves. IIRC our solution was to include sentinel records in > the > zone files to spot problems, take the node out of service, and force a > re-transfer. This of course won't work if you are slaving zones that > you do > not control, and it doesn't prevent a small window of time when the > servers > are operating with broken zones. TSIG was being used. > > > We have also seen broken transfers between secondaries. Our solution > is to dump the zone after transfer, calculate a hash and compare. We > would benefit from having a ZONEMD record inside the zone. > > > If the zone got broken during TSIG-secured transfer then it was not most > probably not caused by network problem because TSIG would have caught that. > > Honestly I do not think it is worth the effort because all the > complexity does not help to prevent implementation bugs, I would say it > even increases probability of a bug! > > What is left is bug on auth and/or slave sides and in that case there is > no guarantee that > a) master did not compute ZONEMD from already broken data > b) slave verification of ZONEMD actually works > > > If we wanted to catch problems with implementation we need something > which is outside of the DNS stack we are attempting to check, be is > simple checksum or some fancier crypto. > > I can easily imagine OPENPGPKEY RR located at _zonefile.apex.example > node and an utility which would extract OPENPGPKEY RR from the zone file > and verify that the zone file signature (either detached or in .gpg > file) can be verified using that key (+ add DNSSEC into the mix if you > wish). > > -- > Petr Špaček @ CZ.NIC > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > > > +1 > I spent lots of time earlier this century along with Johan Ihren trying to > figure out how to > secure the transfer of a particular zone (the root) to any resolver. > The only sane way is to not transfer the zone over AXFR as any intermediary > can mess with the zone contents mostly in the case of “glue” records, > thus transferring the zone over HTTPS or RSYNC with a PGP signature over the > zone file is the only viable solution going forward. > > > Historical background: SIG(AXFR) was rejected because it required putting > the zone into canonical order and calculating the signature, > in the case of dynamic update this is a real expensive operation, thus we > got rid of it. > > Olafur > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 a complete review of the latest revision.. I'm hoping to get >> > to that in a day or two. But I've got a question about whether something >> > should be added to the document.. >> > >> > A question came up in conversation recently about the use of the verb >> > "to publish" in reference to managing DNS data. It quickly became clear >> > that there may be a common overloading of terms, where the same word means >> > different things to different people. I wasn't sure this fell into the >> > scope of the terminology document, but I just checked and it does use >> > "publish" in reference to DNS data, so perhaps we should come up with a >> > definition for that. >> > >> > To me, publishing DNS data has always meant the generation of the zone >> > and the data it contains, as distinct from distributing the zone (to name >> > servers, possibly though zone transfer) and serving the zone (making it >> > available to be queried on a name server). To the person I was speaking >> > to, >> > "publishing" meant putting that data on Internet-facing name servers that >> > would answer queries about it. >> >> To me, DNS data is published when it is made available to actors who wish >> to consume it. That means serving the data (i.e. having servers with the >> data available to answer queries). I have never heard "publish" used to mean >> zone generation. A zone, once generated, is not published until it is >> available for access by others. > > > agree, the word carries the usual dictionary meaning: > > publish v.t. to make public; to divulge; to announce; to proclaim; to set > forth to the public; >to put forth and offer for sale orig. any article, now books, newspapers, > etc.; >to put into circulation. > > zone generation without the "setting forth" does not appear to qualify. > > > Dick > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 draft in the inbox, I feel > we're ready to take this to WGLC. > > (We are aware of the two points raised my Job and Paul) > > > This starts a Working Group Last Call for: > draft-ietf-dnsop-kskroll-sentinel > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ > > The Current Intended Status of this document is: Proposed Standard > > In the brushing of the camel, the draft is focused on determining if > a particular root key has been loaded into resolvers. > > Please review the draft and offer relevant comments. > If this does not seem appropriate please speak out. > if someone feels the document is *not* ready for publication, please speak > out with your reasons. > > This starts a two week Working Group Last Call process, and ends on: 23:59 > 19 April 2018 > > thanks > tim > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Terminology: validating resolver
On Tue, Apr 3, 2018 at 12:13 AM, Paul Hoffman 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 "validating resolver" there. ok. So what is the 'resolver side' of a 'security aware' nameserver in 3.2, 3.2.1, 3.2.2, 3.2.3 and 4? You're not an idiot. I make many inferential leaps which aren't subsequently justified, but it felt to me like the definitional language around security aware went to validation. > >> 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 seen NOT to perform >> validation because it receives queries with the CD bit set. Therefore, >> you cannot say that all queries through a validating resolver >> necessarily demonstrate it is capable of validating. Its not entirely >> subject to external views of its behaviour without the full context of >> what was in the query received. > > > Errr, could you give that specific words that you would want to replace the > current definition? I think we're a bit of a way off that stage Paul. If you don't think its defined in an RFC, we're "inventing things" and I always feel very nervous about that. -G > > --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 seen NOT to perform validation because it receives queries with the CD bit set. Therefore, you cannot say that all queries through a validating resolver necessarily demonstrate it is capable of validating. Its not entirely subject to external views of its behaviour without the full context of what was in the query received. -G On Mon, Apr 2, 2018 at 11:45 PM, Paul Hoffman wrote: > Some folks didn't feel all that great about this because it's not defined in > an RFC. Specific suggestions welcome. > > Validating resolver: > A security-aware recursive name server, security-aware resolver, or > security-aware stub resolver that is applying at least one of the > definitions of validation (above), as appropriate to the resolution > context. For the same reason that the generic term "resolver" is > sometimes ambiguous and needs to be evaluated in context, > "validating resolver" is a context-sensitive term. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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, 2018 at 8:21 PM, Paul Hoffman wrote: > The current text is: > > "A configured DNSKEY RR or DS RR hash of a DNSKEY RR. A > validating security-aware resolver uses this public key or hash as > a starting point for building the authentication chain to a signed > DNS response." (Quoted from , Section 2) > > The WG has has a preference for quoting from RFCs, but there was also some > hesitation about this. How would people change this, possibly updating RFC > 4033? > > --Paul Hoffman > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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: >>> Geoff you are wrong. Titles should tell you what you are about >>> to read especially technical documents. There are WAY TOO MANY >>> RFC TO READ EVERYONE ON THEM. >> >> ... you lack ambition :-P >> >>> >>> If I had a TA for andrews.wattle.id.au the current title would >>> indicate that I could test resolvers to see if there is a TA >>> installed for it. >>> >>> The current draft *is not* generic. It is root TA specific. >>> That needs to be reflected in the title. >>> >>> As for the label it can be used for more than rolling KSKs. >>> It can be used to see what resolvers are supporting new TA >>> *when you are not rolling keys*. The current name reflects >>> *one* use, not all uses. >> >> True, it does reflect one use case, not all -- however, we have >> already changed the name multiple times and implementers are >> (understandably) becoming annoyed, and supporting N different labels >> for the tester is also annoying [0]. > > As an implementer I say TOUGH! The job of the working group is to > put out good specifications not to take short cuts just because > something has been implemented based on a draft. This is the expected > cost of implementing on a draft. I’ve re-written plenty of code to > follow draft changes. > > I’ve got code to implement this. Some corner cases are currently > undefined. Changing the label name will cause me to have to re-write > parts of what I have already written. I know this but I’m still > calling for the changes. Not only will the specific labels change > but potentially configuration arguments and with that documentation. > >> How about a compromise - we update the draft name, but keep the label >> the same - the only people who likely care about the label are >> implementers and testers - once someone sees the name they will read >> the doc and quickly discover how it can be used. >> >> W >> >> >> >>> >>> Mark >>> On 23 Mar 2018, at 8:21 pm, Geoff Huston wrote: > On 23 Mar 2018, at 12:55 am, Mark Andrews wrote: > > This title of this document DOES NOT match reality. > > "A Sentinel for Detecting Trusted Keys in DNSSEC” should be > replaced by “A Root Key Trust Anchor Sentinel for DNSSEC”. > > kskroll-sentinel-- really needs something other > than “kskroll” as the first field. “root-key-sentinal--” > really more clearly matches what it does. > > Any other changes that follow from these two changes” > I personally think this is getting into bike shedding at this point. The title of the document is an adequate description of the content and folk who want to know more should read the document, not guess from the title! The label is a piece of syntactic convenience and is entirely arbitrary. We could start an almost infinite discussion thread over which label is better, but in the end its just a label. regards, Geoff >>> >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Terminology question: split DNS
The quality to me, which was there in abstract, is a port-53 bound daemon, which uses the client IP network or /32 to specify how it answers. Server, Resolver, these are distinct classes. I felt split-horizon was the moment of decision logic from "who asked" If anyone has actually 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 wrote: > > > Ted Lemon wrote: >> >> On Mar 19, 2018, at 6:10 PM, George Michaelson > <mailto:g...@algebras.org>> wrote: >>> >>> "A DNS resolver which looks at the client requesting address, and uses >> >> >> That's a different thing. There's a distinction between a resolver that >> gives different answers, and a set of authoritative servers that give >> different answers. I believe split horizon is referring to the latter, >> not the former. > > > i've done both and referred to both as "split-horizon dns". > > bind9 views does both. > > -- > P Vixie > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 Mon, Mar 19, 2018 at 5:47 PM, Paul Hoffman wrote: > Some folks had reservations about the current definition of "split DNS": >"Where a corporate network serves up partly or completely different DNS > inside and outside >its firewall. There are many possible variants on this; the basic point > is that the >correspondence between a given FQDN (fully qualified domain name) and a > given IPv4 address >is no longer universal and stable over long periods." >(Quoted from , Section 3.8) > > What would the WG like for this definition? > > --Paul Hoffman > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt
I stress, I'm not an author on this one. I'm also heavily biassed by role and relationship(s) with the authors. I'm trying to play nice, in that context: I want it shipped. I think its a net useful contribution. So, I think your suggestion of guiding words is good. If it was my draft, I'd 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 wrote: > Hi George, > > On Jan 30, 2018, at 21:49, George Michaelson wrote: > >>> 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 detail, are we mostly good here? >> >> Because.. I really want this closed off. > > I like it, and I am keen for it to be implemented. I dislike Warren's > compromise on xm-- for all the reasons Paul mentioned (but also "oh my god > no, please no" just on general principles). I would like it to proceed so we > can see the kind of swift implementation that will teach us something about > the DNS. > > I made a comment some time ago in response to someone's (Warren's again, I > think, but I'm not sure) observed confusion in others about the draft. I > recall that I suggested that the draft include some explicit advice for all > the various actors here (resolver implementers, zone managers) so that it was > more clear who was doing what. > > I'm stil willing to contribute text if anybody cares, since I seem to > remember feeling correct about that observation, and I don't *think* I have > noticed a rev of the draft since then, but I also didn't notice any other > people say anything like that and I'm perfectly willing to be overwhelmed by > the silent majority or to have a more recent revision pointed out to me with > the patience normally reserved for the young and the dangerously insane. > > > Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 detail, are we mostly good here? Because.. I really want this closed off. -G On Wed, Jan 31, 2018 at 10:58 AM, Paul Hoffman wrote: > On 30 Jan 2018, at 16:29, Warren Kumari wrote: > >> There is one matter of substance (but, IMO, very minor substance!) -- >> the original document said that the names are of the form: >> _is-ta-[key].example.com >> _not-ta-[key].example.com >> >> This works, but some implementations really don't like having A/AAA >> records for names which start with an underscore... So, we are >> proposing to use instead: >> xm--is-ta-[key].example.com >> xm--not-ta-[key].example.com >> >> Why XM--? Well, we wanted some sort of identifier (that isn't an >> underscore), and XM-- felt "similar" to XN--. A quick look through the >> .com and .net zonefiles didn't show any collisions (yes, I realize >> that this is a tiny slice of the namespace, but it was quick and >> easy), nor did looking in various passive-dns and similar places. > > > Please, no. As the originator of the original > hack, I think this is the wrong thing to do > for many reasons. The biggest one is, sadly, the fact that some software now > has as reserved even though it should not. > > Further, it is not needed. When you say but some implementations really > don't like having A/AAA records for names which start with an underscore", > you could have easily added "...but they allow it with a minor configuration > change". > > The problem you hit was in BIND. To get around it, you simply add > "check-names master warn;" to the options. > > The purpose of the special label in this draft is to mark the whole name as > being used for testing. Making that more obvious with an underscore prefix > seems a lot better than making it seem like a label that would work in a > normal host name. > > And if you really hate the _ and want to use > , please do *not* use something that will > look a lot like an invalid IDN. There are plenty of other choices. > >> The document could really benefit from a better introduction / >> explanation of how this will be used (similar to my earlier >> conversational description) and integrating the comments received. >> The authors intend to publish this soon. > > > Thanks! > > --Paul Hoffman > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 wrote: > On Tue, Jan 30, 2018 at 6:44 PM, George Michaelson wrote: >> 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? It feels like its close. > > There is one matter of substance (but, IMO, very minor substance!) -- > the original document said that the names are of the form: > _is-ta-[key].example.com > _not-ta-[key].example.com > > This works, but some implementations really don't like having A/AAA > records for names which start with an underscore... So, we are > proposing to use instead: > xm--is-ta-[key].example.com > xm--not-ta-[key].example.com > > Why XM--? Well, we wanted some sort of identifier (that isn't an > underscore), and XM-- felt "similar" to XN--. A quick look through the > .com and .net zonefiles didn't show any collisions (yes, I realize > that this is a tiny slice of the namespace, but it was quick and > easy), nor did looking in various passive-dns and similar places. > > For folk who would like try this, I have a PoC / toy implementation at > https://www.ksk-test.net - note that this uses JS and I'm *so* not a > JavaScript programmer. It works on the browsers that I tested, that's > all I'll commit to :-) > > The document could really benefit from a better introduction / > explanation of how this will be used (similar to my earlier > conversational description) and integrating the comments received. > The authors intend to publish this soon. > > W > > >> >> -G >> >> On Wed, Jan 31, 2018 at 4:51 AM, Andrew Sullivan >> wrote: >>> On Tue, Jan 30, 2018 at 10:42:15AM -0500, Joe Abley wrote: >>>> >>>> I realise that the following is not what anybody means in this thread >>> >>> Hmm. Actually, I wasn't sure :-) >>> >>>> I probably missed some. Anyway, I think when people are saying "address >>>> record" here they actually mean "IP address record". >>>> >>> >>> We should probably say that, then, and also of course we should fix >>> the poor text in the teminology document to point this out. >>> >>> A >>> >>> -- >>> Andrew Sullivan >>> a...@anvilwalrusden.com >>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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? It feels like its close. -G On Wed, Jan 31, 2018 at 4:51 AM, Andrew Sullivan wrote: > On Tue, Jan 30, 2018 at 10:42:15AM -0500, Joe Abley wrote: >> >> I realise that the following is not what anybody means in this thread > > Hmm. Actually, I wasn't sure :-) > >> I probably missed some. Anyway, I think when people are saying "address >> record" here they actually mean "IP address record". >> > > We should probably say that, then, and also of course we should fix > the poor text in the teminology document to point this out. > > A > > -- > Andrew Sullivan > a...@anvilwalrusden.com > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain
yes. this is good. -G On Fri, Dec 15, 2017 at 12:30 PM, wrote: > Thanks. > > Adding a example as a text is a little complicated. > > Adding examples as a table is good ? or too large ? > > Delegation | Parent | Name Server Name | Type > | Zone || > +++-- > com | . | a.gtld-servers.net | in-bailiwick / sibling domain > net | . | a.gtld-servers.net | in-bailiwick / in-domain > example.org | org| ns.example.org | in-bailiwick / in-domain > example.org | org| ns.ietf.org| in-bailiwick / sibling domain > example.org | org| ns.example.com | out-of-bailiwick > example.jp | jp | ns.example.jp | in-bailiwick / in-domain > example.jp | jp | ns.example.ne.jp | in-bailiwick / sibling domain > example.jp | jp | ns.example.com | out-of-bailiwick > > -- > Kazunori Fujiwara, JPRS > >> From: George Michaelson >> 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 >>> |either subordinate to or (rarely) the same as the zone origin. >>> >>> Ok, In-bailwick in terminology-bis-08 may be restrictive because "the >>> zone origin" is unclear. I intended that "the zone origin" is the zone >>> origin of parent zone. The sentence needs more words. >>> >>> NEW >>> >>> In-bailiwick: An adjective to describe a name server whose name is >>>either subordinate to or (rarely) the same as the origin >>>of the zone that contains the delegation to the name server. >>> >>> ... bad english text ... please fix. >>> >>> -- >>> Kazunori Fujiwara, JPRS >>> >>>> From: Mark Andrews >>>> The text for "in-bailwick" is too restrictive, it doesn’t just cover NS >>>> records or >>>> glue records. >>>> >>>> In-bailwick refers to records that in the normal course of DNS resolution >>>> would have been requested of by the server the current response is from. >>>> e.g. if you are querying a .com server then all records in the response >>>> that end >>>> with .com are in-bailwick. >>>> >>>> Mark >>>> >>>>> On 5 Dec 2017, at 5:27 am, Paul Hoffman wrote: >>>>> >>>>> Greetings again. >>>>> >>>>> Some of the new terms added to the terminology-bis draft >>>>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since >>>>> RFC 7719 can be a bit tricky. This week, we hope you will look at the >>>>> definitions in the draft for: >>>>> - In-bailiwick >>>>> - Out-of-bailiwick >>>>> - In-domain >>>>> - Sibling domain >>>>> Please review these terms and comment on the list if you think the >>>>> definitions should change. >>>>> >>>>> --Paul Hoffman >>>>> >>>>> [[ As a reminder, we asked the following last week, but got no reply: For >>>>> the past many versions of the terminology-bis draft >>>>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), >>>>> Section 2 has definitions of "Global DNS" and "Private DNS", based on the >>>>> facets listed in "Naming system". This was discussed heavily on the list >>>>> earlier, but it is also a pretty big change, so we want to be sure that >>>>> it is what the WG wants. Please review these terms and comment on the >>>>> list if you think the definitions should change. ]] >>>>> >>>>> ___ >>>>> DNSOP mailing list >>>>> DNSOP@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dnsop >>>> >>>> -- >>>> Mark Andrews, ISC >>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>>> >>>> ___ >>>> DNSOP mailing list >>>> DNSOP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsop >>>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 > |either subordinate to or (rarely) the same as the zone origin. > > Ok, In-bailwick in terminology-bis-08 may be restrictive because "the > zone origin" is unclear. I intended that "the zone origin" is the zone > origin of parent zone. The sentence needs more words. > > NEW > > In-bailiwick: An adjective to describe a name server whose name is >either subordinate to or (rarely) the same as the origin >of the zone that contains the delegation to the name server. > > ... bad english text ... please fix. > > -- > Kazunori Fujiwara, JPRS > >> From: Mark Andrews >> The text for "in-bailwick" is too restrictive, it doesn’t just cover NS >> records or >> glue records. >> >> In-bailwick refers to records that in the normal course of DNS resolution >> would have been requested of by the server the current response is from. >> e.g. if you are querying a .com server then all records in the response that >> end >> with .com are in-bailwick. >> >> Mark >> >>> On 5 Dec 2017, at 5:27 am, Paul Hoffman wrote: >>> >>> Greetings again. >>> >>> Some of the new terms added to the terminology-bis draft >>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since >>> RFC 7719 can be a bit tricky. This week, we hope you will look at the >>> definitions in the draft for: >>> - In-bailiwick >>> - Out-of-bailiwick >>> - In-domain >>> - Sibling domain >>> Please review these terms and comment on the list if you think the >>> definitions should change. >>> >>> --Paul Hoffman >>> >>> [[ As a reminder, we asked the following last week, but got no reply: For >>> the past many versions of the terminology-bis draft >>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), >>> Section 2 has definitions of "Global DNS" and "Private DNS", based on the >>> facets listed in "Naming system". This was discussed heavily on the list >>> earlier, but it is also a pretty big change, so we want to be sure that it >>> is what the WG wants. Please review these terms and comment on the list if >>> you think the definitions should change. ]] >>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 in the wild, and we need a document specifying the behaviour we need deployed into those resolvers. We can use this to inform ourselves of operational risk under keychange. We can know as individuals, as organizations what we will see, if keys change. I think this is quite powerful. compared to measurement of what resolvers see, or what authoritatives or roots see, going back to these service-providers themselves. This method informs the client side of the transaction. Thats big. I'm not saying we shouldn't do other things, or measure. I'm saying that this proposal has a qualitative aspect which I think is different, and good. -George On Thu, Nov 16, 2017 at 4:23 PM, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the meeting > on Monday, and we feel it’s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > Please review this draft to see if you think it is suitable for adoption by > DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 30 November 2017 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 don't think any proposed modification of DNS in this space can be done, which doesn't face this risk: therefore, I don't see it having directing force. If there is some trick to doing something which doesn't expose the risk, What is it? cheers -George On Tue, Nov 14, 2017 at 9:30 AM, Stephane Bortzmeyer wrote: > On Mon, Nov 13, 2017 at 08:54:16PM +0800, > Ray Bellis wrote > a message of 29 lines which said: > >> Would it be feasible to reserve a standard RCODE value in the header >> that just means "see extended error"? > > First reaction: no. Middleboxes would block these responses, or old > clients would not know what to do with it. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 supposition. -George ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP Call for Adoption - draft-tale-dnsop-serve-stale
add client-intent signalling, and irrespective add server signalling of action, and I could be there. I'd support adoption. On Fri, Sep 8, 2017 at 6:42 AM, Paul Vixie wrote: > On Thursday, September 07, 2017 11:33:22 AM 神明達哉 wrote: >> ... >> >> If we don't work on a proposal like this, I'd love to see a specific >> counter proposal that doesn't violate the current protocol >> specification (i.e., using a cached answer beyond its TTL) and still >> avoids resolution failure when authoritative servers are forced to be >> non-responsive due to huge scale DoS attacks. > > i think the actual problem statement is broader, and that by solving for this > narrow version, we would lose the complexity/capability tradeoff -- we'd add > more state and more signaling at a cost higher than what we would get for it. > > it's a general reachability problem not specifically ddos problem. reasons for > not being able to refresh data in a cache include ddos, but also backhoes, > wire cutters, squirrels, circuit breakers, and bad design/provisioning. > > i think the right answer will look like a miniature version of IXFR/AXFR and > NOTIFY, such that a cache can register its intent to become a partial stealth > secondary server, and by participating, an authority server can both indicate > its willingness to have this done, and possibly remember what was transmitted > so as to facilitate subsequent cache invalidation or zone change notification > messaging. one could even imagine a dns cookie exchange at the outset, to help > authenticate later messages. sort of a super-lightweight session protocol. > > when the DNS was first popularized, we were using a lot of computers with less > than four megabytes of memory and fewer than a million instructions per > second, and our links were thought fast if 56K DDS, or super-fast if 1.544M T1 > or even 2.0M E1. this drove choices of how to encode, how to compress, where > to synthesize, and whether to authenticate. all of those choices should be up > for reconsideration now. > > if our _vision_ as a technical community is to have little chunks of semi- > authoritative data cached in stealth-like secondary-like places, and then kept > up to date, then we should pursue that, because moore's law and the > privatization and commercialization of the internet have made it now > practical. > > if we lack a vision and we're going to pursue small discrete targets of > opportunity based on the business problems faced by each industry participant, > then we'd be making hairball soup, and i'd ask that we not. > > see also: > > http://queue.acm.org/detail.cfm?id=1647302 > > vixie > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 I did wonder because Ted's suggestion that use of the literal IP address in either family would the stronger 'keep it local' made me think: what if somebody hand installed a route which somehow took it off-box? I think proscriptive/definitive language over the FQDN/label localhost in DNSSEC is probably still a good thing. IETF is defining behaviours for home.arpa in HOMENET which logistically fall into a very similar bucket (for me at least) so its not like we can't chose to say what behaviours we expect of a label. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 > , George > Michaelson writ > es: >> 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. > > It went to the IETF mailing list because it was added in AUTH48. > If I've read concensus of that discussion correctly there would > have been no issue if it was added earlier in the process. The > problem was timing not content. > > Too many times IETF members take procedual decisions out of context > and apply them elsewhere. This is just one example of that. > >> I am unsure about the R flag and proscriptive language. It seems to me >> that it can't be a single bit flag and suggest BOTH retry, and retry >> another NS. Also, the rest of the flag word is set zero. Surely thats >> '...at this time' >> >> And then the list of when to set, maybe set, maybe not set.. I think >> thats still a bit up in the air. >> >> But thats now WG matter to discuss I guess (assuming it got adopted) >> >> On Wed, Jul 26, 2017 at 5:46 AM, Peter DeVries >> wrote: >> > I have read the draft and support adoption. I plan to review and >> > contribute. >> > >> > Peter >> > >> > On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote: >> >> >> >> This draft was the only one which seemed to have broad support in some >> >> form during the meeting last week. >> >> >> >> This starts a Call for Adoption for draft-wkumari-dnsop-extended-error >> >> >> >> The draft is available here: >> >> https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 >> >> >> >> Please review this draft to see if you think it is suitable for adoption >> >> by DNSOP, and comments to the list, clearly stating your view. >> >> >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> >> >> This call for adoption ends: 8 August 2017, 23:59 >> >> >> >> Thanks, >> >> tim wicinski >> >> DNSOP co-chair >> >> >> >> >> >> >> >> ___ >> >> DNSOP mailing list >> >> DNSOP@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> > >> > >> > ___ >> > DNSOP mailing list >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> > >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 about the R flag and proscriptive language. It seems to me that it can't be a single bit flag and suggest BOTH retry, and retry another NS. Also, the rest of the flag word is set zero. Surely thats '...at this time' And then the list of when to set, maybe set, maybe not set.. I think thats still a bit up in the air. But thats now WG matter to discuss I guess (assuming it got adopted) On Wed, Jul 26, 2017 at 5:46 AM, Peter DeVries wrote: > I have read the draft and support adoption. I plan to review and > contribute. > > Peter > > On Tue, Jul 25, 2017 at 12:04 PM, tjw ietf wrote: >> >> This draft was the only one which seemed to have broad support in some >> form during the meeting last week. >> >> This starts a Call for Adoption for draft-wkumari-dnsop-extended-error >> >> The draft is available here: >> https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 >> >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and comments to the list, clearly stating your view. >> >> Please also indicate if you are willing to contribute text, review, etc. >> >> This call for adoption ends: 8 August 2017, 23:59 >> >> Thanks, >> tim wicinski >> DNSOP co-chair >> >> >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 themselves, not such. The nice thing about bare key cryptography, is that fish don't need bicycles. Dates are dates and validity intervals are a thing, but you can re-bake as many times as you like if there is nothing embedded in the structure like a serial. Oh wait.. we sign the SOA don't we... I (for one) hang onto the .req file. Maybe thats naughty, but I do, so in my case Warren routine is that the keypair is being reused, because.. well.. because I like to. Software I consume I suspect (like you) doesn't, and re-mints shiny new keys now with added keynomium, but when I do it by hand? yes I reuse the .req file. But I am probably being led into bad places as a result. I am sure wiser heads will say. On Fri, Jul 21, 2017 at 1:46 PM, Warren Kumari wrote: > On Fri, Jul 21, 2017 at 1:36 PM, Tony Finch wrote: >> Andrew Sullivan wrote: >>> >>> For instance, people also express astonishment that DNSKEYs don't >>> expire. Everyone always has to be reminded that signatures expire, and >>> if you want to expire keys you take them out of the zone. >> >> I agree with your message. >> >> It might be useful to explain this DNSKEY oddity by comparison with x.509 >> certificates. In particular, it's the cert that expires, not the key, and >> when you renew a cert you can re-use the same key. > > > Yeah, you *can* reuse the same key, but (I suspect) most don't -- from > what I've seen, then general process is: > 1: Erk! My cert is about to / has just expired!!! > 2: Search for and follow some online recipe related to "make ssl certificate" > 3: > 4: Go back to sleep. > > I think that (but would be happy to be proven wrong) that most > certificate renewals[0] involve a change of keys too. > > W > [0]: Well, "legacy certs", excluding sexy new things like LE / ACME, etc. > >> >> Tony. >> -- >> f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode >> Portland, Plymouth, North Biscay: Southerly or southwesterly 6 to gale 8 >> veering westerly or southwesterly 4 or 5, occasionally 6 later. Moderate or >> rough. Rain or showers. Good, occasionally poor. >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >---maf > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] EDNS0 clientID is a wider-internet question
I probably will not carry the WG with me on this, but I find myself thinking the PII aspect of client-ID makes it a wider-internet question and we might have views as a WG, and promote questions as a WG, but I think the "final call" on this is something which needs more than WG approval. Its a big question. I'd actually welcome adoption on many levels, but that isn't to pre-empt that it goes to WGLC. I think we need to formalize the issues and take them out of the WG for review and discussion. documenting current practice is ok btw, but .. PII. -G ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
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 population of a zone? I like it. So yea. I think we should have this. G On Tue, Jul 18, 2017 at 10:24 PM, IETF Secretariat wrote: > > The DNSOP WG has placed draft-woodworth-bulk-rr in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld
I could take it either way. narrow doc is narrow purpose? don't ref it. doc is highly visible, will be (mis)interpreted as being relevant? disavow it (which implies ref it) doc is highly visible, problem next door? Seek guidance. -G On Tue, Apr 4, 2017 at 11:40 AM, Suzanne Woolf wrote: > Hi, > > On one specific point: > >> On Apr 3, 2017, at 9:02 PM, George Michaelson 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 minimum should say why >> this draft is special, against that letter. You make a compelling and >> simple case: because its specifically NOT-DNS, not public DNS, its not >> relevant. Ok, then say so. 'we didn't say so because it wasn't >> relevant' feels pretty weak to me. > > > I’m fine with “the draft needs to be updated with reference to the relevance > of .arpa” as a WGLC comment, so the below is intended as contributing to the > discussion, not repressing it. > > On the intentions and role of the IAB: > > An IAB statement isn’t an IETF document of any kind, never mind a standards > track document, and can’t tell the IETF what to do— including this WG. So > the IAB certainly can’t say “We don’t do that any more” as a policy statement > about an IETF registry such as the special use names registry. However, RFC > 3172 is an IETF BCP, and provides direction to the IETF and the IAB (as admin > authority for .arpa) on the requirements that should be followed for a > delegation in .arpa. So as a WGLC comment, this suggests the addition of a > reference to RFC 3172 and the applicability of the .arpa policy there to the > justification for alt. > > It’s my view that, as Paul says, the IAB note was written about a different > case than the alt-tld draft was: the IAB was attempting to point out an > alternative to asking for a delegation in the root zone in the case that a > special use name is supposed to be resolvable in the DNS. The alt-tld draft > is about names that aren’t intended to be resolvable in the DNS in the first > place. > > However, since I was a contributor to the IAB document, it puts me in an > awkward position to be interpreting it for DNSOP on behalf of the IAB. If > further clarification on the IAB statement would be useful, we should > explicitly request it. > > best, > Suzanne > >> >> I can do this as a nit in the GIT if you prefer. >> >> -G >> >> >> On Mon, Apr 3, 2017 at 7:51 PM, Paul Hoffman 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 the case. >>> >>> >>> Are you saying that because of: >>> >>> https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/ >>> If so, I suspect you read it wrong. My reading is that the IAB is only >>> saying that names that are supposed to act like DNS names (that is, to exist >>> in the public DNS) need to be under .arpa. This draft explicitly is about >>> non-DNS contexts. >>> >>> --Paul Hoffman >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld
I think that's a useful mail. So in that sense, I have a question: Would you say anything to this, were you in edit mode, on a draft going to LC if that draft didn't say it? If you had a draft requesting a TLD to "exist" in some sense: in or not in a registry; passed or not passed into 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 wrote: > In response to the latest comments by Paul Hoffman and George Michaelson, > I'd like to offer my $0.02 on the meaning and purpose of the alt TLD vs the > IAB statement. > > My read is (whether or not it is correct) that there are three possibilities > for a special name. > > The first is, a special but needs DNS resolution. This is one case the IAB > says, "register it and put it in DNS under arpa". (I don't think that is > controversial at all, and a wise recommendation.) > > The second is, a Very Special, but does not belong in DNS. (IAB second > option.) > > The third is, a Not Very Special, and not in DNS. Not registered, FCFS. Not > covered by the IAB statement by virtue of not being registered, but IMHO not > conflicting with the IAB statement. > > Very Special: It gets its entry in the registry in order to establish its > uniqueness, but isn't in DNS, so no entry under arpa. This avoids the > possibility of multiple mechanisms for interception fighting with each > other, since the behavior is (or should be) name-driven. Also wise, and also > in-scope for the IAB statement. > > Not Very Special: whoever wants the name, is reasonably sure it won't be > exposed outside of a closed environment (e.g. a single application), and > doesn't want or need to go through the 6761 process to get the name > registered. > > Not Very Special is basically 6761 without the registry, in a first-come, > first-served, no guarantees kind of way. > > The "onion" thing showed the need for some way of avoiding TLDs, avoiding > conflicting names, and avoiding heavy process, IMHO. And I think "alt" is > the right answer. > > Also IMHO, making it "alt.arpa" would be very confusing; I think any time > someone sees "arpa" as the TLD, they should believe it exists in the DNS. > > Having "alt" be the parent name here, and not be in the DNS, keeps things > clear even to non-DNS folks. > > And finally, maybe there is a use case for FCFS local-use names that kind-of > are in the DNS. If such a need were to arise, then THAT would be something > where "alt.arpa" would make sense. But given the relative ease in adding > things under arpa, I don't see a good reason for creating non-registered > FCFS when registered FCFS is available, under arpa. > > Brian > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
