Re: [dns-operations] Testing of SVCB/HTTPS records
--- Begin Message --- On Mon 08 Apr 2024 09:54:57 GMT, Stephane Bortzmeyer wrote: > Does anyone know a tool (online or local) to test that published > SVCB/HTTPS records are correct? At least checking requirments like all > parameter keys in order, and ideally try to connect to check the > parameters. I don’t know any tool either, but curl plans to implement it: https://curl.se/dev/roadmap.html > the next few years - perhaps > > Roadmap of things Daniel Stenberg wants to work on next. It is > intended to serve as a guideline for others for information, > feedback and possible participation. > > "Complete" the HTTP/3 support > curl has experimental support for HTTP/3 since a good while > back. There are some functionality missing and once the final > specs are published we want to eventually remove the > "experimental" label from this functionality. > > HTTPS DNS records > As a DNS version of alt-svc and also a pre-requisite for ECH > (see below). > See: > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-02 > > ECH (Encrypted Client Hello - formerly known as ESNI) > See Daniel's post on Support of Encrypted SNI on the mailing > list. > Initial work exists in PR 4011 --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Vodafone AS25135 sending 3k req/s to AS112
Hello, Vodafone is sending 3k req/s (~10Mbps) of DNS garbage to my AS112 node from 88.82.0.0/19 If someone knows somebody there, could you please tell them to fix their resolvers? Here is what I’m seeing right now: [root@as112 ~]# time tcpdump -ni vtnet1 -c 20 port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vtnet1, link-type EN10MB (Ethernet), capture size 262144 bytes 19:33:42.811147 IP 88.82.13.11.54217 > 192.175.48.6.53: Flags [S], seq 39814353, win 29200, options [mss 1436,sackOK,TS val 2616906492 ecr 0,nop,wscale 8], length 0 19:33:42.811170 IP 88.82.13.27.34687 > 192.175.48.6.53: Flags [.], ack 1854115208, win 119, options [nop,nop,TS val 2616913819 ecr 3702446245], length 0 19:33:42.811183 IP 88.82.13.10.58825 > 192.175.48.42.53: Flags [F.], seq 3926102883, ack 2182550963, win 119, options [nop,nop,TS val 2625279810 ecr 3153170801], length 0 19:33:42.811196 IP 88.82.13.26.57233 > 192.175.48.6.53: Flags [.], ack 1828208115, win 115, options [nop,nop,TS val 2625275865 ecr 1865700866], length 0 19:33:42.811213 IP 88.82.10.218.49421 > 192.175.48.42.53: Flags [.], ack 2894862899, win 115, options [nop,nop,TS val 2625267389 ecr 209062963], length 0 19:33:42.811356 IP 88.82.13.26.57233 > 192.175.48.6.53: Flags [P.], seq 0:73, ack 1, win 115, options [nop,nop,TS val 2625275865 ecr 1865700866], length 73 42133% [1au] PTR? lb._dns-sd._udp.190.89.235.10.in-addr.arpa. (71) 19:33:42.811364 IP 88.82.10.218.49421 > 192.175.48.42.53: Flags [P.], seq 0:74, ack 1, win 115, options [nop,nop,TS val 2625267389 ecr 209062963], length 74 9544% [1au] PTR? lb._dns-sd._udp.176.163.204.10.in-addr.arpa. (72) 19:33:42.811472 IP 88.82.13.10.56867 > 192.175.48.42.53: Flags [.], ack 780117169, win 115, options [nop,nop,TS val 2625279810 ecr 2484585847], length 0 19:33:42.811495 IP 88.82.13.10.56867 > 192.175.48.42.53: Flags [P.], seq 0:55, ack 1, win 115, options [nop,nop,TS val 2625279810 ecr 2484585847], length 55 38817% [1au] PTR? 102.31.2.10.in-addr.arpa. (53) 19:33:42.811500 IP 88.82.10.219.43881 > 192.175.48.6.53: Flags [S], seq 1012389357, win 29200, options [mss 1436,sackOK,TS val 2616911235 ecr 0,nop,wscale 8], length 0 19:33:42.811791 IP 88.82.13.26.45281 > 192.175.48.42.53: Flags [.], ack 547297471, win 115, options [nop,nop,TS val 2625275865 ecr 1837071328], length 0 19:33:42.811808 IP 88.82.10.218.46467 > 192.175.48.42.53: 19298 PTR? lb._dns-sd._udp.7.116.21.10.in-addr.arpa. (58) 19:33:42.811873 IP 88.82.13.58.48062 > 192.175.48.6.53: 38788% [1au] PTR? lb._dns-sd._udp.80.243.39.10.in-addr.arpa. (70) 19:33:42.811878 IP 88.82.13.10.42689 > 192.175.48.42.53: Flags [.], ack 500116249, win 119, options [nop,nop,TS val 2625279810 ecr 2038550542], length 0 19:33:42.812196 IP 88.82.10.219.41012 > 192.175.48.6.53: 26381% [1au] PTR? lb._dns-sd._udp.83.241.19.10.in-addr.arpa. (70) 19:33:42.812203 IP 88.82.13.10.42689 > 192.175.48.42.53: Flags [F.], seq 0, ack 1, win 119, options [nop,nop,TS val 2625279810 ecr 2038550542], length 0 19:33:42.81 IP 88.82.13.26.45281 > 192.175.48.42.53: Flags [P.], seq 0:72, ack 1, win 115, options [nop,nop,TS val 2625275865 ecr 1837071328], length 72 21925% [1au] PTR? lb._dns-sd._udp.237.95.14.10.in-addr.arpa. (70) 19:33:42.812450 IP 88.82.13.10.38061 > 192.175.48.42.53: Flags [.], ack 1903258500, win 119, options [nop,nop,TS val 2625279810 ecr 3491999576], length 0 19:33:42.812459 IP 88.82.13.59.36361 > 192.175.48.6.53: Flags [.], ack 3710008644, win 115, options [nop,nop,TS val 2616913085 ecr 968827526], length 0 19:33:42.812472 IP 88.82.13.26.58583 > 192.175.48.6.53: Flags [.], ack 2580178843, win 119, options [nop,nop,TS val 2625275865 ecr 558694488], length 0 20 packets captured 22 packets received by filter 0 packets dropped by kernel real0m0.012s user0m0.000s sys 0m0.010s [root@as112 ~]# Thanks, -- Alarig ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] DNSViz Access to C-root
On Thu 02 Jul 2020 18:34:11 GMT, Stephane Bortzmeyer wrote: > On Thu, Jul 02, 2020 at 11:51:53AM -0400, > Matthew Pounsett wrote > a message of 76 lines which said: > > > We’ve been in discussion with Cogent for a while about finding a > > solution to the problem, and last month finally put something in > > place. > > And what is the solution? A static tunnel to a Cogent POP? I’m also curious, from the NLNOG ring LG, HE doesn’t see C and Cogent doesn’t see DNSViz: bird> show route all for 2001:500:2::c where bgp_path ~ [= * 6939 * =] bird> show route all for 2620:ff:c000::138 where bgp_path ~ [= * 174 * =] bird> Which I can confirm from the HE RING node and RIPE Atlas using probes from the second class citizen ISP in France. grifon@hurricane01:~$ mtr -bzwe c.root-servers.net Start: Thu Jul 2 18:27:35 2020 HOST: hurricane01.ring.nlnog.net Loss% Snt Last Avg Best Wrst StDev 1. AS6939 ve1386.core3.fmt1.he.net (2001:470:0:292::1) 0.0%10 0.3 0.4 0.2 1.4 0.0 2. AS??? ??? 100.010 0.0 0.0 0.0 0.0 0.0 alarig@jeunet ~ % blaeu-traceroute --asn 12322 --format --do_lookup --do_reverse_lookup 2620:ff:c000::138 Using IP: 2620:ff:c000::138 Measurement #26107957 Traceroute 2620:ff:c000::138 from AS #12322 uses 5 probes 5 probes reported Test #26107957 done at 2020-07-02T18:43:15Z From: 2a01:e34:ed41:cb40:a2f3:c1ff:fec4:4a9d12322PROXAD, FR Source address: 2a01:e34:ed41:cb40:a2f3:c1ff:fec4:4a9d Probe ID: 12449 12a01:e34:ed41:cb40::1No PTR12322PROXAD, FR[0.932, 0.623, 0.597] 2['*', '*', '*'] 3['*', '*', '*'] 4['*', '*', '*'] 5['*', '*', '*'] 6['*', '*', '*'] 255['*', '*', '*'] -- Alarig ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] glitch on [ip6|in-addr].arpa?
On jeu. 17 oct. 09:44:07 2019, Adam Vallee wrote: > I would suggest to everyone who has access to Telia or GTT, to try them > out, and then you can possibly save money by dumping Cogentco. (That's if > any of you are also part of your Network Architecture Teams.) I have Cogent (and Telia and GTT) and don’t have any issue with them. -- Alarig ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] glitch on [ip6|in-addr].arpa?
On jeu. 10 oct. 22:31:48 2019, Adam Vallee wrote: > Cogent and Hurricane Electric are not and never have been Tier 1 providers > they both have Transit provided through other carriers. Cogent is a Tier 1 provider, they don’t have any transit. Although they don’t have an IPv6 full-view. -- Alarig ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
