Re: [dns-operations] creeping poorness of judgement
Hello, At 09:07 PM 13-03-2020, Paul Vixie wrote: who are you? "SM" is not personal enough for my tastes. I reviewed the draft which was published as a RFC. Apologies for causing the above-mentioned problem. 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. RFC 1035Domain Implementation and SpecificationNovember 1987 is expressed in one or two ways: as a contiguous set of characters without interior spaces, or as a string beginning with a " and ending with a ". Inside a " delimited string any character can occur, except for a " itself, which must be quoted using \ (back slash). Because these files are text files several special encodings are necessary to allow arbitrary data to be loaded. In particular: ... ( ) Parentheses are used to group data that crosses a line boundary. In effect, line terminations are not recognized within parentheses. ... Mockapetris[Page 35] i think this means i won't be using SPF or DKIM, nor exchanging e-mail with anyone who requires that i do so. piling kluge on kluge because the right person wasn't in the right room 15 years ago is no way to build a railroad i'm willing to ride on. The right people were around. However, the discussions which occurred approximately five years ago were controversial. Regards, -sm ___ 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
Hi Paul, At 08:04 PM 13-03-2020, Paul Vixie wrote: oh my great goodness. in RFC 7208 we have this: 3.3. Multiple Strings in a Single DNS Record As defined in [RFC1035], Sections 3.3 and 3.3.14, a single text DNS record can be composed of more than one string. If a published record contains multiple character-strings, then the record MUST be treated as if those strings are concatenated together without adding spaces. For example: IN TXT "v=spf1 first" "second string..." is equivalent to: IN TXT "v=spf1 firstsecond string..." TXT records containing multiple strings are useful in constructing records that would exceed the 255-octet maximum length of a character-string within a single TXT record. note the lack of a space between the word "first" and the word "second". this means: That matches https://kb.isc.org/docs/aa-00356 The RFC referenced in that article is RFC 4408 instead of RFC 7208. Regards, -sm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] c.root-servers.net over IPv6
Hi Shumon, At 12:46 PM 03-02-2020, Shumon Huque wrote: Didn't we discuss this recently? Sorry, I missed that thread. I assume this is the Cogent<->Hurricane Electric IPv6 peering issue. See the long thread that starts here (short summary: dnsviz is singly homed to HE so can't reach Cogent IPv6 servers): Thanks for the feedback. Regards, -sm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] c.root-servers.net over IPv6
Hello, c.root-servers.net (2001:500:2::c) is not responding to queries over IPv6 [1]. Regards, -sm 1. The error from DNSViz is "arpa zone: The server(s) were not responsive to queries over UDP. (2001:500:2::c)" ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] First new gTLD using ICANN's Name Collision Occurrence Management Framework
Hi Chris, At 05:38 28-08-2014, Chris Thompson wrote: The gTLD otsuka, created sometime in the last 24 hours, appears to be the first to use the wildcards described at [snip] What do people think about this business? Is anyone taking specific precautions to detect attempts to connect to 127.0.53.53? I presume that the people who invented this stuff know what they are doing. Regards, -sm ___ 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] First new gTLD using ICANN's Name Collision Occurrence Management Framework
Hi Rod, Warren, At 14:13 28-08-2014, Rod Rasmussen wrote: I note that these documents speak to many of the issues being exposed here (and yes, full disclosure, I wrote a small portion of the text/reviewed them): Was there a response to those issues? At 14:36 28-08-2014, Warren Kumari wrote: So, I just realized that this sounded like a jab specifically at JAS (the folk who proposed the 127.0.53.53 answer) -- this was actually instead supposed to be a jab at everyone :-) That is how I read it. :-) Regards, -sm ___ 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] AAAA record for c.root-servers.net
Hi Stephan, At 15:15 30-03-2014, Stephan Lagerholm wrote: c.root-servers.net is not reachable over v6 for everybody. There appears to be some peering disputes between operators over v6 still. Additionally, Leen Besselink told me on another mailing list (unbound) that it is advertized as a /48 that might get filtered. Route to IPv6 node 2001:500:2::c 125 ms 25 ms 24 ms 2001:470:0:286::1 282 ms 41 ms 50 ms 2001:470:0:270::2 351 ms 48 ms 50 ms 2001:470:0:240::1 474 ms 102 ms 72 ms 2001:470:0:1b4::1 575 ms 74 ms 74 ms 2001:470:0:32::2 6* * * ? Route to IPv6 node 2001:500:2::c 11 ms 1 ms 1 ms 2001:470:0:2cd::1 266 ms 77 ms 73 ms 2001:470:0:2cf::2 383 ms 95 ms 98 ms 2001:470:0:298::1 4 107 ms 100 ms 111 ms 2001:470:0:270::2 5 112 ms 117 ms 107 ms 2001:470:0:240::1 6 145 ms 145 ms 134 ms 2001:470:0:1b4::1 7 137 ms 137 ms 145 ms 2001:470:0:32::2 8* * * ? Route to IPv6 node 2001:500:2::c 136 ms 49 ms 64 ms 2001:470:0:29f::1 2 113 ms 98 ms 134 ms 2001:470:0:26a::1 3 190 ms 198 ms 199 ms 2001:470:0:294::1 4 184 ms 226 ms 192 ms 2001:470:0:72::1 5 191 ms 193 ms 199 ms 2001:470:0:2b7::1 6 222 ms 193 ms 193 ms 2001:470:0:32::2 7* * * ? Regards, -sm ___ 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] chrome's 10 character QNAMEs to detect NXDOMAIN rewriting
Hi Damian, At 18:17 26-11-2013, Damian Menscher wrote: Back to solving the problem of traffic at the roots, I've always been curious why recursive resolvers don't just AXFR the root zone file and cache the list of TLDs. Yes, From some RFC: Root servers SHOULD NOT answer AXFR, or other zone transfer, queries from clients other than other root servers. This restriction is intended to, among other things, prevent unnecessary load on the root servers as advice has been heard such as To avoid having a corruptible cache, make your server a stealth secondary for the root zone. The root servers MAY put the root zone up for ftp or other access on one or more less critical servers. Some root servers allow AXFR; some do not allow AXFR. Regards, -sm ___ 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] serving the root zone
Hi Jim, At 01:35 27-11-2013, Jim Reid wrote: So what? The root zone file is freely available to anyone who wants it. AXFR from a root server is not the only mechanism to get a copy. And as Joe just said, it's not necessarily a Good Thing for resolving servers to keep a local copy of the root zone. Yes. BTW, you quoted Section 2.7 of RFC2870. That BCP is over 13 years old. The root (server system) of 2000 is very different from today's. There was no anycasting back then. The root wasn't signed. ICANN had only created 7 gTLDs. Verisign didn't generate the root zone. etc, etc. Although this document is an excellent starting point for anyone operating an important authoritative name server, it should not be viewed as the final, definitive word on this topic. Yes, it is an old document. I don't read it as the definitive word as a lot has changed since the document was published. Regards, -sm ___ 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] It's begun...
Hi Ed, At 13:01 23-10-2013, Edward Lewis wrote: My sensors show 4 new gTLDs in the last hour or so...IDN, non-ccTLD...added between 1800 and 1900 UTC. http://blog.icann.org/2013/10/first-new-gtlds-get-the-green-light-for-delegation/ Regards, -sm ___ 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
At 20:36 18-10-2013, Kauto Huopio wrote: It seems that .QA TLD could be currenty in wrong hands: google.com.qa. 86400 IN NS ns1.web4africa.com. google.com.qa. 86400 IN NS ns2.web4africa.com. google.com.qa. 86400 IN NS ns3.web4africa.com. google.com.qa. 86400 IN NS ns4.web4africa.com. Regards, -sm ___ 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] Querying version.bind illegal?
Hi Vitalie, At 06:39 23-05-2013, Vitalie Cherpec wrote: I've developed a DNS checking tool (http://www.dnsinspect.com/). After 5 years of running it without any issues, I've received today a compliant through my ISP from a big company in a foreign country. This comment is not legal advice. They pretend that my VPS is attacking their infrastructure while querying their DNS server's version and this request can be regarded as cyber-terror attack (my tool tries only to warn users exposing the DNS software version). If the number of complaints is significant enough to bother your provider, it might consider it cheaper to shut down your service. I don't know whether your provider will bother spending money to keep your service running even if your tool is considered as something good. It might help other people to know which nameserver should not be used for DNS queries. Regards, -sm ___ 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] Capturing 8.8.8.8 Traffic
Hi Graham, At 09:26 25-02-2013, Graham Beneke wrote: office and NOC to a mom-and-pop IT shop. While I question the wisdom in that, I was far more concerned by the fact that this mom-and-pop shop had configured Google Public DNS as the resolver for everything on their LAN. A lot of people use 8.8.8.8. I don't know whether it is due to the lemming [1] effect or swarm intelligence. Now on my corner of the planet Google DNS is 190ms away. Never mind the mess we have with all the CDNs mapping their traffic to a different continent. So what are you thoughts on capturing these queries and answering them on local resolvers that are 10ms away? DNS interception is not a good idea in my opinion. The folks at Google are certainly not going to encourage us to spoof responses from their servers but are there any other potential pitfalls with doing this to save the customers from themselves? Once that becomes popular the regulator might wish to standardize it (see draft-iab-filtering-considerations-02). Saving the customers from themselves is a good intention. Regards, -sm 1. Lemmings are small rodents that have been known to follow each other as they charge to their deaths off the edge of cliffs. This is actually an unsubstantiated myth about lemmings. ___ 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] Capturing 8.8.8.8 Traffic
Hi Carlos, At 10:28 25-02-2013, Carlos M. Martinez wrote: It might sound stupid, but I firmly believe the main reason everyone is now switching to Google's servers is that they are easy to remember and to dictate over the phone. I don't think that it is stupid. One could argue that a few of the Google decisions are well-thought. In my case... (DSL provider at home), I have the choice of 200.40.230.245 or 8.8.8.8. Which one do you think my 63-year-old dad will configure more easily when tutored over the phone? :D The second one. Regards, -sm ___ 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] Another whitepaper on DDOS
At 09:26 22-02-2013, Matthäus Wander wrote: This paper describes a censorship attack which could be mitigated by DNSSEC: http://conferences.sigcomm.org/sigcomm/2012/paper/ccr-paper266.pdf See https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005343.html Regards, -sm ___ 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] getting .CW recognised in the Google ccTLD tables/databases ...
At 07:54 22-01-2013, .CW Registry Curacao wrote: Please find attached the history of some conversations (between my colleague Jeffrey) with Google support. The problem is not related to email or DNS. It related to the web. It may be easier to contact web folks who can fix it. Regards, -sm ___ 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] What's a suffix?
Hi Matthew, At 20:32 20-01-2013, Matthew Ghali wrote: matter experts on a mailing list for dns operators. I'm obviously behind again so please advise on how I can recognize a suffix in the wild, and distinguish it from a garden-variety old-fashioned domain name. See RFC 6265. Regards, -sm ___ 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] responding to spoofed ANY queries
Hi George, At 01:53 10-01-2013, George Michaelson wrote: What makes you think they won't? I mean, isn't this a classic mistake of cold war defense modelling, that you assume your enemy will use weapons you can confidently defend against and ignore the ones you suspect you cannot? There are parallels with antispam. The current suspect (ANY queries) will be considered as bad. Abusers will move to the next low-hanging fruit [1]. I would have to do something about the low-hanging fruit if it turns into an operational problem. The problem is amplification. It can only be mitigated. Regards, -sm 1. https://lists.dns-oarc.net/pipermail/dns-operations/2006-March/000135.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] Question about L-Root IP address
Yasuhiro-san, At 01:29 28-12-2012, Yasuhiro Orange Morishita wrote: I remember the official debut date of M-Root is Aug 22, 1997. In the root hint file: http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/namedb/root.cache.diff?r1=1.7r2=1.8 The SOA for the root zone when M-Root was moved was 1997082200 (official debut date). M-Root was in use before that (see the diff in the message from Peter Koch). Regards, -sm ___ 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] PTR records, and IANA blackhole
Hi Chris, [Bcc to contact address] At 11:47 16-11-2012, Roosenraad, Chris wrote: Anyone else seeing timeouts from blackhole-1.iana.org and blackhole-2.iana.org? Yes. Regards, -sm ___ 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] DNS queries to g.root-servers.net over TCP
Hi Jim, At 09:41 04-10-2012, Cassell, James D. CIV DISA NS233 wrote: We have made a change to improve g-Root's responsiveness to TCP queries. Please let me know if you are still seeing a problem. The problem is solved. Thanks, -sm ___ 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
[dns-operations] DNS queries to g.root-servers.net over TCP
Hello, Does g.root-servers-con2-1.net for g.root-servers.net support DNS queries over TCP? Regards, -sm ___ 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
[dns-operations] RIPE reverse DNS events on 13 June
RIPE published a timeline of the reverse DNS events which occured on 13 June ( https://labs.ripe.net/Members/dfk/timeline-of-reverse-dns-events ). It's nice to see the level of openness. Regards, -sm ___ 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] Why would an MTA issue an ANY query instead of an MX query?
Hi Roland. At 03:33 10-06-2012, Dobbins, Roland wrote: If that's it, then would asking djb to change its behavior so as to issue TXT requests to look for SPF records make sense? There is a thread at https://lists.dns-oarc.net/pipermail/dns-operations/2009-October/004542.html about whether changes in behavior will happen. The issue may not be SPF (see one of the patches http://www.saout.de/misc/spf/qmail-spf-rc5.patch ). Regards, -sm ___ 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
