Re: [dns-operations] DNSbomb attack
It appears that Ond� ej Surý said: >I don’t know why are you trying to create rift where there’s really none. I suspect that I am not the only person who is getting a wee bit tired of papers that say OMG MOST AWFUL DNS FLAW EVER! INTERNET WILL COLLAPSE! MUST CHANGE ALL RFCS! and the authors send out press releases, when in fact it should say "here's a DNS attack that was described a decade ago but isn't yet patched everywhere" or at most "here's yet another amplification attack you should defend against." I realize it can be a challenge to get conference papers accepted but that's not our problem. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Offline DNSSEC Validation
According to Rithvik Vibhu : >Does anyone know of an existing library that only does DNSSEC validation >without resolution? Preferably in go, but any other language will do at >least as reference. The dnspython library has a validation routine that takes an rrset, a signature, and a set of dnskeys and tells you whether the signature is good. If you want to follow the DS chain you'll have to do that yourself but having just written a stunt DNSSEC signing server, I can say that the code to do the chaining would not be hard. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Mysteries of DNSSEC
I have a stunt DNS server at contacts.abuse.net that synthesizes answers from a database so if you look up, say, example.com.contacts.abuse.net it'll give you the contact addresses in TXT records, the number of contacts in an A record, and some hints about where the answer came from in HINFO. While I should have been doing something else, I rewrote it and added DNSSEC support with white lies, which turned out to be easier than I expected once I figured out that nearly all the pieces are already in the dnspython and cryptography libraries. The first surprise I found is that once I turned it on, nearly every query, like 99%, asks for DNSSEC. Is this typical or do I have an odd set of clients? Another surprise is that I'm getting a lot of repeated DNSKEY queries even though the TTL is an hour. One repeat customer is Cloudflare, another is pfsense22.plan-gis.net, at some random company in Germany. My theories are A) a bunch of different caches behind a load balancer, B) a too small cache, C) buggy software. R's, John DNSKEY queries from one of Cloudflare's caches 2024-03-30 03:51:32.279107500 172.71.249.53:47231 * . DNSKEY 2024-03-30 03:57:01.371563500 172.71.249.53:44153 * . DNSKEY 2024-03-30 04:02:08.573508500 172.71.249.53:29535 * . DNSKEY 2024-03-30 04:07:16.672879500 172.71.249.53:14468 * . DNSKEY 2024-03-30 04:12:36.354050500 172.71.249.53:59151 * . DNSKEY 2024-03-30 04:17:40.039189500 172.71.249.53:35542 * . DNSKEY 2024-03-30 04:22:43.444358500 172.71.249.53:38801 * . DNSKEY 2024-03-30 04:28:01.418130500 172.71.249.53:36646 * . DNSKEY 2024-03-30 04:33:17.209824500 172.71.249.53:64486 * . DNSKEY 2024-03-30 04:38:49.759567500 172.71.249.53:13480 * . DNSKEY 2024-03-30 04:44:23.887169500 172.71.249.53:25231 * . DNSKEY 2024-03-30 04:49:30.949830500 172.71.249.53:46320 * . DNSKEY 2024-03-30 04:54:49.464021500 172.71.249.53:12684 * . DNSKEY 2024-03-30 05:00:00.759583500 172.71.249.53:47563 * . DNSKEY 2024-03-30 05:05:40.391819500 172.71.249.53:25912 * . DNSKEY 2024-03-30 05:11:04.576372500 172.71.249.53:48818 * . DNSKEY 2024-03-30 05:16:33.577948500 172.71.249.53:16534 * . DNSKEY 2024-03-30 05:21:54.154829500 172.71.249.53:26989 * . DNSKEY 2024-03-30 05:27:37.780330500 172.71.249.53:23883 * . DNSKEY 2024-03-30 05:33:41.024080500 172.71.249.53:17390 * . DNSKEY 2024-03-30 05:38:33.265995500 172.71.249.53:14358 * . DNSKEY 2024-03-30 05:44:09.675873500 172.71.249.53:14478 * . DNSKEY 2024-03-30 05:50:53.181974500 172.71.249.53:54451 * . DNSKEY 2024-03-30 05:55:09.976686500 172.71.249.53:30454 * . DNSKEY 2024-03-30 06:01:47.898687500 172.71.249.53:21261 * . DNSKEY 2024-03-30 06:06:21.924791500 172.71.249.53:34047 * . DNSKEY 2024-03-30 06:11:40.462522500 172.71.249.53:50080 * . DNSKEY 2024-03-30 06:16:46.781015500 172.71.249.53:61581 * . DNSKEY 2024-03-30 06:22:00.428444500 172.71.249.53:15125 * . DNSKEY 2024-03-30 06:27:00.835822500 172.71.249.53:54978 * . DNSKEY 2024-03-30 06:27:01.098742500 172.71.249.53:56790 * . DNSKEY 2024-03-30 06:32:00.035213500 172.71.249.53:27084 * . DNSKEY 2024-03-30 06:32:13.322007500 172.71.249.53:52489 * . DNSKEY 2024-03-30 06:37:23.630744500 172.71.249.53:63976 * . DNSKEY 2024-03-30 06:42:44.669171500 172.71.249.53:31074 * . DNSKEY 2024-03-30 06:48:03.511289500 172.71.249.53:11628 * . DNSKEY 2024-03-30 06:51:45.442612500 172.71.249.53:30454 * . DNSKEY 2024-03-30 06:54:14.358491500 172.71.249.53:63947 * . DNSKEY 2024-03-30 07:00:11.989979500 172.71.249.53:57044 * . DNSKEY 2024-03-30 07:05:56.483600500 172.71.249.53:59681 * . DNSKEY 2024-03-30 07:11:09.013634500 172.71.249.53:29908 * . DNSKEY 2024-03-30 07:11:09.023567500 172.71.249.53:29908 * . DNSKEY 2024-03-30 07:11:44.874678500 172.71.249.53:30844 * . DNSKEY 2024-03-30 07:16:45.461879500 172.71.249.53:26215 * . DNSKEY 2024-03-30 07:21:17.748638500 172.71.249.53:12148 * . DNSKEY 2024-03-30 07:26:26.489270500 172.71.249.53:41121 * . DNSKEY 2024-03-30 07:32:03.916246500 172.71.249.53:64004 * . DNSKEY 2024-03-30 07:32:04.423734500 172.71.249.53:64004 * . DNSKEY 2024-03-30 07:37:53.514963500 172.71.249.53:43346 * . DNSKEY 2024-03-30 07:44:26.978067500 172.71.249.53:16080 * . DNSKEY 2024-03-30 07:49:28.613381500 172.71.249.53:14171 * . DNSKEY 2024-03-30 07:54:46.232407500 172.71.249.53:63113 * . DNSKEY 2024-03-30 07:59:47.147716500 172.71.249.53:46385 * . DNSKEY 2024-03-30 08:04:55.144469500 172.71.249.53:62343 * . DNSKEY 2024-03-30 08:04:55.432569500 172.71.249.53:56633 * . DNSKEY 2024-03-30 08:09:58.732604500 172.71.249.53:39301 * . DNSKEY 2024-03-30 08:15:12.419048500 172.71.249.53:34974 * . DNSKEY 2024-03-30 08:15:12.425827500 172.71.249.53:34974 * . DNSKEY 2024-03-30 08:20:34.437094500 172.71.249.53:17787 * . DNSKEY 2024-03-30 08:25:58.861623500 172.71.249.53:60182 * . DNSKEY 2024-03-30 08:34:16.994333500 172.71.249.53:57296 * . DNSKEY 2024-03-30 08:40:33.705198500 172.71.249.53:24237 * . DNSKEY 2024-03-30 08:45:38.72500 172.71.249.53:18878 * . DNSKEY 2024-03-30 08:50:59.330848500 172.71.249.53:52902 * . DNSKEY 2024-03-30
Re: [dns-operations] Evaluation of NSEC3-encloser attack
It appears that Jim Reid said: > > >> On 27 Mar 2024, at 19:37, Ondřej Surý wrote: >> >> Both salt and iterations have absolutely no value for NSEC3 security (see >> the RFC you just quoted), so just always use empty salt and zero iterations. >There’s no added value in fiddling with salt to fit into the SHA1 block. > >IMO, there’s no added value in using NSEC3. My understanding is that if you want to prevent zone enumeration you are better off with RFC 4470 white lies. You'd only need NSEC3 if your zone security is so critical that you need to do offline signing. But the overlap between the zones that are that critical and the ones that try to keep their contents secret (realizing that passive DNS makes the whole thing pretty silly) is vanishingly small. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS Operations
It appears that Lee said: >OK - that was bad phrasing on my part :( >How about the most popular DNS server software that end-users chose to >run at home? For the 0.01% of end users that manage their own networks, well, OK. On my home network I have an old mini ATX box running FreeBSD, on which I use unbound. It works great for me. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] most somethind DNS something, DNS Operations
It appears that David Conrad via dns-operations said: >ChatGPT is the weaponization of “I saw it on the Internet so it must be true." May we quote you on that? >> - which seems to be pi-hole > >I’d be very surprised if this were the case. I’d have thought the vast >majority of what end users would use (at least on the recursive >side) would be whatever their ISP was providing, which I strongly suspect is >not pi-hole. I'd also expect it's whatever they use in the cheap NAT routers that broadband providers hand out. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Upcoming Registry Service Provider Evaluation Program
It appears that Rubens Kuhl via dns-operations said: >> I did some of the technical evaluations in the previous round, and we >> saw that the vast majority of applications used about five back end >> providers. Prequalifying those providers would have made the whole >> process much faster. >https://ntldstats.com/backend >new gTLD Statistics by Backends >ntldstats.com > lists 37 back-ends for gTLDs. I don’t think there is a readily available list > for c Sure, but the top five handle about 90% of the new TLDs. I saved a lot of time by writing scripts that did string compares to see if the applicants had correctly copied and pasted the form responses from the large backends. But it would have made a lot more sense if I could have said that RSP is known to be OK so we can skip the parts they handle and only do the ones specific to each applicant. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Upcoming Registry Service Provider Evaluation Program
It appears that Rubens Kuhl via dns-operations said: >-=-=-=-=-=- >-=-=-=-=-=- >-=-=-=-=-=- > > >Gaurav, > >If an applicant so prefers it can have its own RSP evaluated at the same time >its application is evaluated, so it’s not restricted >to the list of pre-approved RSPs. I did some of the technical evaluations in the previous round, and we saw that the vast majority of applications used about five back end providers. Prequalifying those providers would have made the whole process much faster. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Cannot send mail to outlook.com due to olc.protection.outlook.com configuration issues
It appears that Craig Leres said: >I've had edns0 in resolv.conf for a really long time but even if I >comment that out I'm still unable to deliver mail. Also I get SERVFAIL >or a timeout if I lookup outlook-com.olc.protection.outlook.com. I run the FreeBSD package of unbound and it has no trouble even when I specifically set an edns0 option. What else might be odd about your setup? $ drill -b 2000 outlook-com.olc.protection.outlook.com. a ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 9650 ;; flags: qr rd ra ; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;; outlook-com.olc.protection.outlook.com. IN A ;; ANSWER SECTION: outlook-com.olc.protection.outlook.com. 300 IN A 52.101.8.37 outlook-com.olc.protection.outlook.com. 300 IN A 52.101.8.35 outlook-com.olc.protection.outlook.com. 300 IN A 52.101.68.4 outlook-com.olc.protection.outlook.com. 300 IN A 52.101.73.29 outlook-com.olc.protection.outlook.com. 300 IN A 52.101.11.6 outlook-com.olc.protection.outlook.com. 300 IN A 52.101.11.5 outlook-com.olc.protection.outlook.com. 300 IN A 52.101.68.37 ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: ;; Query time: 183 msec ;; EDNS: version 0; flags: ; udp: 1232 ;; SERVER: fde3:783e:127d:1::2 ;; WHEN: Fri Oct 6 21:35:19 2023 ;; MSG SIZE rcvd: 179 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS measurement traffic etiquette
It appears that Andreas Ott said: >What are my best options to find out who is behind all this traffic when it >comes from anonymous sources? A lot of botnet malware has prefetched DNS lookups for sending spam and the like that tend to be very stale. >For how long should I expect this query traffic to continue? Don't hold your breath. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] .in ccTLD 2-level public suffixes
It appears that Viktor Dukhovni said: >> > >> >ai.in am.in ca.in cn.in er.in io.in me.in pg.in tv.in uk.in us.in >Thanks, that confirms and details their availability as public suffixes. > >These suffixes were specifically provisioned (and are not themselves >delegated, they are included directly in the .in zone) by the .IN ccTLD, >and I am curious whether the intent was specifically to "mirror" >similarly named ccTLDs (and if so, why), or whether perhaps these >2-letter abbreviations have some other significance in India... I'm pretty sure they were opportunistic. They don't appear to match up with Indian states or anything else I can recognize. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] .in ccTLD 2-level public suffixes
It appears that Viktor Dukhovni said: >But also some that appear to just mirror other ccTLDs without an obvious >connection to a category of child domains (com, edu, gov, net, org, ...): > >ai.in am.in ca.in cn.in er.in io.in me.in pg.in tv.in uk.in us.in > >What are these for? I'm afraid these may create or add to user confusion. The registry web site says since 2005 they've been available for anyone to register anything. The 2LDs that limit who can register are ac.in res.in edu.in gov.in mil.in. https://registry.in/policies R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Browser Public suffixes list
It appears that Paul Hoffman said: >-=-=-=-=-=- >-=-=-=-=-=- > >On Aug 26, 2022, at 2:43 PM, Meir Kraushar via dns-operations > wrote: >> So bottom line, browser behavior is not based on DNS resolving, nor by any >> IANA list, but rather on the PSL. > >This is interesting info, thanks! The PSL is used by browsers for things like >preventing cross-site scripting, but should not be >relied on for "is it really a TLD". The browser makeers would disagree with you: https://publicsuffix.org/learn/ These are some of the uses of the list we know about. ,,, Firefox Restricting cookie setting Restricting the setting of the document.domain property Sorting in the download manager Sorting in the cookie manager Searching in history --> Domain highlighting in the URL bar Chromium/Google Chrome (pre-processing, DAFSA builder, parser) Restricting cookie setting --> Determining whether entered text is a search or a website URL Determining whether wildcard subdomains are allowed in Origin Trial tokens Internet Explorer Restricting cookie setting --> Domain highlighting in the URL bar --> Zone determination ActiveX opt-in list security restriction I'm not saying they're right, but it's been like this for a long time. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Opportunity to operate a non-gTLD non-ccTLD TLD
According to Paul Hoffman : >https://sam.gov/opp/93a697c39c3f44839a2000119c3e4956/view > >(tl;dr: US is soliciting bids for being the back-end for .gov) The incumbent is Verisign. Any reason to believe they are looking to replace them? Unlike .US, the .GOV TLD only has about 8000 names and the registrants don't pay, so it's unlikely to be worth bidding if you're not already doing government business. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] How should work name resolution on a modern system?
It appears that Viktor Dukhovni said: >Single label names passed to getaddrinfo(3) should not result in single >label "A" or "" DNS queries. If only. See RFC 7085. I've been doing regular surveys of RRs for single label names in the decade since we published that and things haven't changed much. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
It appears that Dave Lawrence via dns-operations said: >Ditto local roots. This feels like something Geoff Huston probably >has some kind of data about, but a cursory search didn't turn it up. >I personally run a local root on my home system, but how prevalent are >they? I believe they are very prevalent in large DNS caches, to the extent that it's unclear how well the queries reaching the public roots match what the world is really asking. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Input from dns-operations on NCAP proposal
It appears that Brian Dickson said: >"ndots" can generally be any number between 0 and X, for >implementation-specific X. Some implementations cap X at 15, some at 255, >there may be other implementations. Do we have any idea how many systems still use search lists? We've been saying bad things about them at least since .CS was added in 1991. >In such a configuration, if the host name "foo" matches the candidate TLD >"foo", and the latter is changed from NXDOMAIN ... It seems to me that the risk depends a lot more on what the name is rather than the particular DNS response. If it's OEMDMCEKCSN. I doubt anyone will notice, but if it's MAIL., watch out. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNS request for ./NS with two extra bytes at the end
It appears that Brown, William said: >-=-=-=-=-=- >It made sense 40 years ago when it was written. In today’s security >environment, it does not. It made sense and still makes sense when you know what Postel meant. Be liberal in what you accept when the specification is ambiguous, not accept any random garbage and try to guess what it means. R's, John >From: P Vixie >Sent: Thursday, May 26, 2022 11:23 AM >To: Stephane Bortzmeyer >Cc: dns-operations@lists.dns-oarc.net >Subject: Re: [dns-operations] DNS request for ./NS with two extra bytes at the >end > >The robustness principle is diametrically wrong. We must be ultra conservative >in what we accept, to put back pressure on >silly bugs before they can gain market share. >Confidentiality Notice: This electronic message and any attachments may >contain confidential or privileged information, and is >intended only for the individual or entity identified above as the addressee. >If you are not the addressee (or the employee or >agent responsible to deliver it to the addressee), or if this message has been >addressed to you in error, you are hereby >notified that you may not copy, forward, disclose or use any part of this >message or any attachments. Please notify the sender >immediately by return e-mail or telephone and delete this message from your >system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] CNAME at the apex breaks DNSSEC DS lookups from caches
It appears that Robert L Mathews said: >That's recent in client terms, though (and it doesn't look like >Microsoft Edge supports it yet, for example). It will take at least a >decade until people feel like they can rely on 99% of clients supporting it. >... >The ANAME draft would have offered an immediate alternative to any DNS >operator who wanted it, that worked 100% of the time, without needing >any client updates. ... I am intrigued at the idea that browsers take a decade to update while DNS servers update instantly. If that's what you want, it is not hard to fake an ANAME in DNS provisioning software. That's what I've been doing for a long time. My DNS servers just see the A and records that the provisioning stuff copies into the zone. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Trouble resolving .by TLD due to circular dependency?
It appears that Sascha E. Pollok via dns-operations said: >-=-=-=-=-=- > >Hello nice people, > >for a few days I have worked on an issue we see with our Bind resolvers of >different >versions regarding resolving addresses under .by. I assume it is not Bind's >fault at all >but the result of a circular dependency in .by after a change of the Auth NS >beginning of >January but let me explain what I see. ... You are correct, they have a NS dependency loop that will cause all sorts of problems. As you note the results can be very inconsistent depending on the TTL of the glue records and how different DNS software handles the expiring glue. >by. 130511 IN NS dns1.tld.becloudby.com. >becloudby.com. 172800 IN NS u1.hoster.by. >becloudby.com. 172800 IN NS u2.hoster.by. >Does this analysis seem correct and are there maybe any .BY ccTLD people on >this list to >take a look at this? I have worked on this together with Anand Buddhdev so I >want to thank >him for working with me. Always a pleasure. The solution, of course, is "don't do that." A simple fix would be to move the NS for becloudby.com to a name under .com. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] What is the reason of J-Root doesn't serve the arpa zone?
It appears that Stephane Bortzmeyer said: >On Mon, Dec 06, 2021 at 01:42:42AM +0900, > Yasuhiro Orange Morishita / 森下泰宏 wrote > a message of 89 lines which said: > >> And I heard from another person that J-Root holds the arpa zone, but >> not delegated. It is also interesting. > >Indeed. It is funny. It gets funnier: $ dig @j.root-servers.net soa arpa ; <<>> DiG 9.10.6 <<>> @j.root-servers.net soa arpa ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 436 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 12, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;arpa. IN SOA ;; ANSWER SECTION: arpa. 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2021120501 1800 900 604800 86400 ;; AUTHORITY SECTION: arpa. 518400 IN NS a.root-servers.net. arpa. 518400 IN NS b.root-servers.net. arpa. 518400 IN NS c.root-servers.net. arpa. 518400 IN NS d.root-servers.net. arpa. 518400 IN NS e.root-servers.net. arpa. 518400 IN NS f.root-servers.net. arpa. 518400 IN NS g.root-servers.net. arpa. 518400 IN NS h.root-servers.net. arpa. 518400 IN NS i.root-servers.net. arpa. 518400 IN NS k.root-servers.net. arpa. 518400 IN NS l.root-servers.net. arpa. 518400 IN NS m.root-servers.net. ;; Query time: 85 msec ;; SERVER: 2001:503:c27::2:30#53(2001:503:c27::2:30) ;; WHEN: Sun Dec 05 14:05:32 EST 2021 ;; MSG SIZE rcvd: 299 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] What is the reason of J-Root doesn't serve the arpa zone?
It appears that Paul Vixie via dns-operations said: >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 the language of RFC 2870. > >2870 was wrong in this respect, and should be revised to allow ARPA. Now that RFC 9120 is moving .arpa to a.ns.arpa. and so forth, it seems kind of late to do so. R's, John ___ 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?
According to A. Schulze : >Hello, > >we found the domain "xn--80atcidr8i.xn--p1ai." in one of our logs. > >the TLD "xn--p1ai." delegate "xn--80atcidr8i.xn--p1ai." to two working >nameservers. >But these nameserver choose to announce "ns1.example.com" and >"ns2.example.com" as authoritative. >These names are garbage. > >But most resolver do not fail to give an answer for "xn--80atcidr8i.xn--p1ai. >/A" >So I wonder, why do so many resolver [1] obviously do only follow a delegation >and ignore authoritative data? >Is it really some sort of "Hey, you asked for $domain/A, the setup is so >broken, but I tried really my best: here as an answer..." ? For better or worse, DNSSEC validates the data itself, not the path you took to get there. I have a local root which gets its info from some servers at ICANN, not any of the regular root servers, but since the DNSSEC signatures are OK, I don't care. Parent and child NS have been out of sync as long as there have been NS, and I have seen no pattern about which is more likely to be "correct". If the server has the data and the signatures are good, why do you care where it came from? And if it's not signed, the zone owner apparently doesn't care either. I realize that with DoH and DoT we are edging toward path validation, but I'd prefer to leave those worms in the can for the moment. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Support for ED25519/ED448 DS records by OpenSRS
In article you write: >-=-=-=-=-=- > >My OpenSRS reseller is unable to get them to support ED25519/ED448 DS >records in .AU (I have a response from the administrator of the domain >informing me that the registrar supports these algorithm types): > >> We're sorry but OpenSRS has stated that they cannot easily/quickly setup >> support for these algorithms and to submit requests via their public forum >> for support to be added. >> >> https://help.opensrs.com/hc/en-us/community/topics/200120733-Suggestions-Ideas Opensrs works entirely through resellers (including their captive reseller Hover) via an XML API. The API is klunky but it works, and it is nice that I can automatically add and update the DS records for all my Tucows domains without having to screw around with web forms. I would also like them to update the XML schema so it can accept algorithms 15 and 16 but before they do that, they'll have to figure out which registries support them, what error codes come back from registries that don't, and so forth. If we complain enough, perhaps they'll move it up in the backlist of changes. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article <20210106032410.ga6...@isc.org> you write: >I wonder aloud if dig's default behavior should be to try IDN and >silently fall back to conventional output formatting if it fails. >I imagine there are situations where you'd want the rules strictly >enforced, but I'm not sure if there was a good reason to do that by >default. Given that there is no reason to assume that any particular query or result in dig will be a hostname as opposed to a generic DNS name, that sounds right to me. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article you write: >dig by default is not built with IDN support. If you request IDN support at >build time >+[no]idnin and +[no]idnout are enabled which then expect valid IDN names on >the command >line for +idnin and in the output for +idnout. That can't be right. I can use dig for underscored names which aren't IDNs either and it doesn't complain. If it's validating IDNs it makes sense to complain about something like xn--1234 which has an IDN prefix but isn't an A-label. But a label that is just a hyphen isn't a hostname just like _foo isn't a hostname. Why does it complain about one but not the other? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article <20210105204121.c4d925829...@ary.qy> you write: >In article <853ece14-271f-4e93-9473-d1dbde836...@icann.org> you write: >>On Jan 5, 2021, at 11:20 AM, Dave Lawrence wrote: >>> >>> Paul Hoffman writes: I am using tools that expect host names instead of domain names (in this case, dig); >>> >>> I think I must be misunderstanding something, or at least haven't >>> imagined widely enough the possibilities of your meaning here. dig >>> has a particular expectation for hostnames either owning or in the >>> rdata of an NSEC record? That's surprising to me. Not inconceivable, >>> of course, but definitely surprising. >> >>I started this thread with: >> dig +dnssec +noidnout anynameyouwant.house.gov a >>Try that without the +noidnout option. > >With DiG 9.16.10 I get the same result either way. What do you get? Oh, OK, I tried a different name and got: dig: '-.house.gov.' is not a legal IDNA2008 name (string start/ends with forbidden hyphen), use +noidnout That's a dig bug. It's a perfectly valid DNS name albeit a fairly ugly one. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article <853ece14-271f-4e93-9473-d1dbde836...@icann.org> you write: >On Jan 5, 2021, at 11:20 AM, Dave Lawrence wrote: >> >> Paul Hoffman writes: >>> I am using tools that expect host names instead of domain names (in >>> this case, dig); >> >> I think I must be misunderstanding something, or at least haven't >> imagined widely enough the possibilities of your meaning here. dig >> has a particular expectation for hostnames either owning or in the >> rdata of an NSEC record? That's surprising to me. Not inconceivable, >> of course, but definitely surprising. > >I started this thread with: > dig +dnssec +noidnout anynameyouwant.house.gov a >Try that without the +noidnout option. With DiG 9.16.10 I get the same result either way. What do you get? R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Signing on the fly and UltraDNS
In article <701c6017-9eb5-4660-90a2-4ae0e7e93...@icann.org> you write: >That all seems correct. However, I brought the issue to this mailing list, >instead of to the UltraDNS folks, because I am using tools that expect host >names instead of domain names (in this case, dig); now I have to write shims >around them. Other signing-on-the-fly mechanisms might cause similar issues >for dig or other tools. But wouldn't that equally fail on a SRV record with a _tcp name or a DKIM key with _domainkey? If you're poking at the DNS I'd think you need to be prepared for anything the DNS can return. It is not clear to me that this stuff is there to prevent enumeration. The funky names allow zone updates without having to keep the zone in canonical order to regenerate the NSEC chain. ___ 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?
In article you write: >critical). I had the registrar's emails specifically filtered to an >important folder so I'd notice the pending expiration date. Then... >that registar sold all their DNS services to a different one. I lost >two domains because the new registar's mails ending up in a spam folder >before I noticed. Whoops. > >Mind you the fault was entirely mine. I dunno. It is pretty common for people to whitelist addresses that have sent mail before, so if they changed their address I'd expect a lot of it to go into spam folders. It doesn't sound like they sent you notices from the old address telling you that future mail would come from the new address. > But auto-renew is probably the only safe way, as mail fails... That's swell until the message asking for the card's new expiration date falls into the spam folder, too. There is a great deal of responsiblity go go around here, particularly when something slightly out of the ordinary happens. R's, John ___ 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?
In article you write: >On Sun, 13 Dec 2020, Randy Bush wrote: >> i find this extremely frustrating. i realize that i am a dinosaur, but >> i really want a usable response to a whois query. compare > >I would just like to be able to publish whois information if I /choose/ >to rather than, for instance, Hover's broken "whois privacy" toggle which >toggles but doesn't do anything. I've talked to Tucows management and been part of the endless ICANN WHOIS process. The combination at ICANN of extreme overcautiousness and (from some parties) self-serving misunderstandings of the issue are quite impressive. >I've fallen back to TXT records; why the heck not, they're overloaded for >a bunch of "prove you love me" epics already. What's wrong with RP records? That's what they're for. $ host -t rp taugh.com taugh.com has RP record hostmaster.iecc.com. rp.services.net. R's, John ___ 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?
In article you write: >My *impression* is the most serious risks a domain owner faces for losing >control of the domain are either because the registration lapses, as is >being discussed here, or because the domain is registered by someone else, >e.g. the tech or admin contact, who then either leaves the company or >refuses to give up control. ... In my experience, the most common problem is bit rot. For example, a few years ago one of our local churches had their domain expire the week before Easter. Ten years earlier whoever was the church secretary had set it up with a Tucows reseller, but the secretary had left long ago, the reseller had gone out of business, and if there were any renewal notices sent, they didn't go to anyone who saw them. By an Easter miracle, they happened to talk to a local ISP who happened to know I was a Tucows reseller and I happened to have good enough contacts to get the church's domain moved into my reseller account so I could renew it, but failing that they would have given up and started over with a new domain. Before anyone writes back with "they should have ...", they're a church, what they did a decade ago was reasonable at the time and they had no warning anything was wrong until their web site disappeared. I try to avoid this by only letting my users renew for two years at a time so I stay in touch with them, but I have run into situations where I know they are using the domain so I renew it, then they don't respond to the mail asking them to pay, so I eventually park their domain and wait for them to complain. "Oh, that old address, I don't use that any more." "You shoulda told me." R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] .frl TLD quality of signed delegations?
In article you write: >Is .FRL generally losing momentum and seeing declines in registrations? >(I haven't been keeping historical data on the total domain counts of >the various gTLDs, and have only "today's" numbers). Its largest size was 14563 names on 29 Dec 2017 and it's been shrinking. Friesland is not very big. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] resolver cache question
In article <2727165c-bf4c-49d8-b45f-8ffcb5a3c...@icir.org> you write: >Folks- > >I just finished reading a paper that basically tries to figure out >if a hostname is worth caching or not [1]. ... I can't give you a direct answer but the same question arose a while back when we were thinking about DNSBLs for IPv6 addresses. The obvious approach is a variant of rDNS so every IP address corresponds to a different DNSBL name, and it occurred to us that someone trying to avoid filtering could hop to a different IP address for every message, causing a whole lot of one time DNS lookups. I came up with a different design that more or less published a B-tree of IP CIDR ranges in the DNS, so all lookups within the same range would reuse the same answer. I did some modelling and the answer was a loud who cares. Even with IPv4 addresses about half of DNSBL lookups are never reused, and it's never been a problem. The only papers I could find on DNS cache performance were very old, back in the day when a megabyte was a whole lot of memory. I agree that this is indeed a non-problem. To the extent that it is a problem, the random names come from a small set of actors (Google Chrome, we're looking at you) and if you care, you're better off with special cases for the known problem makers. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] which breakage is this? *.org
In article you write: >-=-=-=-=-=- > >On Tue, 2020-11-03 at 12:07 +1100, Mark Andrews wrote: >> The anycast server is misconfigured. Some instances return DNS COOKIE >> responses and some don’t. > >wow, i wonder if that's due to the timing of the election here with the >political .orgs Don't be silly. There are ten million .org domains and I would be surprised if as many as a few thousand were political. Also, looking through my large trove of campaign e-mail, I see nearly all of it comes from .com addresses. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] How widely implemented are different DNSSEC algorithms?
Are there any published numbers estimating how well the various DNSSEC algorithms are supported in DNS caches and client software? Or to put it another way, were I to switch from signing with algorithm 8 to 13, how much would I regret it? TIA, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
In article <6f32301724d95a24777dbf993c28b0e35f9b8501.ca...@powerdns.com> you write: >I cannot speak for any other piece of software, but the way PowerDNS >Recursor uses connected UDP sockets to talk to authoritatives means >that the kernel already drops responses from wrong addresses, ... Seems to me that would be true for any software that uses the usual BSD or linux socket calls that match the host and port on received packets with recently sent ones. I'm having trouble figuring out how I would even arrange to receive replies from the wrong host short of using a raw socket that collected all incoming UDP packets, which would make it hard to run anything else that uses UDP on the same machine with the DNS client. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Nameserver responses from different IP than destination of request
In article you write: >should tell Google what to do. (And, yes, I certainly put myself in the latter >category.) I, too, would like to hear >if other resolver operators see this, ... Is there a summary anywhere of what common resolver software like bind and unbound do? I use unbound, but when I look at the unbound documentation I can't tell. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] Re: Separating .ARPA operations from the root zone
In article you write: >I'm sad to see that the root infrastructure, an infrastructure that is >ideal to update partially due to its extreme redundancy, would be a >place where we keep old stuffy software instead of keeping up to date >with new DNS technology. If ever there were a place *not* to deploy whizzo new DNS technology, the root is it. We don't need features, we need stability and reliability. The fewer changes the better. I note that this change is primarily a change to the .ARPA domain and the only change to the root is changing NS and glue which we know they can change reliably because they've done it for lots of other TLDs. >I am concerned that de-coupling .arpa might lead to the zone being >underserved. Or that IETF needs to start budgeting for running this >zone in the future itself. Rater than assuming that ICANN is incompetent, why don't we ask Kim what the provisioning strategy will be. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Separating .ARPA operations from the root zone
In article you write: >-=-=-=-=-=- >-=-=-=-=-=- >Folks, > >I wanted to draw attention to an Internet-Draft under development that seeks >to remove the unique interdependency that >the .arpa zone has with the root zone, by virtue of the zone being served by >the root servers: > > > https://www.ietf.org/id/draft-iana-arpa-authoritative-servers-01.txt > >We are looking for additional review of the proposed changes before taking >further steps. It looks fine but I have a question. One can download the .ARPA zone files from the same places as the root zone, by https or ftp from internic.net and by AXFR from two icann.org servers. Will that change? As far as I know it's not documented anywhere; you just have to know it's in the same places as the root. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] OpenDNS, Google, Nominet - New delegation update failure mode
In article <85882353-8f7c-365b-43e7-6092ad82c...@plum.ovh> you write: >I have a question, why does domain name have to be assigned by ICANN? >I expect everyone could have his/her own domain name, naming is freedom. That's not how the Internet works. There's only one set of root servers and for historical and practical reasons they take ICANN's advice about what goes into the root zone. People have been disagreeing about that for the past 25 years and there's vast amounts of material about it on the net. But this has gotten way outside anything related to DNS operations. R's, John PS: I have a friend who also wants .plum. Who decides who gets it? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] solutions for DDoS mitigation of DNS
In article <26a9dd93-91a3-dbc4-c34b-145f33e74...@plum.ovh> you write: >Hi Stephane, > >I saw you were from FRNIC. May I ask a question that, since I got a >domain from .ovh, It seems anyone can have a domain extension? So how >can I have my own extension, such as .plum? Shall I contact the root >server operators to put .plum glues there? Short answer: no. ICANN manages the addition of top level domains through very, very, complicated processes. They are not currently accepting applications for new top-level domains, but the last time they did, the fee to apply was $180,000. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] solutions for DDoS mitigation of DNS
In article , Tessa Plum wrote: >University has generally some private research projects who have their >domain names, but university won't let others see these domain names >unless the projects have got public. If those names are ever retrieved by users on networks outside your university, it's very likely that they're in public passive DNS databases that are widely visible. It is not realistic to believe that you can put names in your public DNS and not have the world know about them. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Any DNAME usage experience?
In article <22698cb2-ef91-f783-bc53-6f028cc6a...@nic.cz> you write: >On 30. 03. 20 12:35, Meir Kraushar via dns-operations wrote: >> - Obviously resolver compliance is very important (Knot support is >> questionable?) > >We intend to release fix in 5.1.0 release, probably next week: >https://gitlab.labs.nic.cz/knot/knot-resolver/-/merge_requests/965 > >I'm sorry for being late to the DNAME party. It's only been 20 years. The party's hardly gotten started. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Any DNAME usage experience?
In article <22698cb2-ef91-f783-bc53-6f028cc6a...@nic.cz> you write: >On 30. 03. 20 12:35, Meir Kraushar via dns-operations wrote: >> - Obviously resolver compliance is very important (Knot support is >> questionable?) > >We intend to release fix in 5.1.0 release, probably next week: >https://gitlab.labs.nic.cz/knot/knot-resolver/-/merge_requests/965 > >I'm sorry for being late to the DNAME party. It's only been 20 years. The party's hardly gotten started. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] weird queries for mx1.mx2.mx1.mx2...
In article you write: >-=-=-=-=-=- >-=-=-=-=-=- >-=-=-=-=-=- > >Hi Petr, > >We see something similar, albeit not so extreme. > >It's less deep, only 2 levels: > >mx1.mx1.example.nl > >But we also saw this: > >mx1.mx1.nl Same situation, *.example.nl and *.mx1.nl are both wildcarded, and point at a web server that responds to any URL. I don't suppose you caught who was making the queries? ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] weird queries for mx1.mx2.mx1.mx2...
In article <20200331092538.gy41...@straasha.imrryr.org> you write: >> mx1.mx1.mx2.mx2.mx2.mx1.mx2.mx1.mta-sts.mx2.mx1.mx1.mx2.mx2.mx2.mx1.mx2.maxonsoftware.com. >> A >> >> mx2.mx1.mx2.mx1.mx1.mx2.mta-sts.mx1.mx2.mx2.mx1.mx2.mx1.mx2.cineversityoneonone.net. >> A >> >> mx2.mx1.mx1.mx1.mx2.mx2.mx2.mta-sts.mx1.mx2.mx1.mx1.mta-sts.mx2.mx2.mx2.effluentialtechnologies.net. >> A > >The DNS for these domains is busted, the servers return NoError >responses, no answer, authority or additional records other than OPT... Try asking for A records for *.cineversityoneonone.net and you'll get one, that points to a live web server. They're wildcarded and point it returns a page that says deletion is pending for any URL, including mta-sts../.well-known/mta-sts.txt It looks like someone's mta-sts checker does not deal well with a big blob of html and javascript when it's expecting three lines of ASCII. It's clearly a bug, not malicious but I do wonder who it is. Perhaps I can set up a broken domain like that and see who comes visiting. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] weird queries for mx1.mx2.mx1.mx2...
In article <02fe7bae-fec6-f314-b189-4214b75ce...@nic.cz> you write: >This is query list for domain truckinsurancekentucky.com: > >mx1.mx1.mx1.mx1.mx1.mx2.mx1.mx2.mx1.mta-sts.mx1.mx1.mx2.mx2.mta-sts.mx1.mx1.truckinsurancekentucky.com. > >Domain truckinsurancekentucky.com is not the only one with this weird >behavior. Does anyone have an idea what is causing this? It sure looks like misconfigured mta-sts. That domain is dead, got another live one we could look at and see how it's configured? Tnx. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Any DNAME usage experience?
In article <5a408169-12b7-4f39-a69b-20b6e1ef8...@opendns.com> you write: >A few interesting things about DNAMES: > >* For unsigned zones, resolvers don’t have to do anything, but the DNAME >itself can break > - The synthesized CNAME makes the resolver “just work” > - RFC 3597 section 7 says that resolvers MUST uncompress DNAMEs. If they > don’t, they may serve corrupt RRs >So a nameserver that serves compressed DNAMEs must be “fixed” by the > resolver. Have you seen any nameservers that compress DNAMEs? That would be a very strange bug since it was always forbidden. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Any DNAME usage experience?
In article <20200329191324.gi41...@straasha.imrryr.org> you write: >On Sun, Mar 29, 2020 at 12:35:15PM -0400, John Levine wrote: > >> I have to say that at this point my advice is don't bother. Whatever >> problem you hope DNAMEs will solve, they won't. > >I see some administrators succesfully using DNAMEs to retarget >the entire "_tcp" subtree of a set of hosts to a common location. > >Something along the lines of: > >_tcp.mail1.example.com. IN DNAME _dane.example.com. >_tcp.mail2.example.com. IN DNAME _dane.example.com. >_tcp.mail3.example.com. IN DNAME _dane.example.com. >*._dane.example.com IN TLSA 2 1 1 ... > >This works fine. I suppose, although for this application, wouldn't this work just as well? *._tcp.mail1.example.com. IN CNAME _dane.example.com. *._tcp.mail2.example.com. IN CNAME _dane.example.com. *._tcp.mail3.example.com. IN CNAME _dane.example.com. _dane.example.com IN TLSA 2 1 1 ... I can see that if you had both mail and web with _25 and _443 TLSA, DNAME might be a little easier to set up. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Any DNAME usage experience?
In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >Hi > >I looking for insights, usage experience regarding DNAME record >implementation. >If any compatibility issues, client side problems, resolvers etc?.. >Highly apperciate If anyone could share their knowledge. My experience is that DNS software handles DNAME without trouble, but most people who use DNAME want it to do things it doesn't do. One common confusion is that DNAME only copies the tree below the name with the DNAME but not that name itself. The .CAT registry used to have DNAMEs to create unaccented versions of names with accents. Technically the DNAMEs did what they were supposed to, practically they were useless due to only mirroring the subdomains. The other is that people want DNAME to make the two name trees "the same", which is not true for many reasons. The main one is that web and mail servers have to be configured for the names they handle, and if use DNAME to point different names at them, they will treat those the same as any unrecognized names, i.e., badly. While it would be technically possible to have them regognize DNAMEs as aliases for the target names, that would be a a security nightmare since any hostile party could point his names at your server. Mail has an additional problem that RFC 1123 says the addresses in mail transactions have to be "canonicalized", which rules out DNAMEs. This rule is enforced spottily in practice, but enough to make DNAMEs doubly useless for mail. I have to say that at this point my advice is don't bother. Whatever problem you hope DNAMEs will solve, they won't. R's, John -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
In article <20200317021853.d6f1f1621...@ary.qy> you write:
>In article <20200317014627.gw68...@straasha.imrryr.org> you write:
>>Yes, the txtdata() method concatenates with spaces in a scalar context.
>
>Net::DNS is pretty funky.
To beat this dead horse a little more, here's the code that Mail::SPF
uses to collect the text strings (in Mail::SPF::Server.pm)
my $text = join('', $rr->char_str_list);
char_str_list() is right after txtdata() in the Net::DNS source code.
It returns the internal form of the data which is a list of the
strings.
Here's the slightly fancier code in Mail::DKIM (in Mail::DKIM::PublicKey.pm
# join with no intervening spaces, RFC 6376
if ( Net::DNS->VERSION >= 0.69 ) {
# must call txtdata() in a list context
$strn = join '', $rr->txtdata;
}
else {
# char_str_list method is 'historical'
$strn = join '', $rr->char_str_list;
}
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
In article you write: >Viktor Dukhovni wrote: >> >> While it does present a case that lines up with Paul's preferred >> semantics, I don't find the Net::DNS txtdata() behaviour in scalar >> contexts either normative or particularly compelling. :-( It's also completely irrelevant since no normal DNS client will see it. See my recent message about Net::DNS funkitude, R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
In article <20200317014627.gw68...@straasha.imrryr.org> you write:
>Yes, the txtdata() method concatenates with spaces in a scalar context.
Net::DNS is pretty funky. The txtdata() output method is something
that someone apparently thought was useful a long time ago but it's
neither the master file format nor the wire format
Here's what it gives you if you ask for that record formatted for a master file,
or hex of the wire format:
use Net::DNS;
print $Net::DNS::VERSION . "\n";
$rr = new Net::DNS::RR( name=> 'name',
type=> 'TXT',
txtdata => [ 'multiple', 'strings', 'string with spaces' ]
);
print "master format: "; $rr->print;
print "encoded: ",unpack("H*",$rr->encode(0)),"\n";
$ perl text.pl
1.21
master format: name.IN TXT multiple strings "string with spaces"
encoded:
046e616d65110024086d756c7469706c6507737472696e677312737472696e67207769746820737061636573
You get just what you'd expect, no stray spaces in the master record
or in the binary.
--
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
In article <20200315003454.gn68...@straasha.imrryr.org> you write: >Well, you'd be much better off with the more readable, and >equally maintainable: > >@ TXT ( "v=spf1" >" ip6:2001:4f8::/32" >" ip6:2001:559:8000::/48" >" ip4:149.20.56.0/24" >" ip4:24.104.150.0/24" >" ~all" ) > >With the qname changed to "@", since SPF clients do not prepend "_spf.", >and added "ip4:" and "ip6:" prefixes, AFAIK they're required. Life is definitely easier when you read the spec and do what it says. >> but i'd like to be able to remove those \032 workarounds in ~10 years. A gratuitously incompatible change to a widely implented 25 year old protocol? I wouldn't hold my breath. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
In article you write: >So if the issue is the TXT entry cant hold what you need it to hold, >then it needs to be more efficient. See how google does it - it works. Sorry, I don't understand your point, unless you're suggesting people use the way that Google breaks up its SPF into multiple records with different names with SPF includes to combine them. I guess that's OK but I don't see much merit in using four records with four names to represent info that would just as well fit into one record with one name. I presume Google can provision TXT records with multiple strings. >Lastly, TXT and SPF - blame debians Scott Kitterman, he was the one who >so furiously argued agaisnt SPF having its own RR, he is the one >responsible for the massive push that saw it junked. That's a rather egregious rewrite of history. When RFC 4408 was written, SPF was already widely implemented using TXT records. The DNS mafia of the era held the document hostage until the authors agreed to add a type 99 SPF record. In practice, nobody ever published type 99 records, other than a few of us who added hacks to our DNS crudware to mirror TXT records that started with v=spf1. Six years later, RFC 6686, which Scott did not write, surveyed over a million domains with MX records and found that rounded to the nearest percent, nobody published type 99 records, so that was that. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
In article <20200314225019.gm68...@straasha.imrryr.org> you write: >So my take is that applications that expect a single string per TXT >record should just join without inserting spaces, while applications >that expect multiple values can use the verbatim substrings without >concatenation. That sounds right. I gather the reason that SPF and DKIM use a single string rather than tokenized strings is that when they were developed over a decade ago, a lot of DNS web provisioning crudware only handled a single string per TXT record. Meng told me that the reason he didn't use a prefixed name was that a lot of the crudware couldn't handle names with underscores, either. DKIM was a little later and the underscore situation was improved, largely to SPF users complaining to their DNS providers. It was still a problem to publish keys longer than 1024 bits in a 255 byte string. -- Regards, John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping TXT records
In article <20200314203823.37938.qm...@f3-external.bushwire.net> you write: >On 14Mar20, Paul Vixie allegedly wrote: > >> yes. this code had to run on a PDP-11. > >Bummer. Based on this, is it reasonable to assume a TXT only holds >7-bit ASCII then? Not until the Experimental RFC1464 do we finally >find explicit mention of a code set for the contents of a TXT in a >very specific use-case. If you stuff arbitrary octal escapes into your txt records, it works with all of the DNS software I know. Back when I was trying to figure out how to do IPv6 DNSBLs efficiently I did an overclever design that stored the ranges in a B-tree with each node being a large TXT record full of binary glop. It worked OK. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
In article you write: > > >SM wrote on 2020-03-13 20:52: > >who are you? "SM" is not personal enough for my tastes. > >> Hi Paul, >> ... >> >> That matches https://kb.isc.org/docs/aa-00356 The RFC referenced in >> that article is RFC 4408 instead of RFC 7208. > >the concatenation of on 255-octet boundaries has >never been specified in a DNS RFC, and if the DKIM and SPF >specifications require this, they are legislating from the bench. Fortunately, that's not what they say. They say to catenate the strings in the TXT record when they are interpreted as SPF or DKIM instructions. The strings are however long they are. Some zone management software breaks overlong strings into 255 octet chunks but that's hardly new. djbdns did it in the 1990s. Spaces in SPF and DKIM records are significant so if you use master files, you have to quote the spaces. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
In article <746f7bc6-88d3-8420-1074-849b50514...@redbarn.org> you write: >oh my great goodness. in RFC 7208 we have this: > >3.3. Multiple Strings in a Single DNS Record This is unchanged from RFC 4408 which was published 15 years ago. DKIM does the same string smushing. See RFC 4871, published 13 years ago. >> _spfTXT ( v=spf1 >> ip4:140.20.56.0/24 ip6:2001:4f8:3::/48 >> ip4:24.104.150.0/24 ip6:2001:559:8000::/48 >> -all ) I think we can agree that SPF was not designed to make RFC 1034 master files look pretty. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] creeping poorness of judgement
In article <3423731.dTAWf75mkY@linux-9daj> you write: >today i got mail including this: > >: host aspmx.l.google.com[2607:f8b0:400e:c08::1b] said: >550-5.7.26 This message does not have authentication information or fails >to 550-5.7.26 pass authentication checks. To best protect our users from >spam, the 550-5.7.26 message has been blocked. Please visit 550-5.7.26 >https://support.google.com/mail/answer/81126#authentication for more 550 >5.7.26 information. l73si7852706pfd.109 - gsmtp (in reply to end of DATA >command) > >this is because i had no SPF record in my domain's TXT RRset. ... Sort of. Google only accepts mail over IPv6 that validates either with SPF or DKIM. You can send them mail over IPv4 same as always. I am not a big fan of SPF so I sign my mail with DKIM. >i briefly considered adding such a record until i found that only one TXT >string is permitted, so TXT "v=spf1 mx" not TXT (v=spf1 mx) in the zone file. Nope. You can have as many strings as you want. They're treated as though they were one catenated string. This is a concession to provisioning crudware that doesn't handle multi-string TXT records very well. (Those I agree are often ignorant.) >i guess i'll just add one with "v=spf1 +all" to shut google up? It is rarely a good idea to assume that the people to whom you are sending your mail are stupid. Your SPF of "mx ~all" is fine. >so many ignorant and poor judgements shaping this future. You can certainly disagree with Google's choices here, but they had their reasons and it's not because they're ignorant. What is convenient for those of us with individual or SME mail systems doesn't scale very well to systems that have to defend against billions of spam messages every day. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Google DNS Admin
In article you write: >-=-=-=-=-=- > >On Wed, 2020-01-08 at 03:27 -0500, Daniel Corbe wrote: >> Is there anyone from google on this list? >> >> Every well-known recursor is returning valid results for as57335.net >> except for 8.8.8.8 and 8.8.4.4 and I'd like some assistance getting >> down to the root of the issue. > >Works fine from here. Fails from here in upstate NY, local telco ISP fed through Firstlight. $ dig @8.8.8.8 as57335.net a ; <<>> DiG 9.10.6 <<>> @8.8.8.8 as57335.net a ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16908 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;as57335.net. IN A ;; Query time: 11 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Jan 08 14:55:32 EST 2020 ;; MSG SIZE rcvd: 40 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Questions on private nameservers registration
In article you write: >Another more question, can I put DE glues into other domain registry's >zone? For example, the COM's. You only use glue records when resolving the NS address would otherwise lead to a loop, so there's no .de glue in the .com zone. EPP does have name server objects which you can export to different registries to tell them that it's OK to use a name server, but those don't make the zone include glue records. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Link-local IP addresses for a resolver?
In article <9ca43b29-1345-4fd4-9766-36c624589...@isc.org> you write: >ISP SITE <-> CPE <-> CUSTOMER SITE > >The CPE is a SITE boundary. It is also a Link-Local Boundary. ULA source >packets DO NOT cross the CPE by default it the CPE is properly configured. Really? Are you sure you're not confusing LL and ULA addresses? Why would CPE filter ULA addresses? In the normal case where the ISP provides the customer with a default route, they're like global addresses. R's, John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] ULA or Link-local IP addresses for a resolver?
In article <20190925000333.ade8717b0...@fafnir.remote.dragon.net> you write: >marka> DNS servers that are expected to be reached across sites need to >marka> be globally unique addresses which ULA and LL are not. > >The IP address clients use to reach the resolver doesn't have to be the >same one that the resolver uses as source address when it queries. And >it's not uncommon to have an externally exposed recursive resolver on >the public side of a corporate firewall with queries from an internal >resolver being forwarded. Right. My resolver has a public v6 address, a LL, and a ULA. It sends outgoing queries on the public address but only responds to queries on the LL and ULA. The ULA works great, makes it harder for random outsiders to try to abuse it even if the ULA leaks outside my network. The LL sort of works, in clients with resolvers that understand link scoping, and not at all on hosts on my other network segment. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
