Re: [DNSOP] Meaning of lame delegation

On 12 Apr 2023, at 21:37, Joe Abley wrote: > With regard to a flock of drones providing service for a single nameserver I > agree there are other exciting failure modes to look forward to. But, as > before, I don't think we have a shortage of ways to describe them -- no need > to economise by

Re: [DNSOP] Meaning of lame delegation

On 12 Apr 2023, at 20:56, Niall O'Reilly wrote: > I have, or think I have, always understood the NS RRset at a zone > cut to advertise a set of delegations, each to a distinct server. And if you use anycast, where some of the servers in the anycast cloud respond and some do not? Patrik

Re: [DNSOP] Wildcard junk vs NXDOMAIN junk

On 7 Apr 2022, at 18:50, John R. Levine wrote: > A friend of mine asserts that wildcard DNS records are a problem because > hostile clients can use them to fill up DNS caches with junk answers to > random queries that match a wildcard. But it seems to me that you can do it > just as well with

Re: [DNSOP] draft-hoffman-dns-terminology-ter-01.txt - some comments

On 23 Jul 2019, at 20:10, Puneet Sood wrote: >> draft-hoffman-dns-terminology-ter-01.txt says: >> Applications Doing DNS (ADD): Applications that act as stub >> resolvers. This is in contrast to the way that applications >> traditionally have gotten DNS information, which is

Re: [DNSOP] extension of DoH to authoritative servers

On 12 Feb 2019, at 21:48, Paul Vixie wrote: > whether the situation turns out to be temporary or not is important to your > final argument. probably you shouldn't go there so soon. spammers also > believe that network operators should not be able to control their own > networks, and malware

Re: [DNSOP] Root zone KSK-2010 is now revoked

Well done Matt and others! Appreciate your work! Patrik On 12 Jan 2019, at 0:07, Matt Larson wrote: > Dear colleagues, > > A few moments ago, at 1400 UTC today, 11 January 2019, ICANN's root zone > management partner, Verisign, published root zone serial number 2019011100 > with the RFC

Re: [DNSOP] Variant bad idea of the day

On 1 Jan 2019, at 18:00, John R Levine wrote: >> If you get a request that include any of the code points {n1, n2,...}, >> return a CNAME where nM is replaced with foo? > > Not just at foo, but do the same thing on any name under foo. The idea is to > publish the LGR for the subtree and the

Re: [DNSOP] Variant bad idea of the day

On 1 Jan 2019, at 1:28, John R Levine wrote: > foo VARIANT n1 n2 n3 n4 ... > > The fields are 32 bit ints, each of which is interpreted as a UTF-32 code > point. The meaning is that in the subtree at and below this name, n1 is a > canonical code point and the rest are variants. If you get a

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-03.txt

On 21 Dec 2018, at 21:28, Warren Kumari wrote: > On Fri, Dec 21, 2018 at 12:52 PM Wes Hardaker > <[wjh...@hardakers.net]()> wrote: > >> Jared Mauch <[ja...@puck.nether.net]()> writes: >> >> > We went through some of this in IDR about

[DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME vs URI vs NAPTR

Note changed subject... Sure, I think of course the URI RR is the best thing since sliced bread, but same for each one of the proponents of the other RRs. I think we could look at the various deployment scenarios and demonstrate what design features each one of the RRs have. And with such a

Re: [DNSOP] Fundamental ANAME problems

On 6 Nov 2018, at 22:30, Ray Bellis wrote: > You can have wildcard support, or you can have prefixes (hence > delegation), but you can't have both. Thats exactly my point. URI solves "the other problem". Patrik signature.asc Description: OpenPGP digital signature

Re: [DNSOP] Fundamental ANAME problems

On 6 Nov 2018, at 17:51, Joe Abley wrote: >> On Nov 6, 2018, at 20:44, Tony Finch wrote: >> >> Joe Abley wrote: >>> >>> Specifically, I s the wildcard owner name a real problem in the grand >>> scheme of things? >> >> My understanding is that wildcards don't work for SRV because the >>

Re: [DNSOP] Fundamental ANAME problems

On 3 Nov 2018, at 23:32, Måns Nilsson wrote: > _http._tcp.example.org. IN URI10 20 > "https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/; Btw, this is sort of what I am thinking of for URI, cooked up directly after dinner. Could be a wrapper around curl that

Re: [DNSOP] Fundamental ANAME problems

On 4 Nov 2018, at 11:10, Ray Bellis wrote: > -1 :-) > What are the semantics of this? The semantics is exactly like a CNAME + HTTP Redirect. Provisioning is like any provisioning in the DNS, with the advantage that you can delegate the prefix:ed domain just like you can do with any _tcp and

Re: [DNSOP] Fundamental ANAME problems

On 3 Nov 2018, at 23:32, Måns Nilsson wrote: > _http._tcp.example.org. IN URI10 20 > "https://example-lb-frontend.hosting.namn.se:8090/path/down/in/filestructure/; > > We already have this. We need not build a new mechanism. +1 Patrik signature.asc Description: OpenPGP digital

Re: [DNSOP] SRV and HTTP

On 11 Jul 2018, at 8:21, Mark Andrews wrote: > As for lib curl, there is not a RFC that says to lookup SRV records for HTTP > or HTTPS. Agree, and I have wanted it to be part of HTTP/2, or at least resolve this mess, but it did not happen. This is my recurring discussion with Daniel when we

Re: [DNSOP] SRV and HTTP

On 11 Jul 2018, at 5:16, John R Levine wrote: > It's always been my impression that the http crowd believe that the > overhead of a two DNS lookups is too slow, for some meaning of too slow. They rather stay in the space they know, HTTP resolution, and do multiple HTTP requests instead of

Re: [DNSOP] SRV and HTTP

On 11 Jul 2018, at 3:30, Mark Andrews wrote: > I think there are three main objections. > > 1) Wildcards don’t work with prefixes. > 2) Additional data isn’t always returned it may require multiple round trips. > 3) Additional data processing doesn’t support negative responses. 4) Various

Re: [DNSOP] updating fragile dnssec, was Fwd: New Version

On 18 Aug 2017, at 4:39, John R Levine wrote: > Some do it one way, some do it the other, and the registars and registries > I've talked to feel very strongly about whichever way they do it. Correct, and that is why my only strong view is that both mechanisms can be implemented by the solution

Re: [DNSOP] .arpa

On 27 Mar 2017, at 14:41, Ray Bellis wrote: > On 27/03/2017 02:52, Patrik Fältström wrote: > >> One important part is in the letter from NTIA (Karen Rose) to ICANN >> (Louis Touton) in Appendix A. >> >> A letter sent April 28, 2000. > > Is it online? I can't

Re: [DNSOP] .arpa

On 26 Mar 2017, at 17:17, Ozgur Karatas wrote: > 22.03.2017, 10:05, "Jim Reid" : > >>>  On 21 Mar 2017, at 14:53, Suzanne Woolf wrote: >>> >>>  RFC 3172 was written in 2001… > > the last updated was made in 2013, right? One important part is in the

Re: [DNSOP] .arpa

On 22 Mar 2017, at 8:05, Jim Reid wrote: >> On 21 Mar 2017, at 14:53, Suzanne Woolf wrote: >> >> RFC 3172 was written in 2001… > > RFC 3172 was an attempt to rewrite history and contrive an acronym: Address > and Routing Parameter Area - really? > >> Respectfully, I’ve

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

On 4 Feb 2017, at 2:57, Andrew Sullivan wrote: > On Fri, Feb 03, 2017 at 12:21:16PM -0800, Steve Crocker wrote: > >> And just to stir the pot a bit, what would you have ICANN do if someone >> applies for .alt as a top level domain? Is it ok if we say yes and delegate >> the name? If not, what

Re: [DNSOP] [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf

On 4 Aug 2016, at 18:55, Dave Crocker wrote: >>> For URI records RFC 7553 says they're either named the same as SRV >>> records, or they use enumservice names from the Enumservice >> >> Declaring a namespace as the union of two, independently-maintained >> registries is a very efficient way to

Re: [DNSOP] draft-ietf-dnsop-terminology-bis-01

On 17 Jul 2016, at 11:16, Dan York wrote: > The new -01 draft looks good.  I need to do a deeper read but I'll point out > one additional term we found in the development of  > https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/ >   Not all registries accept DS.

Re: [DNSOP] New usage for TXT RR type on radar: Kerberos service discovery

On 31 May 2016, at 21:13, John R Levine wrote: >> It is a big failure and problem for the Internet that there is no support >> for unknown resource record types. > > No kidding. The problem isn't with DNS server software like BIND and NSD, > which are updated regularly. Correct! > The problem

Re: [DNSOP] New usage for TXT RR type on radar: Kerberos service discovery

It is a big failure and problem for the Internet that there is no support for unknown resource record types. See RFC 3597 (from 2003) and followers. Patrik -- that because of this will continue to object to use of TXT, as we all have our windmills signature.asc Description: OpenPGP

Re: [DNSOP] [rfc-edi...@rfc-editor.org: RFC 7788 on Home Networking Control Protocol]

On 24 Apr 2016, at 16:20, Paul Hoffman wrote: > On 23 Apr 2016, at 19:58, Ted Lemon wrote: > >> Bottom line: this is not actually the intended way things should work for >> naming in homenets, and a lot of people missed it. Sigh. > > ...for well over a year. You see that exact phrase in the

Re: [DNSOP] [rfc-edi...@rfc-editor.org: RFC 7788 on Home Networking Control Protocol]

t; On Sun, Apr 24, 2016 at 2:18 AM, Patrik Fältström <p...@frobbit.se> wrote: > >> On 24 Apr 2016, at 3:01, David Conrad wrote: >> >>> I would agree that it is interesting. Unsurprisingly, it is not in >> http://www.iana.org/assignments/special

Re: [DNSOP] [rfc-edi...@rfc-editor.org: RFC 7788 on Home Networking Control Protocol]

On 24 Apr 2016, at 3:01, David Conrad wrote: > I would agree that it is interesting. Unsurprisingly, it is not in > http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml. > My gut feeling is that this is a process failure, but will admit that the > whole

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

On 30 Mar 2016, at 1:23, Suzanne Woolf wrote: > Doubtless I’m missing something though….is there a citation we can ask the > draft authors to incorporate in the future? The formal references we in SSAC have found are the following: For .corp and .home:

Re: [DNSOP] statistics of deployment

On 6 Jan 2016, at 17:16, Hosnieh Rafiee wrote: > Thanks a lot to all of you who provided me with the information. > > I am quite amazed with all these statistics :).. very good job! I knew there > are a lot of efforts on the deployment but didn't know as that much. Btw, as I presume there is

Re: [DNSOP] code points for brainpool curves for DNSSEC

I have nothing to add to what Ólafur wrote below. I agree with his statement. Patrik On 10 Dec 2015, at 1:33, Ólafur Guðmundsson wrote: > Stephen, > > Sorry for being so blunt below. > > The document totally content free as to why this makes any sense in an > operational context. > DNSSEC

Re: [DNSOP] new Resource record?

On 9 Dec 2015, at 21:25, Hosnieh Rafiee wrote: > I would like to suggest the following format (this is the rough version and > it is not exact but only giving you an idea that what is the purpose) for a > new resource record to store the reference information of bounding of > authentication

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

On 26 Nov 2015, at 18:05, Joe Abley wrote: > On 25 Nov 2015, at 0:40, Patrik Fältström wrote: > >> I have read this draft and have a number of comments. I can not say these >> are the only ones, but at least some :-) >> >> The dominant protocol for n

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

Hi, I have read this draft and have a number of comments. I can not say these are the only ones, but at least some :-) The dominant protocol for name resolution on the Internet is the Domain Name System (DNS). However, other protocols exist that are fundamentally different from the

Re: [DNSOP] Registry of non-service _prefix names?

On 13 Nov 2015, at 19:00, John Levine wrote: > It's not a substitute for a > new RRTYPE; they need the prefix whether the data is TXT or a new type. Clarification, my english is not good enough... What you mean is that they believe they do need the prefix regardless of what RRType they will

Re: [DNSOP] Asking TLD's to perform checks.

On 11 Nov 2015, at 11:42, Stephane Bortzmeyer wrote: > On Wed, Nov 11, 2015 at 11:29:41AM +0100, > Patrik Fältström <p...@frobbit.se> wrote > a message of 57 lines which said: > >> Some registries even requires MX records at the zone apex! Even more weird. > > Les

Re: [DNSOP] Asking TLD's to perform checks.

On 11 Nov 2015, at 11:17, Havard Eidnes wrote: > A zone registered with delegation records, but where none of the > name servers respond to queries for the zone does noone any good, > so why must it be acceptable? Because only registration of the domain name is what is wanted. No one want

Re: [DNSOP] Asking TLD's to perform checks.

On 11 Nov 2015, at 11:17, Havard Eidnes wrote: > Does the scenario look like this? > > * Client asks to registrar to set up frobbit.se Yes, someone want to register frobbit.se domain name. For pure IPR reasons. It should not resolve. > * Registrar is lazy and doesn't want to set up a separate

Re: [DNSOP] [ccnso-techwg] Re: Asking TLD's to perform checks.

> On 11 nov. 2015, at 08:11, Dr Eberhard W Lisse wrote: > > So whatever comes out of that could, eventually, also go in. I completely agree. My only point is that I urge IETF to write text som that any(!) reader can understand there will always be cases where "errors" for

Re: [DNSOP] Asking TLD's to perform checks.

On 10 Nov 2015, at 22:24, Jim Reid wrote: >> Or perhaps we should not. > > +1 This discussion on making tests is coming back now and then. In RIPE, in IETF, in discussions around TLDs (specifically ccTLDs). I have run one such initiative myself. Everything has so far collapsed into collision

Re: [DNSOP] My "toxic" remark at the mic today

On 6 Nov 2015, at 4:54, Andrew Sullivan wrote: > On Thu, Nov 05, 2015 at 03:32:43PM +0900, Paul Hoffman wrote: > >> No, but there is an RFC from the IAB about what labels should not be into >> the root without further consideration: RFC 4690. That has been widely >> interpreted as "do not put X

Re: [DNSOP] My "toxic" remark at the mic today

On 5 Nov 2015, at 11:50, John Levine wrote: > I'm not sure how toxic it is, but I agree that we are unlikely to have > anything useful to say on the topic. Speaking personally, I do not see DNAME toxic, but the question has almost always been: - Whether clients do handle DNAME correctly - How

Re: [DNSOP] My "toxic" remark at the mic today

ement for anyone to follow the recommendations. That said, ICANN Board must take SSAC (and other ICANN AC) advisories and recommendations into account, i.e. at least explain why the advice was not followed. Patrik Fältström SSAC Chair signature.asc Description: OpenPGP digital signature _

Re: [DNSOP] Barry Leiba's Abstain on draft-ietf-dnsop-onion-tld-00: (with COMMENT)

On 21 Aug 2015, at 21:15, Stephen Farrell wrote: Do ICANN have any process for allocating special-use names that will not be used in the DNS? ICANN today do not have any process for doing anything regarding anything in the domain namespace except managing the strings that where applied for in

Re: [DNSOP] My remarks at the mic in the DNSOP meeting the other day

On 26 Jul 2015, at 3:06, Andrew Sullivan wrote: I wanted to follow up to the list to try again to make clear what I said in the DNSOP meeting the other day. In the first place, the point I was trying to make in the business model remark is just this: some of the drafts trying to register

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

On 20 Jul 2015, at 10:22, David Conrad wrote: On Jul 20, 2015, at 5:53 AM, David Cake d...@difference.com.au wrote: Of course, ICANN has already determined that .corp does pose a security issue of sufficient significance that .corp will not be delegated. For clarity, I believe ICANN has

[DNSOP] Clarification

At the end of the meeting I was the last person at the microphone, and what I said was confusing. Let me explain... First of all, I mentioned I was chair of SSAC. That was not the slightest a way of convincing you to listen more to me than others. It was a disclosure. My apologies if people

Re: [DNSOP] what's in .alt, was Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

or any SSAC member know, or have a look yourself at https://www.icann.org/groups/ssac/documents. Patrik Fältström Current SSAC Chair ;-) signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https

Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion Special-Use Domain Name) to Proposed Standard

On 14 Jul 2015, at 22:16, Ted Hardie wrote: Further, I believe this stretches the special handling requirement of RFC 6761 to the breaking point.  This does not describe special handling _within the DNS_, but instead removes a portion of the global namespace from the DNS at all.  To me, at

Re: [DNSOP] Some distinctions and a request - Have some class?

On 4 Jul 2015, at 1:56, manning wrote: So I -think- we are on the same page here, although I would replace your use of the phrase, “name space” with domain. We have empirical evidence of multiple domains using the same name space. (Fred Baker persuaded me that there is a single name space,

Re: [DNSOP] Some distinctions and a request - Have some class?

On 4 Jul 2015, at 8:31, John Levine wrote: I guess my question here is, what would prevent House Finch Feathers OY from applying for the DNS(IN) string ONION from ICANN because they want that as a TLD in the IN class? At the moment, nothing. Remember, we also have a draft about .HOME

Re: [DNSOP] Some distinctions and a request - Have some class?

On 4 Jul 2015, at 18:29, Suzanne Woolf wrote: It seems to me, from long experience of both organizations, that ICANN says what names should and shouldn’t be in the DNS root zone— Well, I have never seen ICANN saying definite no to any string. ICANN only say no, this string is not to be ok in

Re: [DNSOP] Some distinctions and a request - Have some class?

Unfortunately I think we all in this discussion [again] mix up discussion about DNS with the discussion about the name space that is in use for example by what we know as the domain name system rooted at the root zone managed by IANA. I think we just must force ourselves to stay focused on

Re: [DNSOP] Some distinctions and a request - Have some class?

On 3 Jul 2015, at 20:11, manning wrote: I guess my question here is, what would prevent House Finch Feathers OY from applying for the DNS(IN) string ONION from ICANN because they want that as a TLD in the IN class? Nothing, if that is the goal, which I claim it is not. The goal is to

Re: [DNSOP] Character encoding of URI Target RDATA?

On 18 Jun 2015, at 6:53, Tony Finch wrote: Patrik Fältström p...@frobbit.se wrote: The over arching issue here is that there is no right answer regarding non ascii in URIs. What about RFC 3987 ? Not everyone have implemented it, and the consensus when creating the URI RR was that the RR

Re: [DNSOP] Character encoding of URI Target RDATA?

On 17 Jun 2015, at 16:52, bert hubert wrote: At least if the RFC does not specify it, we should pick something. The over arching issue here is that there is no right answer regarding non ascii in URIs. A URI is a sequence of characters, but in HTTP the path must be ascii only, and can have

Re: [DNSOP] Character encoding of URI Target RDATA?

On 16 Jun 2015, at 22:45, Robert Edmonds wrote: John Levine wrote: What I'm asking is how the octet sequences provided by the URI RR RFC are decoded into the sequences of URI characters used by the URI RFC. Is there a generic way to do this, or does it depend on the specific protocol (e.g.,

Re: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps

On 28 May 2015, at 11:17, Suzanne Woolf wrote: The IETF doesn't decide what goes into the root zone. ICANN does The IETF decide what does NOT go into the root zone, while ICANN do decide what goes into the zone. ICANN can only delay their decision of adding things by not yet saying yes.

Re: [DNSOP] Agenda and logistics Re: Reminder: Interim Meeting on Special Names and RFC 6761 12-May-2015

People might not come before the main session has ended. :-) Patrik On 12 May 2015, at 17:26, Kaveh Ranjbar wrote: Hello, If you are at the RIPE Meeting: The room is called MEERMAN I/II , right next to the elevators. There are blue sheets ready here and we will try to put the

Re: [DNSOP] EU ISO-3166 code (was Re: I-D Action: draft-ietf-dnsop-dns-terminology-01.txt)

On 4 May 2015, at 7:16, Patrik Fältström wrote: I.e. 3166/MA is very careful with it not being the ones that register codes. Let me add...but they have not been so careful with what codes they reserve. Remember that in those days the list of reserved codes was not public (although IANA did

Re: [DNSOP] EU ISO-3166 code (was Re: I-D Action: draft-ietf-dnsop-dns-terminology-01.txt)

On 4 May 2015, at 10:25, Suzanne Woolf wrote: On May 4, 2015, at 9:22 AM, Andrew Sullivan a...@anvilwalrusden.com wrote: I still think that defining TLD is useful, and I suspect in that definition we'd want to add the sentence, TLDs are often divided into ccTLDs and gTLDs; the division is a

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

On 4 May 2015, at 3:22, David Conrad wrote: Patrik, Also note that there are ccTLDs allocated for codes that are not registered in ISO3166 (UK, EU etc). IIUC these two are on the 3166 list as exceptionally reserved codes. Yes, but not REGISTERED, and that difference is something that

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

On 30 Apr 2015, at 16:40, George Michaelson wrote: economy and economycode is a useful concept sometimes. it avoids the CN/TW issue. and encompasses HK. state or territory can be useful. covers some of the intermediate things. eg much of the CIS is a 'transitional state' according to the

Re: [DNSOP] Interim Meeting on Special Names and RFC 6761

On 30 Apr 2015, at 19:10, Alain Durand wrote: On 4/30/15, 11:23 AM, Warren Kumari war...@kumari.net wrote: The RIPE staff has been very nice and made a room available at RIPE-70 https://ripe70.ripe.net/: Meerman I/II for ~30 people on Tuesday 12 May 18:00- 20:00 Amsterdam Jaap

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

On 30 Apr 2015, at 18:34, Kim Davies wrote: If an allusion to the purpose is useful, then: A TLD that is allocated for use based on an entry in the ISO 3166-1 standard [ISO 3166-1]. The ISO 3166 standard provides codings of countries and their subdivisions. A TLD that is allocated for use

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

On 1 May 2015, at 12:00, Jim Reid wrote: On 1 May 2015, at 08:31, Patrik Fältström p...@frobbit.se wrote: Also note that there are ccTLDs allocated for codes that are not registered in ISO3166 (UK, EU etc). IIUC these two are on the 3166 list as exceptionally reserved codes. Yes

Re: [DNSOP] Some comments on draft-hoffman-dns-terminology

On 2 apr 2015, at 21:51, Paul Hoffman paul.hoff...@vpnc.org wrote: Given this thread, I propose the following for the draft: Well, I would change things around so that it is more clear primary and secondary are the terms to use today, like: Primary servers and secondary servers --- These

Re: [DNSOP] Some comments on draft-hoffman-dns-terminology

On 2 apr 2015, at 20:50, Dave Lawrence t...@dd.org wrote: Paul Hoffman: I added the synonym for slave. How do people feel about primary and master? Personally I'm not fond of the master/slave language and avoid the terms. I recognize their historic computer use and don't feel the need

Re: [DNSOP] Using NSEC3 for opt-out, was Re: Comments regarding the NSEC5

On 15 mar 2015, at 17:30, Ondřej Surý ondrej.s...@nic.cz wrote: JFTR .cz was asked by The Office for Personal Data Protection to implement measures to protect the personal data for domain holders. NSEC3 was part of the solution. Can you explain more how that was part of the solution?

Re: [DNSOP] Using NSEC3 for opt-out, was Re: Comments regarding the NSEC5

On 15 mar 2015, at 21:19, Ondřej Surý ondrej.s...@nic.cz wrote: This is really vague memory of it, but the main problem was that NSEC enumeration with public whois allowed data scraping. Ok, but the real problem was then that all registered domain names where also delegated? Together with

Re: [DNSOP] Is there a concise and comprehensive definition of a zone file?

On 22 feb 2015, at 20:58, Paul Hoffman paul.hoff...@vpnc.org wrote: As for Måns original question: converting wire-format IDNA to some encoding of Unicode characters is unstable because some registries use IDNA2003 rules, others use IDNA2008 rules, and some labels in the former can't be

Re: [DNSOP] New Version Notification for draft-hoffman-dns-terminology-00.txt

Now at last I have had time to read this...sorry for the late response. Let me suggest first of all a change in the structure of the document. For example, in section 2 where you talk about message format, just talk about the message format. Query, Answer, Additional information etc. How these

Re: [DNSOP] DNS URI code point wire format

On 31 jul 2014, at 06:14, Mark Andrews ma...@isc.org wrote: When DNS code points are issued based on the request template the wire and presentation values are supposed to be fixed. URI was issued against draft-faltstrom-uri-05/06. The wire format has been changed

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

On 8 jul 2014, at 08:22, David Conrad d...@virtualized.org wrote: On Jul 7, 2014, at 10:02 PM, Patrik Fältström p...@frobbit.se wrote: The main argument against slaving the root I've seen appears to me to be FUD: people running resolvers are too stupid to configure slaving the root

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

...@vpnc.org wrote: On Jul 7, 2014, at 10:02 PM, Patrik Fältström p...@frobbit.se wrote: - Recovery process when bad data end up in the resolver (cache v.s. auth) That's the cache has gone stale issue that David raised. It is dealt with in the current draft. There is no other way for bad data

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

On 8 jul 2014, at 20:30, David Conrad d...@virtualized.org wrote: On Jul 7, 2014, at 11:39 PM, Patrik Fältström p...@frobbit.se wrote: One could say the discussion is a typical non-constructive IETF discussion which too many are. Seems like it has been (mostly) a constructive discussion

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

On 8 jul 2014, at 02:55, David Conrad d...@virtualized.org wrote: The main argument against slaving the root I've seen appears to me to be FUD: people running resolvers are too stupid to configure slaving the root correctly so root data will go stale! (paraphrased). I am a bit disappointed

Re: [DNSOP] Extended CNAME (ENAME)

On 20 maj 2014, at 14:17, Petr Spacek pspa...@redhat.com wrote: Hmm, would it be too weird to use _http._srv.[name] CNAME _https._tcp.[name] as 'HTTPS required' signalization? (This is weird, I admit that. There will be troubles with DNS client libraries not exposing CNAMEs etc... I

Re: [DNSOP] Extended CNAME (ENAME)

On 20 maj 2014, at 16:00, Ted Lemon ted.le...@nominum.com wrote: On May 20, 2014, at 12:48 AM, Patrik Fältström p...@frobbit.se wrote: Can we not with HTTP/2 please push SRV forward? Dare I assume that you meant not for emphasis, not to ask that we not do this? :) Argghof course

Re: [DNSOP] Extended CNAME (ENAME)

On 20 maj 2014, at 22:57, Mark Delany f...@november.emu.st wrote: one can lookup A, and SRV in parallel and positive answer to SRV, as Paul mentioned, can have additional A and RRs. A downside is that clients has to wait for the SRV query to complete so they can be sure of the

Re: [DNSOP] Extended CNAME (ENAME)

On 20 maj 2014, at 05:54, Paul Vixie p...@redbarn.org wrote: if we decide that web servers can be reached by SRV records, then any web client can start looking for the SRV that describes that service, falling back to whatever tin-cups-and-string it did before if it can't find the SRV it

Re: [DNSOP] Extended CNAME (ENAME)

On 17 maj 2014, at 13:51, Ted Lemon ted.le...@nominum.com wrote: It might be worth actively pushing the CDN folks to go the SRV direction. Even if ENAME were a good idea, which is not clear to me, it's an idea that would require significant infrastructure changes, whereas SRV records

Re: [DNSOP] draft-ietf-dnsop-delegation-trust-maintainance - should child remove the CDS RR?

On 14 apr 2014, at 14:32, Antoin Verschuren antoin.verschu...@sidn.nl wrote: op 12-04-14 09:28, Patrik Fältström schreef: No, I want B. That CDS and CDNSKEY is staying in the zone. To keep it in the same thread, I want: C: The child MAY remove the CDS/CDNSKEY RR from the zone once

Re: [DNSOP] Spinning out of scope on draft-...-delegation-trust...

On 14 apr 2014, at 15:16, Matthijs Mekking matth...@nlnetlabs.nl wrote: On 04/14/2014 03:05 PM, Edward Lewis wrote: I think it is silly to burn two RR types to communicate the same thing. You’re inviting debate on testing and handling the two being out of sync. Would you prefer one RR

Re: [DNSOP] draft-ietf-dnsop-delegation-trust-maintainance - should child remove the CDS RR?

On 12 apr 2014, at 15:04, Warren Kumari war...@kumari.net wrote: Gods I suck at this. No, you are good at this! Patrik signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] (no subject)

On 11 apr 2014, at 23:12, Warren Kumari war...@kumari.net wrote: Hi there all, At the moment this document says that the child SHOULD remove the CDS/CDNSKEY record once the parent has consumed / acted on it (this behavior was requested by someone -- unfortunately I cannot remember whom).

Re: [DNSOP] draft-ietf-dnsop-delegation-trust-maintainance - should child remove the CDS RR?

No, I want B. That CDS and CDNSKEY is staying in the zone. Patrik On 12 apr 2014, at 00:11, Warren Kumari war...@kumari.net wrote: [ Apologies all - I initially sent this with no subject line. Resending. Hopefully this makes things clearer... Also, unless we hear strong objections I'm

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On 11 apr 2014, at 11:36, Matthijs Mekking matth...@nlnetlabs.nl wrote: I want to know what happens both from the child and parent perspective IF the CDS and CDNSKEY differs. Just say what the result should be. Parent pick one at random? At random? Then you still don't really know

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On 11 apr 2014, at 12:03, Antoin Verschuren antoin.verschu...@sidn.nl wrote: I think since this is a protocol definition, CDS and CDNSKEY MUST match. What a parent should do when the protocol is violated is I guess an implementation issue, BCP, or perhaps even local policy. A parent may only

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On 10 apr 2014, at 18:34, Warren Kumari war...@kumari.net wrote: Because of this, I do not mind having some extra words here, like: This proposal do not include all operations needed for maintenance of DNSSEC key material, specifically introduction and complete removal of all keys.

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

On 3 Apr 2014, at 12:09, Patrik Fältström p...@frobbit.se wrote: What does would be a good idea mean in RFC 1918 speak? :-) Hmm...not enough coffee...RFC 2119 of course. Patrik signature.asc Description: Message signed with OpenPGP using GPGMail

Re: [DNSOP] CPE devices doing DNSSEC

On 2014-03-08 09:00, Mark Andrews wrote: They have failed to invent / document a common standard way for machine updates to work. They could have quite easily got together anytime in the last decade and done a standardised update protocol. But they haven't. As long as the registries have

Re: [DNSOP] CPE devices doing DNSSEC

On 2014-03-08 11:47, Jim Reid wrote: Correction: some registrars are obliged to use EPP to talk to some registries. Correction: epp is not one protocol. It is one protocol profile per backend registry. A big failure for IETF I must say. The architecture is broken, but, luckily IETF has now

Re: [DNSOP] CPE devices doing DNSSEC

On 2014-03-09 10:19, Patrik Wallstrom wrote: But the fact is that EPP is several magnitudes better harmonized between TLDs compared to that registrars are offering their customers. There is no way around that today, and the registrars have no incentive at all to improve the situation. For all

Re: [DNSOP] CPE devices doing DNSSEC

On 2014-03-09 12:55, Patrik Wallstrom wrote: Yes, there is. Let me explain how. Registries are using variants of the same protocol, EPP. Registries are typically serving exactly one name space. And this is where the lock-in for the registrar come in - there are no other registries that

Re: [DNSOP] CPE devices doing DNSSEC

On 2014-03-09 12:55, Patrik Wallstrom wrote: Given this pricing structure, and that registries do change their implementations far too often, where do you think registrars do spend the money they have? They MUST support what the changes the registries do, they do not HAVE TO implement a

Re: [DNSOP] summary of WG current status

WOW! This could be a week of meetings... I guess it is not time to fold yet... :-P Patrik On 2014-02-21 18:17, Suzanne Woolf wrote: Dear Colleagues, As we look towards the meeting in London, we have several items in progress, which we've organized here from the most specific and

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

On 2014-02-18 19:58, Joe Abley wrote: I appreciate that knowing the process made things easier (mainly; I was wrong about some things and had to be educated). But I would not describe the process as difficult, and certainly not insurmountable. Agree, and correct (I did the same with URI

  1   2   >