Re: [dns-operations] Non resolving i.zdnscloud.com/j.zdnscloud.com
Raymond Dijkxhoorn via dns-operations writes: > i.zdnscloud.com/j.zdnscloud.com dont have A/ records. But are listed > inside a whole set of TLD's. No A records, but do have records: $ dig +short j.zdnscloud.com 2401:8d00:2::1 $ dig +short i.zdnscloud.com 2401:8d00:1::1 jaap ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
Puneet Sood via dns-operations writes: > While the affected operators are spread around the world, the similarity of > the bad response across operators appears to suggest the DNS software may > be from the same or closely related source. These servers do not respond to > a version.bind query. > > Have you seen similar bad responses? Do you have an idea of the provenance > of this software? Fingerprinting with fpdns gives: fpdns e.ns.email.sonyentertainmentnetwork.com fingerprint (e.ns.email.sonyentertainmentnetwork.com, 207.251.96.133): DJ Bernstein TinyDNS 1.05 [Old Rules] jaap ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Fwd: .club TLD appears to be completely down]
Peter van Dijk writes: > Forwarded Message > From: Peter van Dijk > To: ultrasupp...@neustar.biz > Subject: .club TLD appears to be completely down > Date: Thu, 07 Oct 2021 12:34:48 +0200 > > Hello, > > Quick email, please see > https://dnsviz.net/d/powerdns.club/YV7Mpg/dnssec/ > > All of the name servers for .club return SERVFAIL for any query I can > think of in the .club zone, except for nic.club, which I bet is a > separate zone. > The .hsbc zone has a similar problem. jaap ___ 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)
Andrew Sullivan writes: About this part: > <...> > raise problems for them due to zone walking[1], and so something else > had to be created. The zone-walking-resistant NSEC3 was an > opportunity to reintroduce opt-out, > > Maybe some others have a different memory of this, though? > > [1] As I heard it told, even the lawyers agreed it was stupid, but it > was the consequence of some detail of the law. This hearsay is not > admissible in any proceeding, I'm sure. I do remember there was some discussion in Europe. At SIDN we (Where I was at that time) commissioned some academic research (Tilburg University I think) to see whether NSEC was interfering with privacy concerns (including European regulations). The conclusion was it didn't and got ignored. So NSEC3 developing of NSEC3 started, The opt-out thing got sneaked in and yes, the big zone problem was the motive for that. jaap ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Monitoring for impending expiration of domains?
Patrik Fältström via dns-operations writes: > On 13 Dec 2020, at 5:26, Viktor Dukhovni wrote: > > > So my question to the list is, what can or should be done to help domain > owners avoid a similar fate? > > As it is today: You use a registrar that ensure your domain name never > expires. If you have a good registrar, you simply buy that as a service, > and you are fine. > > People that "just get a registrar" from the shelf, believe all are equal, > and get the one that is the cheapest, they end up having problems like > these. > > This is *exactly* one thing that differs between the services registrars > give to their customers. Note that, as far as I know, NL registry uses a "sunscribtion" model so domains never "just" expired. So Voktor probably saw some outage of netfilter.nl (it is up now). jaap ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] .ag outage
> That is fine if you do not want DNSSEC. > > > Do you also see problems with .ag? > Yesterday morning I noticed it was bogus but that is fixed by now. jaap ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] .ss (South Sudan) zone apex DNSKEY RRSIG expired (2020-02-07)
Viktor Dukhovni writes: > The zone apex DNSKEY RRSIG for .SS (South Sudan) expired on 2020-02-07: Yeah, I've mailed laste week the people list in the IANA whois database, but up to now, no reaction. jaap ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Something happening in the root?
Florian Weimer writes: > > There was a problem with some Cloudflare operated instances > > Does this mean we have 13th root server operator? No. jaap ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Root-servers returning TC=1 after 5 NXDOMAINS
H?kan Lindqvist writes: Emil Natan shlyoko@... writes: If this is an issue with the F-root only it would be easier to use hints file with the F excluded instead of managing local root zone and keeping it up to date. But just changing the hints wouldn't actually do anything, right? Right! The hints file (or build-in hint information) is only used when the resolver starts up. If one of the servers binted to answers, the information from that server is used and the info from the hints is/should be thrown away since it is just a hint. jaap ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] Zone with expired signatures?
Matthew Pounsett writes: I could have sworn that I remembered someone setting up zones with both expired and valid signatures so that people could test against them. But I cannot find any references. I can set that up myself of course, but I don't want to spend the effort if someone else has already invented that particular wheel. Theres one in the test.dnssec-tools.org zone[1], and another at SIDN[2]. I seem to recall one at NLnet Labs, but cant find any reference to it currently. It moved to SIDN and got revamped as [2] jaap [1] https://www.dnssec-tools.org/testzone/ [2] https://workbench.sidnlabs.nl/bad-dnssec.html ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] BAD (HORIZONTAL) REFERRAL in one nameserver of mm ?
Stephane Bortzmeyer writes: On Wed, Jul 30, 2014 at 09:10:12AM +0200, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 28 lines which said: I often see these problems with deep TLD (those with registration in a SLD). TLD managers ask for a secondary hosting and wrongly assume that it will work for all the zones underneath. And the email address in the SOA of net.mm is broken (no MX, A or ) so there is little hope of seeing this problem fixed. Try whois, jaap % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object domain: MM organisation: Ministry of Communications, Posts Telegraphs address: Office Building No. 2 address: Nay Pyi Taw 150111 address: Myanmar contact: administrative name: U Zaw Min Oo organisation: Ministry of Communications, Posts Telegraphs address: Office Building No. 2 address: Nay Pyi Taw 150111 address: Myanmar phone:+95 67 420351 fax-no: +95 67 420349 e-mail: zawminoo@mptmail.net.mm contact: technical name: Daw Khin Swe Htay organisation: Ministry of Communications, Posts Telegraphs address: Overseas Communications Building, address: Myanma Posts and Telecommunications, address: Kabaraye Pagoda Road, Mayangone Township address: Yangon 11061 address: Myanmar phone:+95 1 652372 fax-no: +95 1 662405 e-mail: ksh...@mpt.net.mm nserver: MM.CCTLD.AUTHDNS.RIPE.NET 193.0.9.96 2001:67c:e0:0:0:0:0:96 nserver: NS0.NIC.NET.MM 203.81.64.20 nserver: NS1.NIC.NET.MM 203.81.81.85 nserver: NS2.NIC.NET.MM 203.81.92.10 ds-rdata: 14581 8 1 8B0ED592A997E801DAFADA2CD4CC31999BDA8782 status: ACTIVE remarks: Registration information: http://www.nic.mm/ created: 1997-02-04 changed: 2011-11-29 source: IANA ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] PCAP based detector of malicious DNS traffic
On Fri, Jun 27, 2014 at 10:40:13AM +0200, sth...@nethelp.no wrote: The output of the tool is, like Nick's work, a list of domain names and additionally the set of IP addresses sending traffic to those domains. Is dnsscope available for other OSes, e.g. FreeBSD? Yes, you can compile it from our tarballs, the latest of which contains the --servfail-tree work can be found on: https://autotest.powerdns.com/job/auth-git/lastSuccessfulBuild/artifact/ We don't have FreeBSD binaries because we tend to see little demand for them, sorry. This might be a chicken/egg problem. If people want, I'm happy to create a FreeBSD port/Package when I have some time to life. jaap ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] about the underline in hostname
On 29 May 2014, at 18:56, wbr...@e1b.org wrote: Out of curiosity, where did the prohibition of underscores in host names come from. I'm sure there's a historical reason for it, but I've never heard it. Or is it really as simple as RFC 952 only listed thirty seven characters It might be un urban legend, but I once was told that since EBCDIC had two different encodings for the underscore, the use was discouraged for interchange of things that where supposed to be unique. (As example was mentioned that therefore uuencode is not using it). jaap ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] ALERT: .QA CCTLD in wrong hands currently
The TLD appears to be fine (that is, it hasn't been redelegated). Looks = like the registry might be having issues however -- the domain = referenced on the IANA page for registration information (domains.qa) = does not resolve (NXDOMAIN). But it does by number: http://184.106.140.247/en jaap ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] Should medium-sized companies run their own recursive resolver?
A fictitious 100-person company has an IT staff of 2 who have average IT talents. They run some local servers, and they have adequate connectivity for the company's offices through an average large ISP. Should that company run its own recursive resolver for its employees, or should it continue to rely on its ISP? To who do you ask this questions? From who do you expect an answer? jaap ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] Who is xn--j1amh.? Well, the general problem...
Hi Ed, $ whois -h whois.iana.org XN--J1AMH. % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object domain: =D1=83=D0=BA=D1=80 domain-ace: XN--J1AMH status: ACTIVE created: 2011-03-01 source: IANA Yes, this is pretty odd. Why would it give less info then with $ whois -h whois.iana.org nl I assume IANA could give some answer. BTW, it is an IDN for the Ukraine. Hoovering over the items on https://www.iana.org/domains/root/db shows you the encoding. What always cracks me up on this page is that all IDNs are sorted under the X (because of XNN- I assume). jaap ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] Who is xn--j1amh.? Well, the general problem...
On 20 Mar 2013, at 13:35, Jaap Akkerhuis j...@nlnetlabs.nl wrote: Whatalways cracks me up on this page is that all IDNs are sorted under the X (because of XNN- I assume). Does a sensible sorting order for characters from different character sets even exist? I think, but am not sure that Unicode has some information about desired collation order. The only one I can think of is by strict code point value, but then that would produce incorrect results for those languages whose own code points aren't in lexical order. That will at least be some order. Now it appears semi random under X since it depends on encoding. But this all for the iana webmaster to look at. What I find really odd is that port 43 gives less information when asked with an IDN label. jaap ___ dns-operations mailing list dns-operations@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
Re: [dns-operations] Who is xn--j1amh.? Well, the general problem...
Joe, To close the loop on this: Thanks for this info, jaap ___ dns-operations mailing list dns-operations@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
