Re: [dns-operations] dns-operationsMysteries of DNSSEC
"John Levine" writes: 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. Do check/worry about DDoS reflections from UDP requests for DNSKEYs. A number of addresses out there do seem to always request large packet type responses, which is always questionable. Making sure something like RRL is on/implemented is a good thing to do as well. In this case it's a lot for my tiny server but the total is still only a few queries per second. I also get a great deal of junk queries for people who seem to have very peculiar ideas of what my server does. I've tried various ways to make them go away such as a referral to an NS that resolves to 127.0.0.1 or a giant referral to a dozen randomly named NS each with a dozen random IP addresses. Didn't help. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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] Opportunity to operate a non-gTLD non-ccTLD TLD
The incumbent is Verisign. Any reason to believe they are looking to replace them? It might just be the USG has to go through a procurement process for this sort of thing every few years. Sure. Just wondering if there are reasons that the USG might be unhappy with VRSN. The RFP says they currently do not provide DNS service to registrants but want the new contractor to do so, to make the DNS more secure and reliable. I would imagine VRSN could do that. 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
On Fri, 3 Jun 2022, Brian Dickson wrote: If this increases the number of names that will break search lists from 1487 to 1488, how much of a problem is this likely to be in practice, which leads back to ... If it was ONLY a progression of 1487->1488, it might not be that bad (but again, that all depends on what number 1488 actually is.) What it is actually is an exercise in survivorship bias. Anyone who might have been impacted by any of the earlier rounds of expansion, will (likely) have learned their lesson. That lesson may depend on tribal knowledge, which might not be reliable enough for any previous victim to not be re-victimized. Unfortunately, now we've circled back to where we started. Remember that the NC in NCAP stands for Name Collision, and the whole point of the project is to figure out how risky it is to add familiar looking new names. In the last round of TLD expansion they added over 1000 names but indefinitely deferred requests for .CORP .HOME and .MAIL which had well known existing uses. So now I'm scratching my head, what are they hoping to learn from this exercise that wouldn't be totally dominated by the choice of name? I'm tempted to suggest adding .BELKIN and see how many old routers fail. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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] Input from dns-operations on NCAP proposal
On Fri, 3 Jun 2022, John Levine wrote: In such a configuration, if the host name "foo" matches the candidate TLD "foo", and the latter is changed from NXDOMAIN ... 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. It occurs to me there is another way to look at this. There are already 1487 delegated TLDs, and I doubt anyone could name more than a small fraction of them. If this increases the number of names that will break search lists from 1487 to 1488, how much of a problem is this likely to be in practice, which leads back to ... 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. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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
On Tue, 8 Sep 2020, Puneet Sood wrote: A single recursive resolver process can make a large number of outbound requests to thousands (if not more) of nameservers. Keeping one socket for each unique combination of (resolver IP, nameserver IP) becomes expensive in such an environment. Using more than one resolver IP provides additional entropy for the queries. But you need a separate socket for each port number if you're doing port randomization. In any event, I'd be more interested in knowing how much DNS client software uses connected sockets rather than speculating about it. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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] looking for suggestion: ML for DNS anti-dos
In article , Warren Kumari wrote: One thing to keep in mind is that DNS traffic is a VERY noisy data source, and corrupt / pathologic queries are incredibly common.. I would triply emphasize that. Data from the root servers show that the vast majority of queries they get are garbage: technically ill-formed or for names that have never existed and likely never will. That's less of a problem at less prominent servers, but even at my tiny system hosting domains you've never heard of, I get plenty of junk queries for things like AFSDB records and for domains I don't handle. -- 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
tisf.net. 120 IN TXT "v=spf1 mx ~all" my actual list is about 300 octets long. i won't be putting it into a single string. you know this; why are you going backward in the thread? can you address the question -- would my example work for SPF clients? The SPF clients I know all follow the spec. They glom the strings in the TXT record together. So long as you separate your tokens with spaces and stay within the lookup limits of RFC 7208 sec 4.6.4 they should work fine. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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
so, like this? ;; ANSWER SECTION: _spf.tisf.net. 120 IN TXT "mx " "~all" Aw, come on, you know how to read an RFC. Like this: tisf.net. 120 IN TXT "v=spf1 mx ~all" 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] Link-local IP addresses for a resolver?
On Wed, 25 Sep 2019, Warren Kumari wrote: ULAs are very from unique -- there is a huge bias towards things which humans can remember / cute names, etc (this is very similar to the "IPv6 space is namp / scannable because people name hosts in deterministic ways" - see some presentations from Fernando Gont). There is a large ULA bias towards fd00::, fd10::, fdfd::, fd00:dead:beef:, fd00:bad:coff:ee::. Sigh. If people don't follow the spec, not much we can do about that. My ULAs start with fde3:783e:127d: which I generated with a one line shell script $ jot -r -w%02x 10|rs Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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] Link-local IP addresses for a resolver?
ISP’s advertings ULA’s to customers have similar problems with advertising LL to customers. ULAs do not need scope IDs, so some of the problems are avoided. As Mark later reminded us, ULAs are not normally routed across customer boundaries. They work great within a single network, not so great from ISP to customer. In view of the fact that global IPv6 addresses are cheap and plentiful and are likely to remain so, the solution here is pretty obvious. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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] Link-local IP addresses for a resolver?
On Wed, 25 Sep 2019, Mark Andrews wrote: RFC 7084. Basic Requirements for IPv6 Customer Edge Routers 3.2.1 The IPv6 CE router defaults to acting as the demarcation point between two networks by providing a ULA boundary, a multicast zone boundary, and ingress and egress traffic filters. Which is referenced in the CableLabs documents. Well, that's a drag. Lucky we have plenty of global IPv6 addresses to use instead. ULA still works fine in a situation like mine where the resolver and clients are all within the same network but I realize that's a different question. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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] Link-local IP addresses for a resolver?
On Wed, 25 Sep 2019, Mark Andrews wrote: ISP’s advertings ULA’s to customers have similar problems with advertising LLL to customers. The CPE should be the site boundary making the ISP’s DNS servers unreachable from inside the customer’s network. DNS servers that are expected to be reached across sites need to be globally unique addresses which ULA and LL are not. If a ULA isn't globally unique, something is pretty broken. Each ULA contains a 40 bit random global ID in the prefix that's there so ULAs on different networks won't collide if they happen to be connected. That's why the U stands for, you know, Unique. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY 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
