Re: [dns-operations] Implementation of negative trust anchors?

ghten your grip, Tarkin, the more star systems will slip through your fingers. Ecologies that place heavy emphasis on "security" have been empirically proven to fail at scale (population and/or time). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[dns-operations] DNSSEC and Re: DNS Attack over UDP fragmentation

wrong in our plan to save the Internet(TM) is that DNSSEC's armor against cache poisoning has being used as malicious payload in DDoS attacks via reflections. But because the 'baddies" are after more than DDoS, we can't just drop DNSSEC and be better off. (Cur reference to tal

Re: [dns-operations] DNS Attack over UDP fragmentation

the root servers. > Or cache only after validation? I shudder to think there's an alternative. If you are going to cache anyway, don't waste your time validating. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar

Re: [dns-operations] Should medium-sized companies run their own recursive resolver?

ons@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edwa

Re: [dns-operations] Alert: Massive increase in type A6 queries.

shot in the dark. And likely a poor one. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. _

Re: [dns-operations] summary of recent vulnerabilities in DNS security.

n have changed. [0] http://en.wikipedia.org/wiki/In_the_long_run_we_are_all_dead#Macroeconomic_usages -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no

Re: [dns-operations] summary of recent vulnerabilities in DNS security.

at mechanism was not novel in Kaminsky's description. His major contributions were first exposing how to perform an insertion attack when not "on the path" and secondly he visualized the consequences to people. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[dns-operations] It's begun...

My sensors show 4 new gTLDs in the last hour or so...IDN, non-ccTLD...added between 1800 and 1900 UTC. Anyone else see this? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571

[dns-operations] What do you call them?

scripts we will see. So - what will the dns operations community use to name these TLDs when there are issues with the new gTLDs that are in the xn-- "category" ? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar

Re: [dns-operations] All NSs for a TLD being in the TLD itself

o a multi-homed LAN or two routes that diverge geographically. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - ju

[dns-operations] Opinions sought .... have I come to the right place?

w for DNSSEC? So, I'm turning to this list...what is a good range for TTLs? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Why is it that people who fear government monitoring

Re: [dns-operations] Opinions sought .... have I come to the right place?

0:24, Jelte Jansen wrote: > On 11/07/2013 03:52 PM, Edward Lewis wrote: > ...which would give you only the drawbacks and not the upside... Fully aware that recursive servers are optimizing for their experience but that comes at the cost of predictability. That sounds like a negative statemen

Re: [dns-operations] algorithm rollover strategies

s been made about the confusion over the definition of a "domain name" in STD 13 and "host name" in RFC 1123. Context matters. So - I wish we could measure the impact of what has been deployed. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edw

Re: [dns-operations] chrome's 10 character QNAMEs to detect NXDOMAIN rewriting

good or better job too. Joe's right in general, but it's not that the admins are lazy (putting words in his mouth) - it's the energetic ones that can/may prove to be the "root cause" some day. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- E

Re: [dns-operations] xn--l1acc TLD gone bad already

perational thorns on my reports, I've learned to accept that not all TLDs have the same goals in mind and if the responsible party doesn't care, it's not an outsider's business to make them care. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Le

Re: [dns-operations] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root

>From: dns-operations-boun...@mail.dns-oarc.net ... >Sent: Friday, April 04, 2014 5:20 AM >To: dns-operati...@dns-oarc.net >Subject: [dns-operations] Introducing CNAME Flattening: RFC-Compliant CNAMEs > at a Domain's Root > >http://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-c

Re: [dns-operations] Introducing CNAME Flattening: RFC-Compliant CNAMEs at a Domain's Root

This all smells like something that the IETF is suited to help with. I mean, operators, multiple implementations, desires for interoperability... (Jus'sayin') From: dns-operations-boun...@mail.dns-oarc.net [dns-operations-boun...@mail.dns-oarc.net] On B

Re: [dns-operations] resolvers considered harmful

Talk about a DNS amplification attack - a seven page paper getting 60+ messages. I didn’t do the math, but I bet more was written about the paper than in the paper. With all this list traffic, I feel compelled to join in. If you have work to do, you might want to skip the rest of the message. Mo

Re: [dns-operations] cool idea regarding root zone inviolability

Not meant to rain on the parade (but this sounds like it) - early on In the development of DNSSEC we spent a bit of time on SIG(AXFR) which is exactly what you described. We toyed with it and discarded it. I forget why (which makes this a “rain on the parade” email) but for a long time afterwards

Re: [dns-operations] cool idea regarding root zone inviolability

After reading on… I think the rationale of killing SIG(AXFR) was that DNSSEC is there to protect the relying party and not the manager of the zone. I.e., a relying party only cared about the data it received pertinent to the query it issued. This made the building the chain of trust as efficient

[dns-operations] Wither to revive SIG(AXFR) was Re: cool idea regarding root zone inviolability

Caution - Basic engineering rationale philosophy argument herein. (I.e., barely worth the stamp I put on the letter.) On 11/27/14, 20:04, "George Michaelson" wrote: >I'd struggle to say that was a bad idea. It isn’t just “good” or “bad” idea that needs judging, but, is it worth doing? For wha

Re: [dns-operations] knot-dns

On 12/15/14, 14:40, someone wrote: >My point is that the negatives far outweigh the benefits in most >organizations. The problem with broad generalizations is that they are always wrong. (Meant as a joke.) I skimmed this thread now and then and thought about my experience in building and operat

Re: [dns-operations] extra records in resolver answer, any benefit?

On 1/27/15, 5:46, "bert hubert" wrote: >Can you name me one client side application that benefits from anything >other than the answer section? This may have been meant as a rhetorical question, but it’s pretty interesting. I’ve thought much over the years about a way to mathematically reduce t

Re: [dns-operations] CloudFlare policy on ANY records changing

On 3/6/15, 10:05, "Olafur Gudmundsson" wrote: > > We will be depreciating support for ANY queries and return NOTIMP in the near > future > https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ > > ID proposing this behavior will be forthcoming I simultaneoulsy requested on on DNSOP

Re: [dns-operations] CloudFlare policy on ANY records changing

On 3/6/15, 11:11, "Paul Wouters" wrote: >On Fri, 6 Mar 2015, Olafur Gudmundsson wrote: > >> We will be depreciating support for ANY queries and return NOTIMP in >>the near future >> https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/ >> >> ID proposing this behavior will be forthco

Re: [dns-operations] Saga of HBONow DNSSEC Failure

On 3/9/15, 23:50, "Livingood, Jason" wrote: >So earlier today HBO announced a new HBONow streaming service (at an >Apple event). The FQDN to order, which should have been DNSSEC-enabled, >was order.hbonow.com. This unfortunately suffered from a rather >inconveniently timed DNSSEC problem >(http:/

[dns-operations] What would it take...

...to prevent another DS<-->DNSKEY mishap from happening again? I'm presenting the message to the DNS Operations list of DNS-OARC. (Being subscribed to so many DNS lists I keep forgetting if I'm acting as an IETF participant or talking as a past operator of DNS or as ) In short, think about

Re: [dns-operations] What would it take...

On 3/10/15, 16:45, "Mark Andrews" wrote: > >Why don't we just implement TSIG signed updates... In the sense of "baby steps first" - what I'm driving towards "error detection", ensuring that the zone-to-be is in line with it's environment. Getting to "error correction" is the next level, but comp

Re: [dns-operations] What would it take...

On 3/11/15, 13:31, "Doug Barton" wrote: >Neither solves the problem of authenticating the entity which is sending >the DS update. Note that my request was not for a means to update the parent but to prevent the child from shooting themselves in the foot. A much less involved operation. Perhaps

Re: [dns-operations] What would it take...

On 3/11/15, 14:19, "Doug Barton" wrote: >I think it would be Ok to put up a large, difficult to ignore warning >that the user is about to do something painfully stupid, sure. How much >farther than that to go is an exercise for the implementors. To go a little deeper into what I witnessed up clo

Re: [dns-operations] What would it take...

> On Mar 11, 2015, at 16:18, Rob Foehl wrote: > What about the case of bad data in the parent, regardless of where it lands > on the malice / stupidity scale? Loud warnings to this effect at zone > (re)load time would be one thing, but refusing to load the zone entirely > would mean the bro

Re: [dns-operations] What would it take...

On 3/11/15, 16:52, "Tony Finch" wrote: >Edward Lewis wrote: >> >> Note that my request was not for a means to update the parent but to >> prevent the child from shooting themselves in the foot. A much less >> involved operation. > >In this immediate

Re: [dns-operations] Operations vs. the lab (Was: What would it take...)

On 3/11/15, 15:32, "Doug Barton" wrote: >It's unfortunate that while on the one hand the IETF makes nice smoochy >noises about wanting input from operators, on the other hand that input On 3/12/15, 12:41, "Fred Morris" wrote: >I'm not attending IETF events, so I don't know what is occurring, bu

Re: [dns-operations] dnsop-any-notimp violates the DNS standards

On 3/16/15, 11:05, "bert hubert" wrote: >Sorry? We solve implementation hardship by standards action now? My thoughts in this thread (and I'm choosing to keep this in dns-operations) keep circling because I've spent time at different perspectives. On one hand we like to say that the Internet

Re: [dns-operations] [DNSOP] dnsop-any-notimp violates the DNS standards

(Choosing DNS-operations.) On 3/13/15, 18:21, "Darcy Kevin (FCA)" wrote: >IANAL, but I think this might have legal ramifications. If they are >advertising/selling "DNS" services and what they are delivering is not >"DNS", then Truth in Advertising and/or Bait-and-Switch statutes, >regulations an

[dns-operations] resimprove and Re: DNS Flush Protocol

On 3/27/15, 16:00, "Paul Vixie" wrote: >Warren Kumari wrote: >> ... >> >> I was saying is that we don't really need to reach *every* recursive, >> whatever we do manage to do will be better than the current position. > >i disagree. a solution for the big resolvers will decimate incentive for >any

Re: [dns-operations] resimprove and Re: DNS Flush Protocol

On 3/27/15, 20:09, "Paul Vixie" wrote: >Edward Lewis wrote: >> On 3/27/15, 16:00, "Paul Vixie" wrote: >> >>not just hijacked. see also "oops". My response began with objecting to the notion that we should ignore measurements of how the Int

Re: [dns-operations] resimprove and Re: DNS Flush Protocol

On 3/30/15, 19:07, "Paul Vixie" wrote: >if you want something that we can reach consensus on, that will be a >recommendation, and will be a protocol ("if you want to do this, here's >how to do it interoperably") then that will take at least "many more >years" if it's even possible, which i doubt.

Re: [dns-operations] resimprove and Re: DNS Flush Protocol

On 3/31/15, 13:49, "Paul Vixie" wrote: > the descendant's apex NS TTL has a higher credibility. A nit - RFC 2181 uses trustworthiness, not credibility. I had to "fix" that in my discussions on the topic. (Trying to stem terminology creep.) >if you have an alternative in mind that uses some ot

Re: [dns-operations] Stunning security discovery: AXFR may leak information

Newsflash: Water can make you wet. Sorry. On 4/14/15, 4:23, "Stephane Bortzmeyer" wrote: >https://www.us-cert.gov/ncas/alerts/TA15-103A >http://haxpo.nl/haxpo2015ams/sessions/all-your-hostnames-are-belong-to-us/ smime.p7s Description: S/MIME cryptographic signature ___

Re: [dns-operations] Stunning security discovery: AXFR may leak information

On 4/14/15, 8:29, "Mark Jeftovic" wrote: >Joke all you want. This is worse than heartbleed. In short and if I understand this correctly, the problem isn't AXFR's existence or use, the problem is that systems are poorly configured. It's like blaming your aorta if a cut causes blood to spill. Th

Re: [dns-operations] Stunning security discovery: AXFR may leak information

On 4/14/15, 14:47, "Marjorie" wrote: >The bottom line is that unrestricted AXFR is generally evil, I'd go with "generally unwise". There are folks that believe it is fine to allow access to their zones and I have no reason to say they are foolish. Folks who are not concerned with the minutia o

[dns-operations] Postures was Re: Stunning security discovery: AXFR may leak information

John Crain alluded to the point I want to reinforce here. There are many different operational postures. It's tempting to see a situation as it applies to just one. The three snips below illustrate common environments I've run across - TLD (/registration zones), remote debugging (/third-party ma

Re: [dns-operations] Postures was Re: Stunning security discovery: AXFR may leak information

On 4/15/15, 7:42, "George Michaelson" wrote: >So on that basis: the FTP rule passes: we have open FTP, why would we >block AXFR? It's your call, it's local policy. I've worked in environments where the name servers answering queries did not implement the AXFR mechanism. "Generally unwise" can

Re: [dns-operations] Postures was Re: Stunning security discovery: AXFR may leak information

On 4/15/15, 9:01, "Tony Finch" wrote: >Edward Lewis wrote: >> >> (By the same token, why would one use NSEC3 for signed zones when the >>zone >> is available over FTP?) > >Opt-out. I thought I was going to avoid expanding the discussion int

Re: [dns-operations] calculating DNSSEC keytags in sed (was: RE: calculating DNSSEC keytags in awk)

On 4/16/15, 9:27, "Frank" wrote: >I do not want to read it. I want to calculate it. Start with RFC 4034 "Resource Records for the DNS Security Extensions", Appendix B "Key Tag Calculation". smime.p7s Description: S/MIME cryptographic signature ___ d

Re: [dns-operations] Authoritative name server replies NODATA for a non-existing domain

On 4/23/15, 2:45, "Michał Kępień" wrote: >> Yes, its due to bug: >> >> • Fix RCODE when secondary NSD got transfer that includes deleted >>wildcard record. After deletion, NSD would serve NODATA, should be >>NXDOMAIN (thanks Michal Kepien). > >This is fun - I never expected this bug to be p

Re: [dns-operations] [Security] Glue or not glue?

On 5/4/15, 3:11, "Stephane Bortzmeyer" wrote: >A new edition of the DNS security guide by ANSSI (French cybersecurity >agency) recommends to prefer delegations with glue because glueless >delegations "may carry additional risks since they create a >dependency". Is there any other "best practices"

Re: [dns-operations] Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.

Overall question. Looking at the chart on that URL, it seems like things are trending the wrong way, with the possible exception of the one well-performing bunch - the "Bottom 1000 Servers" [sic]. Is that right? Excepting the one bump up on May 20, it seems like things are actually trending down

[dns-operations] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.

I'm reacting because I see a case of someone observing symptoms, presenting eye-catchy colorful pictures and then running hard into the land of diagnosis. On 5/27/15, 7:10, "Mark Andrews" wrote: >For others is is scrubbing / DoS services which are blocking EDNS(1) >queries. This sounds like the

Re: [dns-operations] EDNS vs DDOS scrubbing - was Re: Nice to see Amazon Route 53 remove the EDNS(1) filters for *.co.uk.

On 5/27/15, 9:09, "Roland Dobbins" wrote: >On 27 May 2015, at 19:00, Mark Andrews wrote: > >> Yes, EDNS compliance issues have been traced to scrubbing services and >> firewalls. > >Competent DDoS scrubbing <> EDNS0 problems, FYI. If that's happening >with some specific scrubbing service, it's b

Re: [dns-operations] DNSSEC issue - why?

On 6/9/15, 3:12, "Kevin Chen" wrote: >> >>which looks quite simple, however the KSK DNSKEY from hollington.ca is >> part of the DS set. The only notable part of the DS set is that it >> contains 4 keys, among which is an older (?) with a longer hash. > >RFC 4509 says: > >Implementations MUST

Re: [dns-operations] DNSSEC issue - why?

On 6/9/15, 7:42, "Mark Andrews" wrote: >How could it be done "per key"? keyid's don't identify a key. They >identify a set of keys. Perhaps but in practice that's not happened. Some key management software won't produce a DNSKEY RR matching an existing keyid. And - "per key" could still be d

[dns-operations] Downgrade attack readiness Re: DNSSEC issue - why?

On 6/9/15, 10:24, "Casey Deccio" wrote: > But when you consider a downgrade attack, the attacker only needs the lowest > hanging fruit. That means that *any* DS (regardless of DNSKEY) with the > weaker digest type could potentially be used for falsifying a DNSKEY. I'm just going to throw this o

[dns-operations] Trying - Re: Fwd: Re: [Security] Glue or not glue?

On 6/9/15, 20:29, "Mark E. Jeftovic" wrote: >But I don't see it happening. (Caution - this all soapbox jibber-jabber:) http://www.goodreads.com/quotes/854398-trying-is-the-first-step-towards-fai lure “Trying is the first step towards failure” -- Homer Simpson http://www.imdb.com/character/ch

Re: [dns-operations] about anti-ddos DNS hostings

On 6/11/15, 1:30, "bert hubert" wrote: Quoting : >Geoff Huston's thinking on ... http://labs.apnic.net/?p=624 (CC'd Geoff in case he's not on this list.) >Can we shift our >collective focus back to the common good, and shift our focus away from >selected potential victims who can afford private

Re: [dns-operations] about anti-ddos DNS hostings

On 6/16/15, 16:13, "Florian Weimer" wrote: >* Edward Lewis: > >> It's not just a matter of the rich getting richer and the poor getting >> poorer, it's a matter rooted in a technical fault in the architecture of >> the system. > >It'

Re: [dns-operations] Verifying that a recursor is performing DNSSec validation

On 7/14/15, 1:08, "dns-operations on behalf of Frank Bulk" wrote: >Is there an existing tool, ideally a NAGIOS-friendly one, that performs a >check against a resolver that it gets an AD back on DNSSec query for a >zone >that is properly signed, failure for one that is not properly signed, and >no

Re: [dns-operations] Verifying that a recursor is performing DNSSec validation

Come to think of it, does DNS-OARC have a set of such zones? I have a vague memory that this may have been set up once. If not, might this be a good idea to provide? (Alongside other test services like reply size as described here: https://www.dns-oarc.net/oarc/services/replysizetest) (An idle

Re: [dns-operations] [Ext] Re: Surprising behaviour by certain authoritative name servers

On 1/8/20, 7:40 AM, "dns-operations on behalf of Niall O'Reilly" wrote: On 7 Jan 2020, at 12:53, Greg Choules wrote: > I don't think it's a protocol violation, I think that's arguable. RFC1035, section 6.1.3: Both the TTL data for RRs and the timing data for refr

Re: [dns-operations] [Ext] Re: any registries require DNSKEY not DS?

Answering a pair of messages in one reply: On 1/23/20, 5:25 AM, "dns-operations on behalf of Paul Vixie" wrote: >On Thursday, 23 January 2020 02:51:28 UTC Warren Kumari wrote: >> ... >> >> If the parent makes the DS for me from my DNSKEY, well, then the DS >> suddenly "feels" like it belongs

Re: [dns-operations] [Ext] Re: Is this DNS Flag Day 2020 including 'in-addr.arpa.' and 'ip6.arpa.' clean-up?

I've been doing some examinations of ip6.arpa and in-addr.arpa as part of other work and I'd say they are pretty darn clean as they are. So I (too) am curious what would be needed as part of a "Flag Day" level clean up. I'm looking at the delegation information in the two zones and the informat

Re: [dns-operations] [Ext] Re: Is this DNS Flag Day 2020 including 'in-addr.arpa.' and 'ip6.arpa.' clean-up?

I think the reaction you are getting is due to the call for a "DNS Flag Day" and not the issues you are experiencing. On this list (DNS-operations), DNS Flag Day (2019) was a significant event involving many implementations of the DNS protocol to adhere more closely with the specifications of t

Re: [dns-operations] [Ext] Re: Stale NTA for "peek.ru" at Cloudflare?

Responding to two messages, perhaps with a "get off my lawn" old-guy attitude: On 3/13/20, 4:59 PM, "dns-operations on behalf of Marek Vavruša" wrote: >the DSA-NSEC3-SHA1 has been deprecated in >https://tools.ietf.org/html/rfc8624 so zones below DS with these keys >are effectively treated as u

Re: [dns-operations] [Ext] Progress on algorithm 5 and 7 decommissioning

This is visible in the attached chart of ccTLD "crypto-choices". (I'm on the agenda for ICANN 69's Tech Day to talk about DNSSEC in the TLDs. I'll have longer-term views of that chart in the slide deck, this just focuses on 2020.) On 10/12/20, 9:14 PM, "dns-operations on behalf of Viktor Dukho

Re: [dns-operations] [Ext] Progress on algorithm 5 and 7 decommissioning

On 10/14/20, 12:29 PM, "dns-operations on behalf of Viktor Dukhovni" wrote: On Wed, Oct 14, 2020 at 03:27:35PM +0000, Edward Lewis wrote: > This is visible in the attached chart of ccTLD "crypto-choices". (I'm > on the agenda for ICANN 69's

Re: [dns-operations] [Ext] Progress on algorithm 5 and 7 decommissioning

On 10/14/20, 2:24 PM, "dns-operations on behalf of Viktor Dukhovni" wrote: >These give a much broader picture of DNSSEC practice that what one learns by >looking at just the ~1500 TLD DNS/DNSKEY RRsets. That's true. Drawing from an old conversation on the data I've been curating "how (or wha

Re: [dns-operations] [Ext] Historical reminiscences (was Re: nsec vs nsec3 use)

On 4/13/21, 7:38 PM, "dns-operations on behalf of Andrew Sullivan" wrote: >Maybe some others have a different memory of this, though? I agree with that re-telling. The idea of an opt-out/in existed prior to NSEC3, it was even implemented in experimental code but never released because the I

[dns-operations] Registration Operations Workshop #10

ROW#10: Register now & submit your proposal June 8th, 2021 | 13:00 - 16:00 UTC | Zoom Video Conference ROW#10 will be held via remote participation on June 8th, 2021, 13:00 - 16:00 UTC. Check additional time zones here

[dns-operations] ROW#10 - Final call for proposals

ROW#10: Register now & submit your proposal before May 14th, 2021 The 10th Registration Operations Workshop [regiops.net] (ROW#10) is scheduled to take place via

Re: [dns-operations] [Ext] Re: DNSSEC and multiple signatures

On 5/17/21, 8:15 PM, "dns-operations on behalf of Viktor Dukhovni" wrote: >Bottom line: make sure *all* your signatures are valid, if you sign >with multiple algorithms... I disagree with that advice. Building a truly verifiable (following all the rules as well as cryptographic calculations)

[dns-operations] The 10th Registration Operations Workshop (ROW#10) | June 8th, 2020 | 13:00 - 17:00 UTC

The 10th Registration Operations Workshop (ROW#10) | June 8th, 2020 | 13:00 - 17:00 UTC ROW#10 will take place via Zoom Webinar platform on Tuesday, June 8th, 2021, 13:00 – 17:00 UTC. Additional time zones may be checked here

Re: [dns-operations] [Ext] Re: why does that domain resolve?

On 6/10/21, 2:35 AM, "dns-operations on behalf of Petr Špaček" wrote: >Personally, with all the experience we have in 2021, I find the historic >decision to put authoritative NS RRs to the child side to be a poor >choice, to the point of being indefensible. > >As Anthony points

Re: [dns-operations] [Ext] Re: Checking for signatures of a certain DNSKEY within a zone

On 7/6/21, 12:15 PM, "dns-operations on behalf of Tony Finch" wrote: >If it is one of your zones then your key management software should ensure >that all the key IDs are different, i.e. if there is an ID collision when >generating a key, throw it away and regenerate it. This is impo

[dns-operations] Follow up to the talk - Beta availability of Two Data Sets

(This isn't operational, but it relates to the DNS-OARC workshop held last week. Which raised a side question: Ought there be a dns-resea...@lists.dns-oarc.net?) As a follow up comments that JSON is necessary I've added a JSON version for each CSV file on the DNS Core Census website. Ev

Re: [dns-operations] [Ext] Re: ENT NXDOMAIN problem at .BS nameserver ns36.cdns.net

I think there is still something broken. Using edu.bs, which seems to be working, the name ub.edu.bs can be resolved. If one queries for the SOA at edu.bs, the negative answer is the right answer – showing the SOA record owned by bs. Asking for the SOA for com.bs., the responses I see, from al

Re: [dns-operations] [Ext] Re: Cloudflare TYPE65283

On 3/27/23, 9:08 PM, "dns-operations on behalf of Viktor Dukhovni" wrote: >Perhaps, but until the mythical post-quantum DNSSEC is needed, online >signers will use ECDSA, for which denial of existence is already >sufficiently compact, even with 4 RRSIGs (SOA + 3 NSEC3). Idle muttering

Re: [dns-operations] [Ext] Re: Cloudflare TYPE65283

From: "p...@redbarn.org" Date: Tuesday, April 11, 2023 at 11:11 AM To: "dns-operati...@dns-oarc.net" , Edward Lewis Subject: Re: [dns-operations] [Ext] Re: Cloudflare TYPE65283 >Well, we are overdue for starting over on dnssec, which we used to do every >two year

Re: [dns-operations] [Ext] Re: .RU zone failed ZSK rotation

Very interesting. There have been two cases since 2011 of a TLD having two published DNSKEY resource records sharing the same key_tag. The first in 2018/2019 involved a TLD having a KSK and ZSK share. I didn't notice while it was happening, but found it when testing some code I have to visual

[dns-operations] A follow upRe: [Ext] Re: .RU zone failed ZSK rotation

;,"ZONE","DNSSEC","RSASHA256","1024","52263","LARGE","AwEAAbjj3GP0TUw... Key tags do collide, but rarely (so far) at the same time. I haven't quantified this, I just happened to look to see if my data included the two keys that ca

Re: [dns-operations] [Ext] Re: .RU zone failed ZSK rotation

On 2/8/24, 10:40, "dns-operations on behalf of Viktor Dukhovni" wrote: The chances of a remotely possibly event happening is 100% once it happens. __ So long as a hash is shorter than the data it covers, there's a chance there will be a collision. Just a general statement. >There is no i

Re: [dns-operations] Upcoming Registry Service Provider Evaluation Program

I have some data on this. Trying to convey this in email is hard, so here’s a link to slides from Nov 2022 explaining the data: https://www.icann.org/en/system/files/files/presentation-consolidation-amongst-top-level-domains-15nov22-en.pdf Below is a chart (pulled from debug output) for 18 Feb

Re: [dns-operations] [Ext] Re: Evaluation of NSEC3-encloser attack

On 3/27/24, 17:34, "dns-operations on behalf of Jim Reid" wrote: >IMO, there’s no added value in using NSEC3. NSEC3 has opt-out, which is important for large, delegation-centric zones. Noting, I'm no fan of NSEC3, but it does have that going for it. _

[dns-operations] A request for "data"

An open question... Is anyone aware of any use of Automated Updates of DNS Trust Anchors, documented in RFC 5011, in the last 5 years or so? Does anyone know of a zone (other than the root) that documents or publicizes a reliance on Automated Updates? For the record, the last time a ccTLD pub

Re: [dns-operations] [Ext] Re: A request for "data"

From: dns-operations on behalf of Joe Abley Date: Saturday, April 27, 2024 at 02:50 To: Warren Kumari Cc: "dns-operations@lists.dns-oarc.net Operations" Subject: [Ext] Re: [dns-operations] A request for "data" >It's a big Internet. There is a lot of surprising stuff in it. I find it's >usua

Re: [dns-operations] The (very) uneven distribution of DNS root servers on the Internet

quot;ok, the number is way more precise than accurate." (As in "1.544 +/- 2" was the follow up joke.) I'd say that is the same label that could be put on this article. The numbers probably are precise, but don't carry the "accurate" story. -- -=-=

[dns-operations] "bad infosec economics " Re:

bout it in 2012. So, use it with caution. PS - One possibility, instead of simply not responding, send back rcode=REFUSED. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice mess

[dns-operations] I know I'm a curmudgeon but

server or displaying a reply from the server. If you´d like to turn off the IDN support for some reason, defines the IDN_DISABLE environment variable. The IDN support is disabled if the variable is set when dig runs. I like the "for some reason" quip. -- -=-=-=-=-=-

Re: [dns-operations] I know I'm a curmudgeon but

messing with my mind. At 11:39 -0400 7/9/12, Edward Lewis wrote: Running dig on a newly built Linux machine I see the below output (and man page explaining it). To me this just seems wrong. Mucking with the bare metal here is not desirable. The zone *is* x n - - x k c 2 a l 3 h y e 2 a . ,

Re: [dns-operations] I know I'm a curmudgeon but

At 17:53 +0200 7/9/12, Benny Pedersen wrote: Den 2012-07-09 17:39, Edward Lewis skrev: $ dig xn--xkc2al3hye2a. ns dig +trace xn--xkc2al3hye2a ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0 2 last zerro is bad sign The name isn't a problem, it's

Re: [dns-operations] I know I'm a curmudgeon but

tried the man page "fix" the problem didn't go away. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars! _

Re: [dns-operations] Name server turning off RD bit in response - just curious

#x27;s like doing 60 in a 55 zone, on paper it's an infraction but it makes no material difference. There are many places where the old RFCs either over or under specified actions. This is a case over over specification. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: [dns-operations] dotless domains

. Worked fine with Chromium and lynx, despite the ICANN FUD. In Safari, http://dk./ "worked" while http://dk/ didn't. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5

Re: [dns-operations] email address in SOA

the old spouse's tales is that it does thus raising the fear of putting real data there. Much of what is now done operationally in DNS is rooted in folklore, rooted neither in real threats nor standards. ;) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis

[dns-operations] BIND 9.7 was Re: what nameserver software have you been using?

than 9.9!) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ dns-operations mailing

Re: [dns-operations] are we adding value?

ves it's own discussion. I'm refraining from using a quick analogy because that tack alone is not a good way to express concepts that are ill-formed. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message

[dns-operations] 10% was Re: .mm ....

y times like that really a good idea? If all > all validators allowed a 10% overrun, DNS operators would just > get 10% sloppier and we would back where we started. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou

Re: [dns-operations] 10% was Re: .mm ....

On Jan 18, 2013, at 12:18, Dobbins, Roland wrote: > > On Jan 18, 2013, at 11:05 AM, Edward Lewis wrote: > >> Adding security to an existing system will, inherently, make it more >> brittle. > > I strongly disagree with this statement. Increasing resilience unde

Re: [dns-operations] RRL specified in a stable place?

along? Is this a DNSOP draft? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ dns-operations mailing list dns-operations@lists.d

Re: [dns-operations] Another whitepaper on DDOS

So - take this as you will. And finally - the event happened last summer and was ongoing when I wrote the blog entry in the fall. I don't know if it is still ongoing, I don't expect to hear back from anyone nor is it really my business to know. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

  1   2   >