Re: [dns-operations] DNSbomb attack

--- Begin Message --- Apologies please. I meant all DNS responders not merely DNS full resolvers. p vixie On May 28, 2024 13:08, Paul Vixie via dns-operations wrote: ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https

Re: [dns-operations] DNSbomb attack

--- Begin Message --- This attack was predicted by DNS RRL in 2012 and as such is not novel. All full resolvers should make RRL the default, as BIND9 seems to have done. https://circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns I am in full support of ISC's position

Re: [dns-operations] Strange things at C root name server

--- Begin Message --- Yes. See: https://c.root-servers.org/ p vixie On May 24, 2024 13:31, Cameron Banowsky via dns-operations wrote: ___ dns-operations mailing list dns-operations@lists.dns-oarc.net

[dns-operations] C-root incident

--- Begin Message --- News 2024‑05‑23 - On May 21 at 15:30 UTC the c-root team at Cogent Communications was informed that the root zone as served by c-root had ceased to track changes from the root zone publication server after May 18. Analysis showed this to have been caused by an unrelated

Re: [dns-operations] DNS Operations

--- Begin Message --- Openwrt is fine. See also pihole. I just run bind9. Knot, powerDNS, and unbound are also great. p vixie On Mar 2, 2024 09:56, Lee wrote: On Sat, Mar 2, 2024 at 8:55 AM David Conrad wrote: > > Hi, > > On Mar 2, 2024, at 4:57 AM, Lee wrote: > > On Sat, Mar 2, 2024 at

Re: [dns-operations] Filtering policy: false positive rate

--- Begin Message --- I think the examples being used in this thread are too narrow. In RPZ a firewall rule might trigger on something other than the QNAME. For example the trigger could be one of the NSDNAMEs in the resolution path, or on the address (A or ) associated with some NSDNAME in

Re: [dns-operations] xn--mgbai9azgqp6j broken

--- Begin Message --- I think uptime has high correlation to utility. p vixie On Oct 23, 2023 11:39, Stephane Bortzmeyer wrote: On Thu, Oct 19, 2023 at 02:02:22PM +, Carr, Brett via dns-operations wrote a message of 265 lines which said: > This may have been mentioned before as I

Re: [dns-operations] DNS over TCP response fragmentation

--- Begin Message --- if the dns responder uses write() or send() or sendto() for the two octets of framing length, rather than writev() or sendmsg(), the kernel's default will be to "push" each buffer as a segment. that's where the one- or two-octet segments are probably coming from. this

Re: [dns-operations] Google Public DNS has enabled case randomization globally

--- Begin Message --- Paul Vixie via dns-operations wrote on 2023-07-29 17:35: back in the day, only one rdns server was downcasing on cache miss, and it was one of google's. dave presotto fixed it in about a day. apologies (obvious). it was an authority for l.google.com, not rdns. -- P

Re: [dns-operations] Google Public DNS has enabled case randomization globally

--- Begin Message --- Evan Hunt wrote on 2023-07-29 13:58: (Resending because I accidentally replied privately.) likewise. Evan Hunt wrote on 2023-07-29 13:55: On Sat, Jul 29, 2023 at 09:07:21AM -0700, Paul Vixie wrote: ... would the google dns team be willing to contribute to this draft

Re: [dns-operations] Google Public DNS has enabled case randomization globally

--- Begin Message --- > would the google dns team be willing to contribute to this draft in the ietf dns wg? we have not pressed the matter since 2008 simply because noone cared.

Re: [dns-operations] Cache efficiency (was: Re: DNS .com/.net resolution problems in the Asia/Pacific region)

--- Begin Message --- Robert Edmonds wrote on 2023-07-20 14:50: Mark Andrews wrote: ... Yes, there are lookups that can take a long time to perform with a cold cache. By putting lots of users behind large, centralized caches we can insulate users from a lot of cold cache lookups, but these

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

--- Begin Message --- Ondřej Surý wrote on 2023-07-18 13:25: ... There’s already mechanism for not serving a stale RRSIGs. The EXPIRE field in the SOA record should be set to a value that’s lower than the RRSIG resigning interval (the minimal interval between now and shortest RRSIG expiry

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

--- Begin Message --- i have two comments here. Ondřej Surý wrote on 2023-07-18 11:54: With my implementor’s hat on, I think this is wrong approach. It (again) adds a complexity to the resolvers and yet again based (mostly) on isolated incident. I really don’t want yet another “serve-stale”

Re: [dns-operations] DNS .com/.net resolution problems in the Asia/Pacific region

--- Begin Message --- On Thu Jul 13, 2023 at 7:16 PM UTC, Gavin McCullagh wrote: > ... > > I assume lots of us on this mailing list operate authoritative dns > servers. When one of our PoPs or nameservers is unresponsive, most of us > rely on retries against other nameservers (aka PoPs) to ensure

Re: [dns-operations] Ani Piracy - RPZ Feed

--- Begin Message --- if such is found, please submit it for inclusion here: https://dnsrpz.info/ re: Renyk de'Vandre wrote on 2023-05-26 05:11: Hi All, Can anyone recommend a good quality anti-piracy RPZ feed?   Looking to block access to video/music piracy websites. Many Thanks! -- P

[dns-operations] why DNS can't have nice things

--- Begin Message --- once an embedded dns recursive server works well enough, it ships, is widely deployed, and becomes abandonware. the apps which don't work are found (by others) later. there is no complaint path. ; <<>> DiG 9.16.33 <<>> api.dnsdb.info ;; global options: +cmd ;; Got

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

--- Begin Message --- <8, RSA-SHA1 vs RSA-SHA1-NSEC3). But a new on-the-fly denial of existence might prove to be worth it in operations.>> Well, we are overdue for starting over on dnssec, which we used to do every two years or so. But does the next generation have the will to do so? p

Re: [dns-operations] [DNSOP] bind fails to continue recursing on one specific query

--- Begin Message --- i think there's language slippage in this thread. Peter DeVries wrote on 2023-03-29 03:51: On Tue, Mar 28, 2023, 9:23 PM Dave Lawrence > wrote: ... It is very poor form for nameservers to intentionally not respond to queries under normal

Re: [dns-operations] Resolvers seeing repeated bursts of identical queries

--- Begin Message --- if the same IP is asking the same qname over and over, then you might want to look into DNS RRL, which was originally a BIND thing but which all open source name servers now possess in some form. it was crafted for authority (really, root and TLD) servers, but does also

Re: [dns-operations] Browser Public suffixes list

--- Begin Message --- Viktor Dukhovni wrote on 2022-08-27 11:06: On Sat, Aug 27, 2022 at 10:48:46AM -0700, Paul Vixie wrote: ... see: https://www.ietf.org/mailman/listinfo/dbound Another aspect of the problem, is that the browsers unified the address bar and the search bar in order

Re: [dns-operations] Browser Public suffixes list

--- Begin Message --- this... Meir Kraushar via dns-operations wrote on 2022-08-27 02:56: 2) The need to maintain a list dedicated to browser issues is out of our scope. I'm sure there are good reasons to have it, like you said, there is gap between the worlds. ...is why the IETF DBOUND

Re: [dns-operations] mail.protection.outlook.com has EDNS issues

--- Begin Message --- Matthew Richardson wrote on 2022-07-06 07:52: ... Alternatively, is this the sort of issue in which DNS-OARC could become involved by way of outreach to MS about the problems? The lack of EDNS0 will probably become an increasing problem over time. This DNS setup is

Re: [dns-operations] [Ext] How should work name resolution on a modern system?

--- Begin Message --- David Conrad wrote on 2022-06-16 08:26: ... What ISC defined as “views" in BIND 9 is simply an implementation of an independent namespace. The fact that it is (now) most frequently used in the context of an independent address space is irrelevant. when considering

Re: [dns-operations] How should work name resolution on a modern system?

--- Begin Message --- Dave Lawrence wrote on 2022-06-15 10:33: Viktor Dukhovni writes: Single label names passed to getaddrinfo(3) should not result in single label "A" or "" DNS queries. http://ai./ https://www.icann.org/en/system/files/files/sac-053-en.pdf -- P Vixie --- End

Re: [dns-operations] CNAME at the apex breaks DNSSEC DS lookups from caches

--- Begin Message --- Evan Hunt wrote on 2022-04-17 02:58: ... I was the original author of the ANAME draft, and I thought it was a terrible idea, and said so at the time. The only reason I wrote it was that I believed browser vendors would remain unwilling to adopt a more sensible

[dns-operations] DMV.CA.GOV to WCP please?

--- Begin Message --- the name servers are: dmv.ca.gov. 604763 IN NS ns7.net.ca.gov. dmv.ca.gov. 604763 IN NS infohqp5.ad.dmv.ca.gov. dmv.ca.gov. 604763 IN NS ns6.net.ca.gov. dmv.ca.gov. 604763 IN NS

Re: [dns-operations] [Ext] What is the reason of J-Root doesn't serve the arpa zone?

--- Begin Message --- Paul Hoffman wrote on 2021-12-03 19:28: On Dec 3, 2021, at 7:05 PM, Paul Vixie via dns-operations wrote: 2870 was wrong in this respect, and should be revised to allow ARPA. Why that, instead of the direction taken by RFC 9120? RFC 9120 was sponsored by the IAB

Re: [dns-operations] What is the reason of J-Root doesn't serve the arpa zone?

--- Begin Message --- Wessels, Duane via dns-operations wrote on 2021-12-03 15:39: In November 2002 K, L, and M were added to the NS list for arpa, but J was not. We can't speak to decisions made by the other operators, but Verisign chose not to put j.root-servers.net in the NS set based on

Re: [dns-operations] Full-service resolver - Pending Upstream Query behaviour

Paul Ebersman wrote on 2021-10-05 13:23: fneves> ... vcunat> I'm not sure if there can be *one* BCP way. Definitely would need to be more a bag of tricks that operators can mix/match based on their actual environment, customer base, etc. Paid vs free probably have different concerns and

Re: [dns-operations] Full-service resolver - Pending Upstream Query behaviour

Frederico A C Neves wrote on 2021-10-05 09:01: ... Anyway I think that even though the incident was not DNS related "We", as the DNS community, could probably do better in future events. I would like to start a discussion or to hear implenters and operators of Full-service resolvers on what

Re: [dns-operations] slack.com bogus

Paul Ebersman wrote on 2021-09-30 14:30: ... NTAs in production use aren't even vaguely new. They've been in wide use for 8-10 years that I'm aware of. They are part of why folks like google, cloudflare, comcast et al are willing to do DNSSEC validation in production. i know that. i just

Re: [dns-operations] slack.com bogus

Matthew Pounsett wrote on 2021-09-30 12:12: ... Negative Trust Anchors, most probably. It's standard operating procedure, particularly for the very large operators, to work around zones that are clearly broken and not actually being attacked to essentially turn off DNSSEC validation for those

Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS

dns.h header file, and the usage messages for the programs should be sufficient." 30 years later, still no man page? -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS

On Wed, Aug 18, 2021 at 12:56:14AM -0400, Viktor Dukhovni wrote: > On Wed, Aug 18, 2021 at 03:48:03AM +0000, Paul Vixie wrote: > > > On Wed, Aug 18, 2021 at 07:12:32AM +1000, Mark Andrews wrote: > > > ... Everything that comes off the wire needs to be checked. > >

Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS

ce bad stuff often. make problems hot, early, and fast, for implementations by fresh undamaged programmers who are ready to declare "works for me" and take off for their weekend. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dn

Re: [dns-operations] Ultra DNS responding with NXDOMAIN for "www.uber.com"

On Mon, Aug 09, 2021 at 11:01:02AM -0400, Dave Lawrence wrote: > Paul Vixie writes: > > On Sun, Aug 08, 2021 at 03:20:24PM +0530, Shreyas Zare wrote: > > > ... The resolver I have does restart for the last CNAME regardless > > > of the RCODE but, the negative cache impl

Re: [dns-operations] Ultra DNS responding with NXDOMAIN for "www.uber.com"

oritative responders fail earlier and more often. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

Viktor Dukhovni wrote on 2021-06-10 12:04: > On Thu, Jun 10, 2021 at 08:24:17AM +0200, Petr Špaček wrote: > >> ... > > I'm inclined to agree. Given a time-machine, and perverse priorities to > then use it to try to undo DNS "mistakes", I'd be inclined to try to > make "NS" be authoritative on

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

Benno Overeinder wrote on 2021-06-07 05:29: > On 04/06/2021 18:22, Anthony Lieuallen via dns-operations wrote: >> ...  Largely for issues like this: the child delegations can be wrong, >> but for the domain to work at all, the parent delegations must be >> correct.  (Resolvers that choose to

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

On Sat, Jun 05, 2021 at 04:11:43PM -0400, Viktor Dukhovni wrote: > On Sat, Jun 05, 2021 at 06:11:06PM +0000, Paul Vixie wrote: > > I expect these NS RRs to become visible in any validating full resolver that > > implements QNAME Minimization. that's not a protocol change. > >

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

pect these NS RRs to become visible in any validating full resolver that implements QNAME Minimization. that's not a protocol change. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

x NS names will never improve. > (Resolvers that choose to use child delegations will likely in this case > discover that these delegations are bogus, and be left with only the valid > delegations, from the parent.) at which point they should return SERVFAIL. fail

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

know for a fact that someone who argued the GDPR case was in fact carrying water for verisign? -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations

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

owever, first we had to uglify, complexify, and add another three to four years of "ideology delay". -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] UDP fragmentation while not needed/wanted DS www.veilingzaalmelase.be

we'll eventually run out of payload space, or worse, go negative. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Possibly-incorrect NSEC responses from many RSOs

On Tue, Mar 02, 2021 at 08:34:21PM -0500, Viktor Dukhovni wrote: > On Wed, Mar 03, 2021 at 12:40:55AM +0000, Paul Vixie wrote: > > I think you had me right the first time. I'm imagining a world with > > dnssec aware apps and stubs (and therefore, DANE validators in TLS > >

Re: [dns-operations] [Ext] Possibly-incorrect NSEC responses from many RSOs

On Tue, Mar 02, 2021 at 09:44:16PM -0200, Viktor Dukhovni wrote: > > > On Mar 2, 2021, at 9:31 PM, Paul Vixie wrote: > > ... > > I don't quite understand how "giving up" or not "giving up" on "dnssec-aware" > apps fits into the picture.

Re: [dns-operations] [Ext] Possibly-incorrect NSEC responses from many RSOs

ld already containing wildcards and synthesis. it's all garbage, mostly useless, and differentiating between one kind of garbage and another is a fool's errand. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Ext] Possibly-incorrect NSEC responses from many RSOs

sec-aware apps, or on validating stubs. there was discussion of making the dnssec types meta-only (authority or additional) back in the day. that road was deliberately unchosen. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 DNSSEC Validation?

loss of incoming traffic and a lot of complaints from one's own users. we won't be solving this with a cron job. NTA adds deliberate assymetry between the costs of doing DNSSEC signing wrong and the costs of coping with that. > -- > Mark Andrews -- Paul Vixie _

Re: [dns-operations] Quad9 DNSSEC Validation?

dly, i doubt that any large-scale RDNS operator would tolerate the resulting NOC or call center complaint volume while the invisible hand did its work. NTA won't be _the_ thing that killed DNSSEC, but it's in the top five. -- Paul Vixie ___ dns-operations

Re: [dns-operations] Quad9 DNSSEC Validation?

r .mil and .gov domains due > mostly in part for poor key rollover management practives/monitoring. so, this is a game of "chicken" where the wrong people keep flinching. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dn

Re: [dns-operations] Quad9 DNSSEC Validation?

enting, and the cost of breaking it should be extreme. also, negative trust anchors aren't part of the global MIB, and lead to different behaviour for different users. please consider offering to present your DNSSEC policies and experiences at an upcoming DNS-OARC meeting. fur may fly, but, usefu

Re: [dns-operations] anybody awake over at comcast.net?

any validity period. going into SERVFAIL like this is an operational risk i shouldn't take. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] anybody awake over at comcast.net?

my IPv6 PTRs are failing, and like last time, it's a signature expiration upstream of my zone: > 5.0.1.0.0.2.ip6.arpa to 9.5.5.0.1.0.0.2.ip6.arpa: No valid RRSIGs made by a > key corresponding to a DS RR were found covering the DNSKEY RRset, resulting > in no secure entry point (SEP) into the

Re: [dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)

the agreed wisdom of our era so that it can be easily and persistently found both in this and future eras? (same for the empty salt thread, and likely many others past and future.) -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oa

Re: [dns-operations] Signing on the fly and UltraDNS

within the last seven (7) days online here: http://family.redbarn.org/~vixie/house.gov.txt i did not deduplicate, because the tick rate of the SOA serial is interesting. (moral of story: zone transfer is not the risk surface anybody thought it was.) -- Paul Vixie

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

ion, but it's going to be rare. (i looked today at the bind9 configuration guide and it says that rfc2308-type1 is not implemented yet. it's been 20 years, so this situation may be permanent. i'd like it to get implemented, and i would turn it on here.) -- Paul Vixie __

Re: [dns-operations] which breakage is this? FreeBSD.org / systemd-resolved

esolved. i want my operating system to not offer me services i don't explicitly ask for. -- Paul Vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [EXTERNAL] Re: is anybody awake at 5.0.1.0.0.2.ip6.arpa? (comcast and/or arin)

On Tuesday, October 6, 2020 6:32:20 AM PDT Feldman, Mark wrote: > We are awake now. With some coffee and some consultation with our vendor, > we have corrected the signing issue on 9.5.5.0.1.0.0.2.ip6.arpa. Now to > make sure this doesn't happen again... ty, ty, ty. -- Vixie @FSI

Re: [dns-operations] is anybody awake at 5.0.1.0.0.2.ip6.arpa? (comcast and/or arin)

On Monday, October 5, 2020 8:24:09 PM PDT Robert Edmonds wrote: > Paul Vixie wrote: > > ssh gets hinky when i connect from a server whose PTR is "servfail" > > (dnssec > > "bogus") > > Unless you're using host-based authenticatio

Re: [dns-operations] is anybody awake at 5.0.1.0.0.2.ip6.arpa? (comcast and/or arin)

On Monday, October 5, 2020 8:18:54 PM PDT Mark Andrews wrote: > Why are you complaining to ARIN (5.0.1.0.0.2.ip6.arpa) when this is > Comcast's (9.5.5.0.1.0.0.2.ip6.arpa) fault? > > ... > > Now ARIN should be badgering Comcast to fix this as they should be checking > that the delegation is

[dns-operations] is anybody awake at 5.0.1.0.0.2.ip6.arpa? (comcast and/or arin)

ssh gets hinky when i connect from a server whose PTR is "servfail" (dnssec "bogus") * 5.0.1.0.0.2.ip6.arpa to 9.5.5.0.1.0.0.2.ip6.arpa: No valid RRSIGs made by a key corresponding to a DS RR were found covering the DNSKEY RRset, resulting in no secure entry point (SEP) into the

Re: [dns-operations] [Ext] DNS Flag Day 2020 will become effective on 2020-10-01

Mark Andrews wrote on 2020-09-16 15:20: ... O(10^6) But DNS traffic doesn’t need those sized packets even for zone transfers. i feel the same. but i felt that way about 64K and 640K RAM, and was wildly wrong. in practical terms i think the old 4K EDNS bufsize default will likely remain

Re: [dns-operations] [Ext] DNS Flag Day 2020 will become effective on 2020-10-01

ope, yet undashed. i would like to saturate a modern LAN and future WAN with O(10^7) physical-layer packets, which will mean that those packets will have to be up to O(10^6) octets in size. this can't happen under the tyranny of 1500, nor of 1280 or 1232. -- Paul Vixie

Re: [dns-operations] systemd resolved ignores specified root

when leo bicknell asked why we were keeping 10-year-old bug reports in our RT instance and nobody knew, so he deleted everything older than last january 1. we never noticed. open source is very powerful, but when it's not right, there's usually zero recourse. -- Paul Vixie ___

Re: [dns-operations] systemd resolved ignores specified root

t for the OS library (or for the apps, since apps are now doing their own DNS independent of the OS's settings). the best single thing we could all do for dns goodness is to get systemd to adopt the getdnsapi library, which is license-compatible. raise your voice _ther

Re: [dns-operations] DNS Flag Day 2020 will become effective on 2020-10-01

Ondřej Surý wrote on 2020-09-10 21:25: Paul, do you actually believe that shouting the same thing over and over will achieve anything? no, of course not. We’ve heard you before, we’ve listened to you, we’ve considered your arguments, and you haven’t convinced us and there’s a consensus

Re: [dns-operations] DNS Flag Day 2020 will become effective on 2020-10-01

Petr Špaček wrote on 2020-09-08 03:04: Dear DNS people. We are happy to announce next step for DNS Flag Day 2020. Latest measurements indicate that practical breakage caused by the proposed change is tiny [1]. In other words we can conclude that the Internet is ready for the change. from

[dns-operations] random numbers

> this number is random, unjustified, and should not be used. re: https://dnsflagday.net/2020/ -- Sent from Postbox

Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request

ing seperate > sockets for servers that don???t support DNS COOKIES. > +1. DNS COOKIE was a brilliant bit of work. but you should mention the RFC# and perhaps say which well known DNS implementations support it, to be more convincing to people who are not m

Re: [dns-operations] Nameserver responses from different IP than destination of request

Viktor Dukhovni wrote on 2020-08-28 18:46: On Fri, Aug 28, 2020 at 06:24:40PM -0400, Puneet Sood via dns-operations wrote: We (Google Public DNS) have noticed some instances of nameserver responses for a query coming from a different IP. Our initial plan was to consider these responses

Re: [dns-operations] FlagDay 2020 UDP Size

On Tuesday, 4 August 2020 21:50:22 UTC Paul Wouters wrote: > On Tue, 4 Aug 2020, Viktor Dukhovni wrote: > > ... > > It's almoast as if 1) we shouldn't hardcode any of this and 2) > definately not switch behaviour on some arbitrary "flag day". that's a fairly good interpretation of

Re: [dns-operations] FlagDay 2020 UDP Size

On Monday, 3 August 2020 19:41:11 UTC jack tavares wrote: > ... > > I have gone through the archives, is there consensus on this at this time? > For both the date of Flag Day (Which appears to be 1st October 2020, > pending confirmation from google) > and for the suggested default? i expect this

Re: [dns-operations] FlagDay 2020 UDP Size

On Monday, 3 August 2020 17:20:30 UTC jack tavares wrote: > I am asking for a clarification on the recommended default settings for > Resolvers etc. > > I understand that the default setting should be 1232. that's been proposed, and contested. > > But what is not clearly laid out, in my

Re: [dns-operations] Wormable RCE in MS Windows DNS Server CVE-2020-1350

On Thursday, 23 July 2020 01:21:04 UTC Brian Somers wrote: > ... > > So, a resolver that drops or decompresses compressed SIG RRs should > protect windows, assuming windows doesn’t just go ahead and ask the > authority directly. > > ... > > In short, resolvers should disallow compressed RRSIG

Re: [dns-operations] NS Piloting Secure DNS for Defense Contractors

On Monday, 22 June 2020 06:52:42 UTC Anne-Marie Eklund-Löwinder wrote: > No, but here's another article on the topic. Seems to be securing by rolling > out a new DNS resolver service, with a plan to eventually provide it > governmentwide. >

Re: [dns-operations] RFC 6975 (was: Re: Algorithm 5 and 7 trends (please move to 8 or 13))

On Tuesday, 9 June 2020 05:16:25 UTC Brian Somers wrote: > ... 1200IN A 208.65.116.3 > > I’m now looking at re-implementing the code we had in place for EDNS > probing prior to flag day 2019: > - FORMERR/SERVFAIL/NOTIMP - try without any EDNS codes > - No response - try with

Re: [dns-operations] EDNS client-subnet best practice?

On Wednesday, 3 June 2020 12:44:53 UTC Chris Adams wrote: > What is considered current best practice for recursive servers on > enabling EDNS client-subnet? most full resolvers leave it completely off. sometimes because the full resolver shares topology with its stub resolvers, and ECS would be

Re: [dns-operations] For darpa.mil, EDNS buffer == 1232 is *too small*. :-(

they will have to be troubled. perhaps we can notify them first. that config is not sustainable. ⁣Get BlueMail for Android ​ On 30 Apr 2020, 23:38, at 23:38, Viktor Dukhovni wrote: >On Sun, Apr 19, 2020 at 12:39:24AM -0400, Viktor Dukhovni wrote: > >> The DANE survey unbound resolver is

Re: [dns-operations] Pointer to discussion of name compression trade-offs?

On Thursday, 30 April 2020 07:17:48 UTC Viktor Dukhovni wrote: > I recall seeing a discussion (perhaps a few years back) of balancing > CPU-cost vs. space gained in DNS name compression. Where IIRC it > was suggested that most of the gain may come from only storing and > checking the offsets of

Re: [dns-operations] For darpa.mil, EDNS buffer == 1232 is *too small*. :-(

On Tuesday, 21 April 2020 06:20:04 UTC Petr Špaček wrote: > On 20. 04. 20 22:22, Viktor Dukhovni wrote: > > On Mon, Apr 20, 2020 at 12:52:49PM -0700, Brian Somers wrote: > >> ... > >> At Cisco we allow up to 1410 bytes upstream and drop fragments. We > >> prefer IPv6 addresses when talking to

Re: [dns-operations] Cloudflare Rose and Rick in .com authoritative Nameserver

On Monday, 20 April 2020 12:51:15 UTC Vladimír Čunát wrote: > ... > > As noted, these records are not required but are in bailiwick of .com, > so it's reasonable to trust their value and speed up resolution that > way. I believe there's nothing CloudFlare-specific in there. (For > example, Knot

Re: [dns-operations] At least 3 CloudFlare DNS-hosted domains with oddball TLSA lookup ServFail

On Sunday, 19 April 2020 16:49:36 UTC Viktor Dukhovni wrote: > ... > > > Could this work if the authoriative server returned an RRSIG signature > > of an empty TLSA RRset? > > An interesting hypothetical, my take is "no", that's what NSEC is for. > > signed_data = RRSIG_RDATA | RR(1) |

[dns-operations] fragmentation avoidance

On Friday, 17 April 2020 22:48:08 UTC Mark Andrews wrote: > ... > > Or we could adopt the well known TSIG approach and defeat > fragmentation attacks that way. This works for both IPv4 and IPv6. fragmentation's harms extend well beyond dns integrity vulnerabilities. i should not have proposed

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

On Friday, 17 April 2020 19:48:48 UTC Olafur Gudmundsson wrote: > > On Jan 22, 2020, at 11:16 PM, Paul Vixie wrote: > > > > ... > > > > historians please note: we should have put the DS RRset at $child._dnssec. > > $parent, so that there was no exceptio

Re: [dns-operations] NXDOMAIN vs NOERROR/no answers for non-existant records

On Thursday, 9 April 2020 23:56:04 UTC Alexander Dupuy wrote: > Paul Vixie wrote: > > i hope CF will differentiate NODATA from NXDOMAIN in their signed DNSSEC > > responses, because the difference is absolutely vital to anyone who uses > > DNS analytics as a defense v

Re: [dns-operations] NXDOMAIN vs NOERROR/no answers for non-existant records

On Monday, 6 April 2020 16:19:44 UTC Dave Lawrence wrote: > Matthew Richardson writes: > > However, is this going to cause any practical problems? > > Even outside DNSSEC, where it absolutely would be a problem, there are > some context for specialty applications where the difference between >

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

On Saturday, 4 April 2020 22:55:55 UTC Viktor Dukhovni wrote: > On Sat, Apr 04, 2020 at 09:56:06PM +0000, Paul Vixie wrote: > > ... > > I'm therefore sympathetic to Google's parent-centric approach (one > source of truth), without denying the desirability of letting the child

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

On Saturday, 4 April 2020 20:21:01 UTC Doug Barton wrote: > Sorry, wasn't clear. I was making a general statement when I said that > the child should be able to determine its own fate, not responding > specifically to something you said. ty. on that narrow topic, i will separately disagree. a

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

On Saturday, 4 April 2020 17:45:49 UTC Doug Barton wrote: > On 4/3/20 9:28 PM, Paul Vixie wrote: > > the economy requires faster, easier takedown of domains. when a delegation > > is revoked due to bad behaviour by a registrant, it has to die > > _everywhere_ almost immediat

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

On Saturday, 4 April 2020 06:59:30 UTC Ralf Weber wrote: > ... > > I actually agree with you that most domains are bad and especially that > most > new domains are bad. But from my experience takedown on authorities > takes so > long (weeks and months) that the additional NS TTL doesn’t really >

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

On Friday, 3 April 2020 17:20:10 UTC Shumon Huque wrote: > On Fri, Apr 3, 2020 at 11:59 AM Ralf Weber wrote: > > Well it was you think and others (including me) disagree for valid > > reasons. > > There is absolutely no reason to issue queries for some validation, when > > you already got good

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Friday, 3 April 2020 11:13:17 UTC Steven Miller wrote: > Essentially, yes. Some increase in capacity on your side plus RRL will > certainly keep you safer, but it's no guarantee. > > ... i saw the question differently: > On 4/3/2020 5:03 AM, Tessa Plum wrote: > > So no way to stop reflector

Re: [dns-operations] solutions for DDoS mitigation of DNS

ystems; only two are currently supported by that tool. (more would be welcome, it's apache 2.0 licensed!) > Paul Vixie wrote: > > $ dnsdbq -r '\*.berkeley.edu/ns' -A 2020-01-01 -j | jq .rrname | uniq -- Paul ___ dns-operations mailing list

Re: [dns-operations] solutions for DDoS mitigation of DNS

On Friday, 3 April 2020 01:18:46 UTC Tessa Plum wrote: > ... > > Not only for those private domain names, but zone data also includes the > administrative structure of corp/group. nothing in the dns is private. if you don't want something viewed, cataloged, indexed, searched, and used, then do

Re: [dns-operations] Cloudflare considered harmful?

On Thursday, 2 April 2020 23:59:30 UTC Mark Andrews wrote: > ... > > This means there is no push back on operators doing the wrong thing with > those servers. BIND has refused to load zones with CNAME and other data > for the last 20+ years so, yes, it can be done. It just requires DNS >

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

On Thursday, 2 April 2020 21:06:26 UTC Brian Somers wrote: > FWIW, OpenDNS/Umbrella/Cisco will use the glue to look things > up and won’t explicitly ask the authority for its own NS record. > > However, if we’re asked for an NS record by a client, we’ll lookup > & return the authoritative answer

Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode

On Thursday, 2 April 2020 20:12:50 UTC Puneet Sood via dns-operations wrote: > ,,, > > Google Public DNS is “parent-centric”—meaning that it only uses the > name servers that are returned in the referral responses from the > parent zone name servers, and does not make NS queries to this child >

  1   2   3   4   >