Re: [dns-operations] ag.gov not providing NXDOMAIN responses

[Stephane Bortzmeyer]

On Tue, Apr 09, 2024 at 01:09:20PM -0500,
 David Zych  wrote 
 a message of 121 lines which said:

> The problem: when queried for a record underneath ag.gov. which does
> not exist, these nameservers do not return a proper NXDOMAIN
> response; instead, they don't answer at all.

Funny enough, it depends on the QTYPE.

% dig @ns2.usda.gov. nonono.ag.gov A 
;; communications error to 2600:12f0:0:ac04::206#53: timed out
;; communications error to 2600:12f0:0:ac04::206#53: timed out
;; communications error to 2600:12f0:0:ac04::206#53: timed out
;; communications error to 199.141.126.206#53: timed out

; <<>> DiG 9.18.24-1-Debian <<>> @ns2.usda.gov. nonono.ag.gov A
; (2 servers found)
;; global options: +cmd
;; no servers could be reached

% dig @ns2.usda.gov. nonono.ag.gov NS

; <<>> DiG 9.18.24-1-Debian <<>> @ns2.usda.gov. nonono.ag.gov NS
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44750
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1220
; COOKIE: 108e6a3526539745cbe04caf6617b75afc5cf42f25232e56 (good)
;; QUESTION SECTION:
;nonono.ag.gov. IN NS

;; AUTHORITY SECTION:
ag.gov. 900 IN SOA ns1.usda.gov. duty\.officer.usda.gov. (
...

> The practical trouble this causes has to do with an increasingly popular DNS 
> privacy feature called QNAME Minimization, which depends upon authoritative 
> DNS servers like yours responding in a standards-compliant way to queries like
> 
> _.ag.gov IN A
> _.ars.ag.gov IN A
> _.tucson.ars.ag.gov IN A

More fun: the previous version of QNAME minimisation used QTYPE=NS. It
then changed to QTYPE=A precisely to work around broken
middleboxes. (And also to avoid sticking out.)

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Testing of SVCB/HTTPS records

[Stephane Bortzmeyer]

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.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Strange deviation from DNS Operations normal work, just for sunday

[Stephane Bortzmeyer]

On Sun, Mar 03, 2024 at 04:54:24PM +,
 Turritopsis Dohrnii Teo En Ming  wrote 
 a message of 33 lines which said:

> > * anyway, nobody knows how many DNS servers are there (except may be
> > the NSA?)
> 
> Will the National Security Agency knows how many DNS servers there are in the 
> whole world?

To tell the truth, your questions are quite strange and one may wonder
if you really think before you write.

So, the problem with the NSA is not what they know, it is what they
will tell.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNS Operations

[Stephane Bortzmeyer]

On Sun, Mar 03, 2024 at 04:05:43PM +,
 Turritopsis Dohrnii Teo En Ming via dns-operations 
 wrote 
 a message of 98 lines which said:

> I define most popular as the largest number of DNS server installed
> throughout the whole world.

OK but this is very questionable:

* some DNS servers have one user, some have millions,
* resolver or authoritative server? They are two quite different types
  of DNS servers,
* anyway, nobody knows how many DNS servers are there (except may be
  the NSA?)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .ke - something wrong with DNSKEYs?

[Stephane Bortzmeyer]

On Fri, Mar 01, 2024 at 04:27:03PM +0100,
 Ondřej Surý  wrote 
 a message of 33 lines which said:

> does anyone else see this?
> 
> https://dnsviz.net/d/han.ke/ZeHwpA/dnssec/

Zonemaster sees similar
.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .ke - something wrong with DNSKEYs?

[Stephane Bortzmeyer]

On Fri, Mar 01, 2024 at 05:05:30PM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 11 lines which said:

> On Fri, Mar 01, 2024 at 04:27:03PM +0100,
>  Ondřej Surý  wrote 
>  a message of 33 lines which said:
> 
> > does anyone else see this?
> > 
> > https://dnsviz.net/d/han.ke/ZeHwpA/dnssec/
> 
> Zonemaster sees similar
> <https://zonemaster.fr/en/result/41fec1d862e7d78a>.

Also, like Zonemaster and DNSviz, RIPE Atlas probes show that, indeed,
ns2ke.dns.business does not always send DNSKEYs:

% blaeu-resolve --requested 100 --nameserver NS2KE.DNS.BUSINESS --nsid 
--ednssize 4096 --type DNSKEY ke
Nameserver NS2KE.DNS.BUSINESS
[] : 91 occurrences 
[TIMEOUT] : 1 occurrences 
[256 3 8 aweaadwi0wdlxihuia0n2oqlif9+xjju qyjxhglrjqr6m47xepvvls9aft+7tvet 
wo1alo 257 3 8 aweaazlaskgfz2dilbzrqbepwtpkp62g 
rjghjqas+7iogcsagazob8jajtrgpwrf mbmdcp] : 2 occurrences 
Test #68174319 done at 2024-03-01T16:04:22Z
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .RU zone failed ZSK rotation

[Stephane Bortzmeyer]

On Wed, Jan 31, 2024 at 04:37:02PM +0200,
 Phil Kulin  wrote 
 a message of 56 lines which said:

> Done. New serial number 4058860. New active ZSK
> https://dnsviz.net/d/ru/ZbpWZg/dnssec/

There is now a detailed technical post-mortem. These official
explanations fit the facts that we observed. Nice bug.

https://www.rbc.ru/technology_and_media/07/02/2024/65c38fea9a794752176bd3a0
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .RU zone failed ZSK rotation

[Stephane Bortzmeyer]

On Wed, Jan 31, 2024 at 04:34:40AM +0200,
 Phil Kulin  wrote 
 a message of 45 lines which said:

> Timeline:

Thanks.

I'm not convinced that the subject of this thread is useful. The chain
of keys was always correct (unlike many DNSSEC problems, the DS, and
DNSKEY were always in sync), the problem being that ZSK 52263 produced
invalid signatures.

Two hypothesis:

1) Something strange in this specific key broke the signatures (funny
but unlikely)

2) The signing system had a sudden problem. Note that .ru went back,
not only to the the previous ZSK but also to a previous zone, and the
SOA serial (4058856) did not change since (it changed every ~ two
hours before). It is possible that they cannot sign anymore.

Note: there will be a short talk about this incident in FOSDEM
(Brussels) on saturday, either at the DNS devroom or during the
lightning talks.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] [ra...@psg.com: swedish dns zone enumerator]

[Stephane Bortzmeyer]

A domain crawler (nothing catastrophic, just for information).
--- Begin Message ---
i have blocked a zone enumerator, though i guess they will be a
whack-a-mole

others have reported them as well

/home/randy> sudo tcpdump -pni vtnet0 -c 10 port 53 and net 193.235.141
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:42:39.516849 IP 193.235.141.90.32768 > 666.42.7.11.53: 14 NS? 33j4h.org.al. 
(30)
22:42:39.517640 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 
33m6d.xn--mgbayh7gpa. (38)
22:42:39.519169 IP 193.235.141.17.32768 > 666.42.7.11.53: 14 NS? 33lxd.tn. (26)
22:42:39.520064 IP 193.235.141.171.32768 > 666.42.7.11.53: 14 NS? 33md6.jo. (26)
22:42:39.521081 IP 193.235.141.247.32768 > 666.42.7.11.53: 14 NS? 33lxd.lb. (26)
22:42:39.523981 IP 193.235.141.162.32768 > 666.42.7.11.53: 14 NS? 33pd2.az. (26)
22:42:39.525043 IP 193.235.141.60.32768 > 666.42.7.11.53: 14 NS? 33nc5.com.al. 
(30)
22:42:39.526185 IP 193.235.141.209.32768 > 666.42.7.11.53: 14 NS? 33nc5.sz. (26)
22:42:39.527931 IP 193.235.141.150.32768 > 666.42.7.11.53: 14 NS? 33q5p.com.al. 
(30)
22:42:39.529516 IP 193.235.141.210.32768 > 666.42.7.11.53: 14 NS? 33qbq.com.al. 
(30)
10 packets captured
124 packets received by filter
0 packets dropped by kernel

inetnum:193.235.141.0 - 193.235.141.255
netname:domaincrawler-hosting
descr:  domaincrawler hosting
org:ORG-ABUS1196-RIPE
country:SE
admin-c:VIJE1-RIPE
tech-c: VIJE1-RIPE
status: ASSIGNED PA
notify: c+1...@resilans.se
mnt-by: RESILANS-MNT
mnt-routes: ETTNET-LIR
created:2008-04-03T11:21:00Z
last-modified:  2017-04-10T12:47:06Z
source: RIPE

randy
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anchors.atlas.ripe.net/ripe.net - DNSSEC bogus due expiration

[Stephane Bortzmeyer]

On Wed, Nov 01, 2023 at 12:18:42PM -0400,
 Viktor Dukhovni  wrote 
 a message of 67 lines which said:

> Specifically, in the case of signed zones, monitoring MUST also include
> regular checks of the remaining expiration time of at least the core
> zone apex records (DNSKEY, SOA and NS), and ideally the whole zone, both
> on the primary server and the secondaries.

Indeed. If you use Nagios or compatible (such as Icinga), I recommend
this plugin for signatures monitoring:

http://dns.measurement-factory.com/tools/nagios-plugins/check_zone_rrsig_expiration.html

(If you use Debian, it is in the package monitoring-plugins-contrib.)

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anchors.atlas.ripe.net/ripe.net - DNSSEC bogus due expiration

[Stephane Bortzmeyer]

On Wed, Nov 01, 2023 at 01:37:14PM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 17 lines which said:

> > If looks as if DNSSEC has expired:-
> 
> It seems it has been repaired around 1215 UTC.

https://twitter.com/ripencc/status/1719712189496311986

"Our services have been restored and all services are operational. We
believe the root cause of the issue was DNSSEC-related, and we are
continuing to monitor the situation. We will soon share a postmortem
on our status page: https://status.ripe.net;

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] anchors.atlas.ripe.net/ripe.net - DNSSEC bogus due expiration

[Stephane Bortzmeyer]

On Wed, Nov 01, 2023 at 11:13:15AM +,
 Matthew Richardson via dns-operations  wrote 
 a message of 64 lines which said:

> If looks as if DNSSEC has expired:-

It seems it has been repaired around 1215 UTC.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] TLD .ci DNSSEC-down

[Stephane Bortzmeyer]

On Mon, Oct 23, 2023 at 10:26:46AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 4 lines which said:

> .ci has a DS in the root but apparently no longer signs.
> 
> https://zonemaster.net/en/result/9d87233d252a8b60
> https://dnsviz.net/d/ci/ZTYEMQ/dnssec/

Now working again:

https://zonemaster.fr/fr/result/c57c27c1031b5e2c
https://dnsviz.net/d/ci/ZTZc9g/dnssec/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] xn--mgbai9azgqp6j broken

[Stephane Bortzmeyer]

On Thu, Oct 19, 2023 at 02:02:22PM +,
 Carr, Brett via dns-operations  wrote 
 a message of 265 lines which said:

> This may have been mentioned before as I think it has been broken for quite 
> some time but:
> 
> None of the delegated NS’s for xn--mgbai9azgqp6j (IDN for .pk) seem to be 
> responding to queries.
> 
> Anyone on list from .pk or who knows them?

It is indeed for a long time. I wrote to them, never a reply.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] TLD .ci DNSSEC-down

[Stephane Bortzmeyer]

.ci has a DS in the root but apparently no longer signs.

https://zonemaster.net/en/result/9d87233d252a8b60
https://dnsviz.net/d/ci/ZTYEMQ/dnssec/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Signature expired for the DS of .ch at Cloudflare ?

[Stephane Bortzmeyer]

On Wed, Oct 04, 2023 at 10:35:14AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 57 lines which said:

> Other instances of Cloudflare has the correct info:
> 
> % dig +cd +nsid @1.1.1.1 DS ch.

https://www.cloudflarestatus.com/

Investigating - Cloudflare is aware of, and investigating, DNS resolution 
issues which potentially impacts multiple users using 1.1.1.1 public resolver 
and/or WARP. 

Further detail will be provided as more information becomes available.
Oct 04, 2023 - 08:19 UTC

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Signature expired for the DS of .ch at Cloudflare ?

[Stephane Bortzmeyer]

Other instances of Cloudflare has the correct info:

% dig +cd +nsid @1.1.1.1 DS ch.

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> +cd +nsid @1.1.1.1 DS ch.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20816
;; flags: qr aa rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; NSID: 35 33 38 6d 31 37 38 ("538m178")
;; QUESTION SECTION:
;ch.IN DS

;; ANSWER SECTION:
ch. 86400 IN DS 10 13 2 (
0E175543A74D9083EA977BAB2BEE98A771995F80982F
B796B2B0B9CC6413D1A6 )
ch. 86400 IN RRSIG DS 8 1 86400 (
2023100405 2023092104 11019 .
U0PZSe2x3/R7P1+TKdnX9DSFxRtfvJIEdnI3q4MhSVuq
jX8HiqpU613EAyLF3s9IINPg+ctOSKWOzULMpZK+sbX9
NBzzRevhbHFziGNgqupscrxFKX7PGvRXKjmwfcfi7X4n
nvOlpsW0glNixT4M4vjdzO2bYDmgwzfwoosDy3r2W5e8
VKBn4lj75nqI/fgtLJQyi2pDHokZ5qRnzQ4/lsajwRsP
CnOgGnmtTyq3HRnI9cng5Lqv6yDHYacIk2Fpte6ehirN
oLwGaSwtWk7Tf1k/GpNKB3kpYb/e8VYVQ7c1ydwk7on7
tVn6hUaNlHpVbj8eFHXQYmRfvAl8+VAMBw== )

;; Query time: 8 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Oct 04 10:34:06 CEST 2023
;; MSG SIZE  rcvd: 377

% dig  +nsid @1.1.1.1 DS ch.

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> +nsid @1.1.1.1 DS ch.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52317
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 7 (Signature Expired): (failed to verify ch. DS: RRSIG ch., expiration = 
1696395600)
; NSID: 35 33 32 6d 33 33 ("532m33")
;; QUESTION SECTION:
;ch.IN DS

;; Query time: 8 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Wed Oct 04 10:34:50 CEST 2023
;; MSG SIZE  rcvd: 106
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] MaginotDNS: Attacking the boundary of DNS caching protection

[Stephane Bortzmeyer]

On Wed, Sep 27, 2023 at 05:17:05PM +0200,
 Petr Špaček  wrote 
 a message of 48 lines which said:

> If you are interested in the gory details, BIND's description of the issue
> can be found here:
> https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_241893
> https://gitlab.isc.org/isc-projects/bind9/-/issues/2950#note_244624

Thanks, these detailed discussions are much clearer than the paper,
which I find confusing (with its strange use of terms like "on-path").

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] MaginotDNS: Attacking the boundary of DNS caching protection

[Stephane Bortzmeyer]

I'm reading the paper behind "MaginotDNS: Attacking the boundary of
DNS caching protection"

.

Am I correct to think that forwarding from the CDNS to the upstream
resolver with DoT (DNS over TLS) would be sufficient to disable the
attack (even TCP or cookies would be enough if the attacker is
off-path)?

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Why is DNS still hard to learn?

[Stephane Bortzmeyer]

As usual, a good practical article by Julia Evans:

https://jvns.ca/blog/2023/07/28/why-is-dns-still-hard-to-learn/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] FYI: Google Public DNS now reports EDEs

[Stephane Bortzmeyer]

On Fri, Jul 21, 2023 at 05:29:10PM -0400,
 Viktor Dukhovni  wrote 
 a message of 17 lines which said:

> 
> https://developers.google.com/speed/public-dns/docs/troubleshooting/domains#edes

Note that, depending on your language setup, this page may redirect
you to a translation and not all the translations are up-to-date. For
instance, the french one does not mention EDE. To be sure to have the
last information, use:

https://developers.google.com/speed/public-dns/docs/troubleshooting/domains?hl=en#edes

And, yes, EDE works, which is great.

% dig @8.8.8.8 bogus.bortzmeyer.fr 

; <<>> DiG 9.18.16-1~deb12u1-Debian <<>> @8.8.8.8 bogus.bortzmeyer.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15089
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
; EDE: 10 (RRSIGs Missing): (For bogus.bortzmeyer.fr/soa)
;; QUESTION SECTION:
;bogus.bortzmeyer.fr.   IN A

;; Query time: 124 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Thu Jul 27 11:00:47 CEST 2023
;; MSG SIZE  rcvd: 81
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] FYI: Google Public DNS now reports EDEs

[Stephane Bortzmeyer]

On Fri, Jul 21, 2023 at 05:29:10PM -0400,
 Viktor Dukhovni  wrote 
 a message of 17 lines which said:

> Google Public DNS (also "dns.google", or, colloquially, "Quad8") now
> includes EDEs in most error responses.  For details see:
> 
> 
> https://developers.google.com/speed/public-dns/docs/troubleshooting/domains#edes

They also now support NSID which is great for debugging an anycast
service.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [DNSSEC] Venezuela ccTLD broken

[Stephane Bortzmeyer]

On Thu, Jul 20, 2023 at 07:25:17AM -0400,
 Hugo Salgado  wrote 
 a message of 148 lines which said:

> They are aware and working on this. Thanks!

It works now.

$ dig NS ve

; <<>> DiG 9.18.14 <<>> NS ve
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40942
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ve.IN  NS

;; ANSWER SECTION:
ve. 18000   IN  NS  ns3.nic.ve.
ve. 18000   IN  NS  ns4.nic.ve.
ve. 18000   IN  NS  a.lactld.org.
ve. 18000   IN  NS  ns5.nic.ve.
ve. 18000   IN  NS  ssdns-tld.nic.cl.
ve. 18000   IN  NS  ns6.nic.ve.

;; Query time: 780 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Thu Jul 20 12:54:31 UTC 2023
;; MSG SIZE  rcvd: 163


https://dnsviz.net/d/ve/ZLknmA/dnssec/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [DNSSEC] Venezuela ccTLD broken

[Stephane Bortzmeyer]

On Thu, Jul 20, 2023 at 09:37:10AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 6 lines which said:

> https://dnsviz.net/d/ve/ZLjinw/dnssec/
> 
> The DS goes to a key which does not sign (and there is no DS for the
> key which is actually signing.)

Any contact not in .ve to tell them? My email server uses a validating
resolver :-(
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] [DNSSEC] Venezuela ccTLD broken

[Stephane Bortzmeyer]

https://dnsviz.net/d/ve/ZLjinw/dnssec/

The DS goes to a key which does not sign (and there is no DS for the
key which is actually signing.)


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] service.gov.scot erroneous NXDOMAIN from "scot" auth servers

[Stephane Bortzmeyer]

On Tue, Jun 20, 2023 at 01:36:10PM +0200,
 CORE DNS Support Team  wrote 
 a message of 43 lines which said:

> since anycast9 is only responsible for scot and not for gov.scot, I
> believe the desired answer is a delegation to the name servers of
> gov.scot, and not, as you wrote, a "NODATA" response

No, Viktor is right, and a NODATA (the correct answer) is indeed what
the servers return for other query types:


% dig @anycast23.irondns.net. A service.gov.scot

; <<>> DiG 9.18.12-1-Debian <<>> @anycast23.irondns.net. A service.gov.scot
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30666
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;service.gov.scot.  IN  A

;; AUTHORITY SECTION:
gov.scot.   86400   IN  NS  ns0.ja.net.
gov.scot.   86400   IN  NS  ns4.ja.net.
gov.scot.   86400   IN  NS  ns2.ja.net.
gov.scot.   86400   IN  NS  ns3.ja.net.

;; Query time: 8 msec
;; SERVER: 2a01:5b0:5::b#53(anycast23.irondns.net.) (UDP)
;; WHEN: Tue Jun 20 14:43:54 CEST 2023
;; MSG SIZE  rcvd: 123
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .GL (Greenland) 2LD DS denial of existence problems

[Stephane Bortzmeyer]

On Mon, Jun 19, 2023 at 10:23:13PM -0400,
 Viktor Dukhovni  wrote 
 a message of 66 lines which said:

> The .GL TLD returns bogus NXDOMAIN responses to DS queries for:

But it replies properly for NSEC3PARAM :-)

% dig +dnssec @d.nic.gl NSEC3PARAM com.gl

; <<>> DiG 9.18.12-1-Debian <<>> +dnssec @d.nic.gl NSEC3PARAM com.gl
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55173
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 734ffb7abf3db0bf51ad1f92649173941779bd5c41101e6d (good)
;; QUESTION SECTION:
;com.gl.IN  NSEC3PARAM

;; ANSWER SECTION:
com.gl. 0   IN  NSEC3PARAM 1 0 10 788F7E66
com.gl. 0   IN  RRSIG   NSEC3PARAM 8 2 0 2023070514 
2023061814 36840 com.gl. 
GhwPL1HdLpQFd0TYzqsa79AgDyAcZMOKK63LVPZK0TjrcT8ffaKo4ZYU 
6a0Pv0yifl07xPNMmxSb4EHodk9TYoOG4BAX624zTs8fhfkdjzvhh64T 
WSieZsXvEQ5Z8yizzutL3Tp3kST2nYDCXnILpNSEiS/OIh28J7iQgJf1 
JP65lKuoiPtYNVCqf4UjiGbPn3/ar9WijMB91tdqjBbOZIRvsFxSXfb6 
VrQ8Fz82a8BA3h1QqeaH1KvyOz5wRHX4p7Qh3eYti7E1Zcp98lLDmOnx 
ZSo55voqtxCZxm/sxLWMdPCEZbyZEzU1Co6953V/jFvFZeYkZNWxhf1/ mbIclQ==

;; Query time: 0 msec
;; SERVER: 2001:500:14:6049:ad::1#53(d.nic.gl) (UDP)
;; WHEN: Tue Jun 20 11:38:28 CEST 2023
;; MSG SIZE  rcvd: 378
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Percentage of DoT/DoH requests for public resolvers?

[Stephane Bortzmeyer]

Hello,

I'm looking for the current percentage of encrypted DNS requests
vs. in-the-clear ones on public resolvers having DoT/DoH/DoQ. I do not
find public information about it. May be I searched too fast?

If you work for a public DNS resolver, is there data you can share? If
you can/want/prefer to reply privately and ask me not to mention the
name of the resolver, that's OK, too.


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Query regarding my paid domain communityclinic.ga form freenom

[Stephane Bortzmeyer]

On Mon, Jun 05, 2023 at 02:46:35PM +0100,
 Mark Rousell  wrote 
 a message of 223 lines which said:

> It is not clear to me what will become of all of the registered .ga domains
> after the registry switch over.

It is perfectly clear:

"ANINF estimates that there are currently over 7 million domain names
in stock in the .ga name base. However, independent bodies consider
that there is widespread technical abuse on ‘.ga’ domain names. As
part of this switch-over operation, several million domain names will
be deleted as the previous operator has not provided the data that
concern them."

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Query regarding my paid domain communityclinic.ga form freenom

[Stephane Bortzmeyer]

On Mon, Jun 05, 2023 at 06:40:01PM +0530,
 Amit Singh  wrote 
 a message of 157 lines which said:

> I raised a ticket with freenom today but they did not provide a
> single reply in that matter. I also opened an issue with
> google. They pointed me at this list for updates by stating that now
> gibbon will take over this TLD.

I don't know what or who is "gibbon". But the TLD is managed by ANINF
.

> I also see that 6 june is the date of change. But the domain stopped
> working at all from 4 june.

Yes, it was done a bit in advance.

> I don't see any further guide or way to reach the right team to look
> into the matter and help to resolve the issue.

https://mon.ga/english.html
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Important change for the .ga TLD 6th june 2023

[Stephane Bortzmeyer]

On Fri, Jun 02, 2023 at 09:28:24AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 56 lines which said:

> The .ga TLD will change its mode of operation on 6th june 2023. The majority
> of domain names, registered under disputable conditions, will be removed. Do
> not be surprised if many domains will yield NXDOMAIN.

Done in advance, this night (gabonese time).

% check-soa -i ga
d.nic.fr.
2001:678:c::1: OK: 222414 (6 ms)
194.0.9.1: OK: 222414 (14 ms)
f.ext.nic.fr.
2001:67c:1010:11::53: OK: 222414 (17 ms)
194.146.106.46: OK: 222414 (19 ms)
g.ext.nic.fr.
2001:678:4c::1: OK: 222414 (5 ms)
194.0.36.1: OK: 222414 (5 ms)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Important change for the .ga TLD 6th june 2023

[Stephane Bortzmeyer]

On Fri, Jun 02, 2023 at 11:03:19AM +0300,
 Frank Habicht  wrote 
 a message of 33 lines which said:

> I'm not involved at all, but wondering:
> no webpage for registrants to check whether their domain will 'survive'?

The way I see it (disclaimer: I don't work for ANINF), if you
registered through a registrar, you're probably safe (check the list
of registrars in , and check with your
registrar), if you registered directly from Freenom, you're probably
not safe (Freenom did not send the data to the registry).


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Important change for the .ga TLD 6th june 2023

[Stephane Bortzmeyer]

The .ga TLD will change its mode of operation on 6th june 2023. The majority
of domain names, registered under disputable conditions, will be removed. Do
not be surprised if many domains will yield NXDOMAIN.

https://mon.ga/english.html

See the details in the press release:

https://www.afnic.fr/wp-media/uploads/2023/05/ga-domain-names-soon-to-return-to-Gabonese-management-1.pdf



signature.asc
Description: PGP signature
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Looking for zones using white lies (RFC 4470)

[Stephane Bortzmeyer]

On Fri, Jan 27, 2023 at 12:19:18AM -0500,
 Viktor Dukhovni  wrote 
 a message of 30 lines which said:

> Three sample zones:

They all seem to use black lies, not white lies.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Looking for zones using white lies (RFC 4470)

[Stephane Bortzmeyer]

I'm looking for zones in the wild that are signed using the technique
of white lies (RFC 4470).

[Not the black lies used by Cloudflare.]

Do you know some?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] What's going on at Microsoft?

[Stephane Bortzmeyer]

On Fri, Oct 21, 2022 at 08:49:16AM +0200,
 Borja Marcos  wrote 
 a message of 41 lines which said:

> Right now I have quite a lot of pollution on my recursive error logs due to 
> two Microsoft operated domains:
> 
> microsoftdnstest.net
> msedge.net

For microsoftdnstest.net, the two name servers do reply but they reply
SERVFAIL (and, unfortunately, without EDE).

msedge.net works fine for me. (But of course, names like
t-ring-fallback.msedge.net which redirect to microsoftdnstest.net are
not useful.)

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] ENT NXDOMAIN problem at .BS nameserver ns36.cdns.net

[Stephane Bortzmeyer]

On Tue, Sep 27, 2022 at 02:20:11PM +,
 BS Domain Administrator  wrote 
 a message of 229 lines which said:

> Please test again and let us know if the problem still occurs.

This specific problem disappeared but there are other funny things in
the zone. For instance, the three authoritative name servers for .bs
claim that com.bs has three name servers, but they are the same.

% dig @anyns.dns.bs. SOA com.bs  

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @anyns.dns.bs. SOA com.bs
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32202
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: b6dd75980a42dca4e88a412663335275aec889b7585d3e59 (good)
;; QUESTION SECTION:
;com.bs.IN SOA

;; AUTHORITY SECTION:
COM.bs. 21600 IN NS anyns.dns.bs.
COM.bs. 21600 IN NS ns36.cdns.net.
COM.bs. 21600 IN NS anyns.pch.net.

;; Query time: 16 msec
;; SERVER: 2001:500:14:6068:ad::1#53(anyns.dns.bs.) (UDP)
;; WHEN: Tue Sep 27 21:43:49 CEST 2022
;; MSG SIZE  rcvd: 147
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] ENT NXDOMAIN problem at .BS nameserver ns36.cdns.net

[Stephane Bortzmeyer]

On Thu, Sep 22, 2022 at 02:12:43PM +,
 BS Domain Technical Contact  wrote 
 a message of 64 lines which said:

> Please provide an update regarding the same. Thanks.

Which update? Nothing changed.

% dig @ns36.cdns.net com.bs

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> @ns36.cdns.net com.bs
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46699
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;com.bs.IN A

;; AUTHORITY SECTION:
bs. 9000 IN SOA dns.nic.bs. bsadmin.cob.edu.bs. (
2022092000 ; serial
3600   ; refresh (1 hour)
900; retry (15 minutes)
1814400; expire (3 weeks)
9000   ; minimum (2 hours 30 minutes)
)

;; Query time: 12 msec
;; SERVER: 2001:678:4::24#53(ns36.cdns.net) (UDP)
;; WHEN: Fri Sep 23 09:27:04 CEST 2022
;; MSG SIZE  rcvd: 101
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] ICANN Launches the KINDNS Initiative to Promote DNS Security Best Practices

[Stephane Bortzmeyer]

[I don't have a strong opinion about this project, but it seems
relevant and I don't think it has been forwarded here.]

The Internet Corporation for Assigned Names and Numbers (ICANN)
invites you to participate in the "Knowledge-sharing and Instantiation
Norms for DNS and Naming Security" (KINDNS) initiative. This
initiative promotes Domain Name System (DNS) operational security best
practices and encourages DNS operators to voluntarily commit to their
implementation.

https://www.icann.org/en/announcements/details/icann-launches-the-kindns-initiative-to-promote-dns-security-best-practices-06-09-2022-en


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Browser Public suffixes list

[Stephane Bortzmeyer]

On Fri, Aug 26, 2022 at 10:25:49PM +,
 Paul Hoffman  wrote 
 a message of 100 lines which said:

> There's also, you know, the DNS itself

Speaking of DNS, it is time to remind readers that there was a
project to express information such as "is it a public suffix?" in
the DNS and it failed:

https://mailarchive.ietf.org/arch/msg/dbound/F9SkNAZmYHGKlRwbn5Il78pOkFs/
https://datatracker.ietf.org/wg/dbound/about
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] mail.protection.outlook.com has EDNS issues

[Stephane Bortzmeyer]

The authoritative name servers for mail.protection.outlook.com
apparently don't reply if you use EDNS. And it seems many resolvers
don't fallback on old-DNS (and rightly so). Seen from the RIPE Atlas
probes, many resolvers cannot resolve names under
mail.protection.outlook.com (here, the MX of cybercampus.fr):

% blaeu-resolve --type A -r 500 campuscyber-fr.mail.protection.outlook.com
[104.47.24.36 104.47.25.36] : 298 occurrences 
[ERROR: SERVFAIL] : 138 occurrences 
[] : 2 occurrences 
Test #4162 done at 2022-07-06T09:25:50Z

% dig @ns1-proddns.glbdns.o365filtering.com. NS  mail.protection.outlook.com

; <<>> DiG 9.16.1-Ubuntu <<>> @ns1-proddns.glbdns.o365filtering.com. NS 
mail.protection.outlook.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 64702
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; WARNING: EDNS query returned status FORMERR - retry with '+nodnssec +noedns'

;; Query time: 43 msec
;; SERVER: 104.47.16.17#53(104.47.16.17)
;; WHEN: mer. juil. 06 11:22:28 CEST 2022
;; MSG SIZE  rcvd: 12

~ % dig +nodnssec +noedns +bufsize=0 +nocookie 
@ns1-proddns.glbdns.o365filtering.com. NS  mail.protection.outlook.com

; <<>> DiG 9.16.1-Ubuntu <<>> +nodnssec +noedns +bufsize +nocookie 
@ns1-proddns.glbdns.o365filtering.com. NS mail.protection.outlook.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52148
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;mail.protection.outlook.com. INNS

;; ANSWER SECTION:
mail.protection.outlook.com. 10 IN NS ns1-proddns.glbdns.o365filtering.com.
mail.protection.outlook.com. 10 IN NS ns2-proddns.glbdns.o365filtering.com.

;; Query time: 47 msec
;; SERVER: 104.47.16.17#53(104.47.16.17)
;; WHEN: mer. juil. 06 11:22:50 CEST 2022
;; MSG SIZE  rcvd: 199
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Program/library/framework for testing robustness of servers

[Stephane Bortzmeyer]

I maintain an experimental authoritative DNS server and I would like
to test its robustness. dnsperf and flamethrower are great to test its
performance, zonemaster and dnsviz are perfect to test its correctness
in face of legal input but I would like to see how it reacts to
*illegal*, malformed input. (An example of such input is
.)

Since most DNS libraries are made to prevent the programmer for
issuing illegal DNS requests, it is not obvious to write such a test.

Are you aware of libraries / programs / frameworks to exercice, in a
hard way, the robustness of a server?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] DNS request for ./NS with two extra bytes at the end

[Stephane Bortzmeyer]

[This has no operational consequences, it is just idle curiosity.]

A server receives a few packets/second coming from several IP
addresses and querying ./NS (like in priming, or may be in some
reflection attacks). The server was never a root server, of course.

What is interesting is that all these packets have two extra bytes at
the end, after the class. The UDP length is correct, but the DNS
content is not. I don't show you the output of tshark, because it
ignores these extra bytes (but you can see them with Wireshark or
other tools). I attached a small pcap.

The source IP addresses (which may be spoofed) are all registered in
China.

Did anyone see these requests?

Side question: what should the receiver do? tshark, as I said, drops
these extra bytes, Wireshark flags no error (but displays the
bytes). I did not test them with various DNS servers to see how they
react. Ignoring the extra bytes in the name of the robustness
principle? Instead, at least one DNS library rejects the packet as
malformed.



extra-bytes.pcap
Description: application/vnd.tcpdump.pcap
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .au DNSSEC issues

[Stephane Bortzmeyer]

On Mon, Mar 28, 2022 at 08:56:39AM +,
 Brett Carr  wrote 
 a message of 131 lines which said:

> This seems to of gone undiscussed on here which is unusual.

It was discussed on australian mailing lists:

https://lists.ausnog.net/pipermail/ausnog/2022-March/thread.html
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Running the ua.-top level domain in times of war

[Stephane Bortzmeyer]

Interestng interview:

https://www.heise.de/hintergrund/Running-the-ua-top-level-domain-in-times-of-war-6611777.html

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] TLD .fj broken (DNSSEC issue)

[Stephane Bortzmeyer]

Entire TLD down since the DS goes to an unexisting key
.

% dig @a.root-servers.net fj ds


; <<>> DiG 9.16.22-Debian <<>> @a.root-servers.net fj ds
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21820
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;fj.IN DS

;; ANSWER SECTION:
fj. 86400 IN DS 18952 8 2 (
B22F5938AD822A76499A3AC295E061CC07FCE36D7956
E26A4F51AEDE1717F993 )
fj. 86400 IN RRSIG DS 8 1 86400 (
2022032105 2022030804 9799 .
GV9jHAYa1/THxNVXY8xfd9KpkgfWJH9etKm6d13p95Dp
DI/i8q8gDCYHK3s7+QkQWmwnuhyIajYXbJGpwjpIZFJJ
dUlL6kJyApAbx8p+XvnMRE8IiI7HwjE+SReu4iOVhuXy
sBEDGvdwHjENYes8g7S909FefLFCaBfZ8WVWVBWOOQNY
ueERcBFn6kAUSM8Es5xzt7B0UnivO+dWX6NSXxzVPxTW
8hTsWXoyLle6Qkxti2+4zQJS/UlQYYeSUZbj/bGTlV/j
8z7GdoFngXNwyZXrGxmdqxSvzFUh9/38Idn0xC1HAvFW
4jhDCS1WV9NPiBs0Wx/VG8yMM0KGXbi+Fg== )

;; Query time: 12 msec
;; SERVER: 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30)
;; WHEN: Tue Mar 08 10:22:09 CET 2022
;; MSG SIZE  rcvd: 366

But:

% dig @144.120.146.1 fj dnskey

; <<>> DiG 9.16.22-Debian <<>> @144.120.146.1 fj dnskey
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53588
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 2c82e96a472de66f47f4f4ee62272071a682d2e21408 (good)
;; QUESTION SECTION:
;fj.IN DNSKEY

;; ANSWER SECTION:
fj. 3600 IN DNSKEY 256 3 8 (
AwEAAdpT6o6ustm4WxYhP8Xa6P1+1dvYExn1LyOC9qUX
dbt3BWPok+obi69yRywGD740Aj6AO7To2HXDlLF3YF5c
R1mO5mo6iSTHqNAg4rjE49/BVxjV3KgmEOGFdtiMbAi+
4d6KMPkl+HULwmJkdcu8gkG9cYjBkJ2OUpfvsjaZ47/a
zk+d8ffEd0oN/0dC9lhcaeYOvhJehdGHFemKY3Mk5O1F
Zrww9OF3SOBSrW+C6LPk04/mTji7j6OeIDfFIMvuu0oN
OAqxTlwUuoTeIiHmJZ0jNlKgBgmsTmlRETAEjcDqcGha
wiENI65uRYbx2eRv5k2U5If0ydhMxBLYAcqFEHE=
) ; ZSK; alg = RSASHA256 ; key id = 24459
fj. 3600 IN DNSKEY 257 3 8 (
AwEAAchm/6TsZVKXuzGe+5Kx/7PW2j1jMkctAL+FaWn+
LW28Kzr4KI9XQz2bd1byWdsljsKkW1zMiiLBlxHcmUiK
vv8hIPLwdxwEdutCve9arJNfDyDhCf5SCHenzQwaR3pQ
zQ+QzaTVPQKz9VIfV6u06wGqq4iTo014N2ITs2EtYU0T
bydZ/cOuy2+N5xE1Xi6JrJuwPKSQfi3M3Ojb3SA4EK6f
BaiGM2Ri1DN6OD+5A8Z9R4EihqAtPtkjJI8mqAbmXu+d
krMJVljtaCMlt2tejaqzqfwd4FJQEdFRiEdMwB3sYjsH
+cMn3QJlvlSXm/w174e5Wzvk563TvuPOrLzefQU=
) ; KSK; alg = RSASHA256 ; key id = 12931
fj. 3600 IN RRSIG DNSKEY 8 1 3600 (
20220321164811 20220307230005 12931 fj.
uRN6QJdTyElu51Xzz30KDF8efDUL+RrZwjy4YyPX2YKv
fLJ5ugQm2jA/Js3UteScHJOEzBobYLnWI/jKYqi6/EVX
78KCaqDMZwnkDOVn6FKRUM+oK/FPWFCPWAUQQ6pVWqY3
OiU/GA5yW6f5oD0yyt3K0HIpAnC86lAftGyhHSoeDm4D
EF+yJPJtB07z2/dyIthg8Gtzo9/24yEAgWjhFPa/DNWv
K7jw2/alPUBFMNTIWGba918PJRgJg8G6HQQ4xWqr4xV/
O7gPRk+Wh8/YlfrGdfWoBTax2VMvQGhrBmqTqxwKwaEC
+gpwGasOMSF5g/DujuHSQ0NK7+L67m+wHA== )

;; Query time: 320 msec
;; SERVER: 144.120.146.1#53(144.120.146.1)
;; WHEN: Tue Mar 08 10:22:57 CET 2022
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] [outa...@outages.org: [outages] DNSSEC issues .se]

[Stephane Bortzmeyer]

Indeed, DNSviz seems to confirm the problem:

https://dnsviz.net/d/sportbladet.se/Yf1XbQ/dnssec/

The signature of the NSEC record looks strange to me:

% dig @a.ns.se. +dnssec A sportbladet.se

; <<>> DiG 9.16.1-Ubuntu <<>> @a.ns.se. +dnssec A sportbladet.se
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60924
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 0048c3eb59d11c2b010061fd58dcdecd7e08e6619bd5 (good)
;; QUESTION SECTION:
;sportbladet.se.IN A

;; AUTHORITY SECTION:
sportbladet.se. 86400 IN NS dns02.ports.se.
sportbladet.se. 86400 IN NS dns03.ports.se.
sportbladet.se. 86400 IN NS dns04.ports.net.
sportbladet.se. 86400 IN NS dns01.dipcon.com.
sportbladet.se. 7200 IN NSEC sportbladet-tv.se. NS RRSIG NSEC
sportbladet.se. 7200 IN RRSIG NSEC 8 2 7200 (
20220217023427 20220204111055 30015 se.
AAH/





ADAxMA0GCWCGSAFlAwQCAQUABCDDlM45/p82
gs9EuWI0BODTVEgrkVM5ZrtG98oLVgefGQ== )

;; ADDITIONAL SECTION:
dns03.ports.se. 86400 IN  2a04:3540:1000:310:287e:f6ff:fe1d:4789
dns02.ports.se. 86400 IN  2001:19f0:5001:2a:5400:ff:fe38:1e6f
dns03.ports.se. 86400 IN A 94.237.33.102
dns02.ports.se. 86400 IN A 45.63.42.179

;; Query time: 39 msec
;; SERVER: 2a01:3f0:0:301::53#53(2a01:3f0:0:301::53)
;; WHEN: ven. févr. 04 17:48:28 CET 2022
;; MSG SIZE  rcvd: 595
--- Begin Message ---



Anyone else seeing dnssec issues on unsigned .se domains?
Apparently, if a unsigned domain is followed by a signed domain in the .se zone - the domain wont resolve due to NSEC errors.




Example:
Sportbladet.se
Kgkfastigheter.se
Deltacity.se



Med vänlig hälsning / Best Regards​Jonathan SéleaLinux Technician+46 70 726 00 50jonathan.se...@portsgroup.comGöteborg, Kungsgatan 42The General Terms applicable to our services are available on our website, here. Please refer to our Privacy Policy for information about how we process personal data. This e-mail may contain legally privileged and confidential information. If you are not the intended addressee, you are hereby notified that any reading, distribution, copying or other use of this message or attachments is strictly prohibited. If you have received this message in error, return to us and delete this email. Thank you.

___
Outages mailing list
outa...@outages.org
https://puck.nether.net/mailman/listinfo/outages
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Freenom TLDs not working through Google Public DNS

[Stephane Bortzmeyer]

I did not investigate yet but it may be fun:

https://issuetracker.google.com/issues?q=.ml=1
___
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?

[Stephane Bortzmeyer]

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.

% dig @j.root-servers.net NS arpa


; <<>> DiG 9.17.20-3-Debian <<>> @j.root-servers.net NS arpa
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31618
;; flags: qr aa rd; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1
 ^^
 :-)


;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1472
;; QUESTION SECTION:
;arpa.  IN  NS

;; ANSWER 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: 3 msec
;; SERVER: 192.58.128.30#53(j.root-servers.net) (UDP)
;; WHEN: Sun Dec 05 17:18:44 UTC 2021
;; MSG SIZE  rcvd: 241

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNSviz and G-root: EDNS issue?

[Stephane Bortzmeyer]

On Tue, Oct 12, 2021 at 01:01:08PM -0400,
 Matthew Pounsett  wrote 
 a message of 11 lines which said:

> > This might be a known intermittent IPv6 routing issue with DNSviz, do
> > you see this problem for v4 and/or v6 ?
> 
> That would show up as a non-answer over IPv6, rather than an apparent
> PMTU/EDNS problem.

DNSviz (and similar tools) may wrongly diagnose a PMTU problem if
there are random losses.

1) Try with bufsize=4096. No answer, because of a random packet loss.
2) Retry with bufsize=1024. Answer received, therefore it must be a
   PMTU problem.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNSviz and G-root: EDNS issue?

[Stephane Bortzmeyer]

On Tue, Oct 12, 2021 at 11:21:44AM -0400,
 Keith Mitchell  wrote 
 a message of 22 lines which said:

> > (192.112.36.4, UDP_-_EDNS0_4096_D_KN)".
> > 
> > Testing G-root/192.112.36.4

> This might be a known intermittent IPv6 routing issue with DNSviz, do you
> see this problem for v4 and/or v6 ?

v4
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] DNSviz and G-root: EDNS issue?

[Stephane Bortzmeyer]

DNSviz currently always flags the root with a warning "./DNSKEY (alg
8, id 14748): No response was received until the UDP payload size was
decreased, indicating that the server might be attempting to send a
payload that exceeds the path maximum transmission unit (PMTU)
size. (192.112.36.4, UDP_-_EDNS0_4096_D_KN)".

Testing G-root/192.112.36.4 with the RIPE Atlas probes, bit DO and
bufsize=4096 shows no evidence of a problem (and the answer is well
below 4096 bytes). It seems it affects only the path between G-root
and DNSviz.

Any idea?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Fwd: .club TLD appears to be completely down]

[Stephane Bortzmeyer]

On Thu, Oct 07, 2021 at 03:57:33PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 17 lines which said:

> Most RIPE Atlas probes use a resolver which now sees .club (there was 99
> % SERVFAIL before) :

It seems it works everywhere now.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Fwd: .club TLD appears to be completely down]

[Stephane Bortzmeyer]

On Thu, Oct 07, 2021 at 03:32:45PM +0200,
 Peter van Dijk  wrote 
 a message of 27 lines which said:

> None of those 'some' appear to be in Amsterdam :-) Still nothing for
> me.

Most RIPE Atlas probes use a resolver which now sees .club (there was 99
% SERVFAIL before) :

% blaeu-resolve --type SOA -r 100 club
[ns1.dns.nic.club. admin.tldns.godaddy. 1633613754 1800 300 604800 1800] : 81 
occurrences 
[ERROR: SERVFAIL] : 12 occurrences 
[] : 1 occurrences 
[ns1.dns.nic.club. admin.tldns.godaddy. 1633613239 1800 300 604800 1800] : 1 
occurrences 
[ns1.dns.nic.club. admin.tldns.godaddy. 1633613505 1800 300 604800 1800] : 3 
occurrences 
Test #32446552 done at 2021-10-07T13:44:00Z
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] [Fwd: .club TLD appears to be completely down]

[Stephane Bortzmeyer]

On Thu, Oct 07, 2021 at 01:54:18PM +0200,
 Peter van Dijk  wrote 
 a message of 16 lines which said:

> https://www.namecheap.com/status-updates/archives/63707
> 
> Update @ 7:45 AM EDT | 11:45 UTC
> We have received an update from the registry. They are working to
> resolve the issue within the nearest time possible. Thank you for your
> patience and understanding.

It seems it works again (at least for some of their auth. name
servers).
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Akamai outages possibly related to Edge DNS?

[Stephane Bortzmeyer]

On Thu, Jul 22, 2021 at 09:53:25AM -0700,
 Mauricio Vergara Ereche  wrote 
 a message of 90 lines which said:

> Seeing several reports of sites going down
> 
> Some people blaming AWS, others Akamai Edge DNS

Clearly Akamai Edge. They acknowledged it on their status site "a
software configuration update triggered a bug in the DNS system, the
system that directs browsers to websites. This caused a disruption
impacting availability of some customer websites."

As usual on the modern Web, where every page depends on several remote
things, it created cascading problems, leading to erroneous
diagnostics about the real root of the problem.

The authoritative name servers for Akamai Edge returned SERVFAIL
during the problem:

https://pbs.twimg.com/media/E66ejnmXsAYDSEZ?format=png=small



___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Name:Wreck vulnerability

[Stephane Bortzmeyer]

Time for a new vunerability-with-a-catchy-name. Name:Wreck is a bug in
some implementations of DNS clients when dereferencing compression
pointers, in some cases leading to remote code execution when parsing
a malicious packet.

https://www.forescout.com/company/resources/namewreck-breaking-and-fixing-dns-implementations


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Spurious (?) DNSSEC SERVFAIL with some (?) versions of BIND for one domain?

[Stephane Bortzmeyer]

Some resolvers cannot resolve the DMARC record _dmarc.prv.se/TXT. They
reply SERVFAIL (the correct answer is NXDOMAIN). Running with checking
disabled solves the problem.

I see nothing that explains this problem. Zonemaster and DNSviz do not
see it either.

RIPE Atlas probes show that some probes' resolvers have the problem:

% blaeu-resolve -r 100 --displayvalidation  --type TXT _dmarc.prv.se
[ERROR: NXDOMAIN] : 86 occurrences
[ERROR: SERVFAIL] : 12 occurrences
Test #29281287 done at 2021-03-10T14:28:09Z

It seems limited to some (?) versions of BIND. All the other resolvers
I tested are fine. Here, with BIND:


; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> @192.168.1.1 TXT _dmarc.prv.se
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 22448
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: a5d317b0ecd877372d40f20b6048d7eeb17f96fd42e1cd5b (good)
;; QUESTION SECTION:
;_dmarc.prv.se. IN TXT

;; Query time: 36 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Mar 10 15:30:06 CET 2021
;; MSG SIZE  rcvd: 70




; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +cd @192.168.1.1 TXT _dmarc.prv.se
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5521
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: a202795cfd0e59e942562a706048d7f38ae88ad6b4988c85 (good)
;; QUESTION SECTION:
;_dmarc.prv.se. IN TXT

;; AUTHORITY SECTION:
prv.se. 3243 IN SOA dns1.prv.se. postmaster. (
2020111898 ; serial
1200   ; refresh (20 minutes)
600; retry (10 minutes)
1209600; expire (2 weeks)
3600   ; minimum (1 hour)
)
prv.se. 3243 IN RRSIG SOA 8 2 3600 (
20210320003042 20210309233042 16321 prv.se.
VwPp3euu60s7lEGw7uliB8Ktf9UeLEMufsLVoalKCZ8G
i6Y5SL6u045fT2S//XpNwFZoFaJER1JtlOo5s97utv9k
gi2PFNWQ6VtfcMpYLcuvwuQ0xdwBUWBnmit7n0diZRzB
1KMSvzs7ur/+KBeGNcqqd4D2pjvxwYIHadDoQLY= )
9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se. 3243 IN RRSIG NSEC3 8 3 3600 (
20210320003042 20210309233042 16321 prv.se.
ESiImHBFB3n+cS/bm/5FFE4KiB1pZ3norVyytnXdd4pv
LrtnJyhXcdgipneyozq2+0c1iwzaLUzLFKnC8yeIjvXB
pB6JQwFXYNOQXjnZOB30nX/PU3hfrgGuODJrjargXkCl
69sUaYMwK+uW2J3NAofjFOMizAK7by1bWCe9b3Q= )
9qbq9dd8lt1gvge9gdmb5m0o13iuqeqt.prv.se. 3243 IN NSEC3 1 0 50 33E9285AB62C0803 (
9U28UGFJH153VH0IT0GU0CEDR2SQ93MA
A NS SOA MX TXT DS RRSIG DNSKEY NSEC3PARAM )
hup1us667e5fsc26ltim32tpkio8r12b.prv.se. 3243 IN RRSIG NSEC3 8 3 3600 (
20210320003042 20210309233042 16321 prv.se.
N/aPN5MuDY04vnfAU2SG/1ISeEcIAnpd6F6ufX4uwMrx
J/R/FP+fzp0mn3zuseu124aMFBzX8SG9rRDt1keVmCaH
9rqooFuPZvbCr2WKmTi9OAWIzJSOzVcfimNnrNNU0J5C
By7dkt0umlzoKt73S9M0dVdjkoSUwxsyt9kYtos= )
hup1us667e5fsc26ltim32tpkio8r12b.prv.se. 3243 IN NSEC3 1 0 50 33E9285AB62C0803 (
J20QA6CUD21FG9V4A6P6IEFNOURK87JC
CNAME RRSIG )
lh8nso9jvk3fcgelcakjp266mb0vctj5.prv.se. 3243 IN RRSIG NSEC3 8 3 3600 (
20210320003042 20210309233042 16321 prv.se.
D04hQjopnJoQJB3mPU+2fiECQcWdGDKpADFdbYF0SvYK
B2WbMgOdHV3aOTSnkNnWX0QDTyarJ8JWpIQnq1wfaAbD
n7AlF3eOWYWNolClRIchvY4dIBwBbYVHLRQ6f/Hul1ww
D17xe6SmUOaLGyYNlLrXSuYHHRAeGY/XwZLNTlc= )
lh8nso9jvk3fcgelcakjp266mb0vctj5.prv.se. 3243 IN NSEC3 1 0 50 33E9285AB62C0803 (
Q16A55QV24JJ8VKLC4U0DU1HGBA0QCM7
A RRSIG )

;; Query time: 3 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Mar 10 15:30:11 CET 2021
;; MSG SIZE  rcvd: 1047


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] dnspooq

[Stephane Bortzmeyer]

On Tue, Jan 19, 2021 at 03:53:04PM +,
 Roy Arends  wrote 
 a message of 7 lines which said:

> fyi
> 
> https://www.jsof-tech.com/disclosures/dnspooq/

Real vulnerabilities and good technical work but why do they feel the
need to add references to the "Internet DNS Architecture" (it is not a
DNS problem, purely bugs in an implementation) or to HSTS (what's its
relationship with a bug in a DNS program?)?

To get more attention?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Google DNS hiccups (Toronto, Canada?)

[Stephane Bortzmeyer]

On Fri, Jan 08, 2021 at 10:43:30AM -0500,
 David Magda  wrote 
 a message of 19 lines which said:

> Is anyone experiencing timeouts and hangs with Google DNS?

It is discussed on the outages mailing list. I quote a Google employee:

Google is aware this has recurred over the last 3 days and we are
digging
into it.

If you happen to have crisper start-stop times than ~09:20-09:50 EST
for
any of the last three days, that might well help us narrow it down.
Thanks to those who have come via n...@google.com (our master ticket:
b/176930179).

Phil Sykes
(day job: Google Networking SRE)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] .ag outage

[Stephane Bortzmeyer]

On Fri, Nov 27, 2020 at 12:09:08PM +0100,
 Thomas Mieslinger  wrote 
 a message of 28 lines which said:

> I received customer complaints that quad8 and some german broadband
> resolvers were unable to resolve .ag secondlevel domains.

It works for me:

% dig @8.8.8.8 peak.ag

; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> @8.8.8.8 peak.ag
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16172
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;peak.ag.   IN A

;; ANSWER SECTION:
peak.ag.3599 IN A 153.92.198.115

;; Query time: 17 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Nov 27 13:46:06 CET 2020
;; MSG SIZE  rcvd: 52


RIPE Atlas probes in Germany see no issue either.

% blaeu-resolve -r 100 --country DE --type A peak.ag
[153.92.198.115] : 96 occurrences
[ (TRUNCATED - May have to use --ednssize)  153.92.198.115] : 2 occurrences
Test #28290912 done at 2020-11-27T12:47:10Z

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] How DNS work

[Stephane Bortzmeyer]

On Mon, Nov 09, 2020 at 03:34:32PM +,
 Jim Reid  wrote 
 a message of 60 lines which said:

> A well behaved resolving server will only send a handful of queries
> (if that) to the root every day - ie whenever it needs to lookup a
> TLD that hasn’t been cached.

And may be not even so, if they implement RFC 8198, or RFC 8806.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] How DNS work

[Stephane Bortzmeyer]

On Mon, Nov 09, 2020 at 11:15:12AM +0700,
 Hoan Vu  wrote 
 a message of 122 lines which said:

> And we have already do lab, and then the DNS Cache work out of
> order, the DNS Root is choiced rondomly.

As explained in the APNIC article, it depends on the resolver. BIND,
Knot, Unbound and the others do not use the same algorithm.

> the nature of the rule to choose the DNS Root of Resolver, what
> factor, algorithm, 

Sometimes, it is more or less documented, but you'll probably have to
read the source code and, as you did, experiment in the lab to find out.

> Our final taget to want to know can we control the operation of the
> DNS Cache. Suppose that we have one Root Secondary Node of Anycast
> in our country (example DNS Root K), and we want to direct query of
> the DNS Cache to the that DNS Root, how can we interfere the resolve
> process to do that

Well, if it is free software (like PowerDNS, Unbound, BIND, etc), you
have to modify the source code (not for the faint of heart).

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] QTYPEs 65 and 65479

[Stephane Bortzmeyer]

On Wed, Sep 16, 2020 at 10:44:00AM +0100,
 Roy Arends  wrote 
 a message of 128 lines which said:

> More info:
> 
> https://mailarchive.ietf.org/arch/msg/add/MbOOWPVHRHM_wvbKhfHuzUTwimI/ 
> 

And a good Cloudflare paper


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] CLI Tool for DoH

[Stephane Bortzmeyer]

On Tue, Sep 29, 2020 at 11:37:29AM +0200,
 Jeroen Massar via dns-operations  wrote 
 a message of 88 lines which said:

> one can also test quickly with Stéphane Bortzmeyer's script:
> https://www.bortzmeyer.org/files/test-doh.py

Now superseded by Homer 
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] CLI Tool for DoH

[Stephane Bortzmeyer]

On Mon, Sep 28, 2020 at 06:30:33PM -0700,
 cjc+dns-o...@pumpky.net  wrote 
 a message of 9 lines which said:

> Looking for a command line tool to do testing of DoH. Something like
> dig or drill with DoH support. I suspect there's a Python tool

https://framagit.org/bortzmeyer/homer

% homer https://doh.bortzmeyer.fr/ dns-oarc.net
id 0
opcode QUERY
rcode NOERROR
flags QR RD RA AD
edns 0
payload 4096
option ECS ::/0 scope/0
;QUESTION
dns-oarc.net. IN 
;ANSWER
dns-oarc.net. 120 IN  2620:ff:c000::198
;AUTHORITY
;ADDITIONAL

Total elapsed time: 1.20 seconds (1195.46 ms/request)
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNS attacks against FR/BE/NL resolvers of Internet access providers

[Stephane Bortzmeyer]

On Mon, Sep 14, 2020 at 03:14:59PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 11 lines which said:

> On 1 and 2 September 2020, several French IAPs (Internet Access
> Providers), including SFR and Bouygues, were "down". Their DNS
> resolvers were offline, and it does indeed seem that this was the
> result of an attack carried out against these resolvers.
> 
> https://www.afnic.fr/en/resources/blog/about-the-attack-on-french-isps-dns-resolvers.html

The warning of ANSSI (the french cybersecurity agency) about recent
extorsion campaigns (with the message from the racketeer)
<https://www.cert.ssi.gouv.fr/actualite/CERTFR-2020-ACT-007/>

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Tutanota DNS issues

[Stephane Bortzmeyer]

On Thu, Sep 17, 2020 at 12:11:09PM +0800,
 Amari CH  wrote 
 a message of 17 lines which said:

> I have migrated the hosting service with them to other providers.
> 
> And their DNS query always returns SEVRFAIL:

I don't know for the old servers at IronDNS but the new ones at AWS
work and I get a proper answer for my DNS requests.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNS attacks against FR/BE/NL resolvers of Internet access providers

[Stephane Bortzmeyer]

On Mon, Sep 14, 2020 at 02:54:42PM -0300,
 Fernando Gont  wrote 
 a message of 19 lines which said:

> Any more details about the attack? e.e., what vectors they used, etc.?

No, they didn't publish any technical details. Like many people, I saw
the effects (DNS resolution down) but not the causes.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNS attacks against FR/BE/NL resolvers of Internet access providers

[Stephane Bortzmeyer]

On Mon, Sep 14, 2020 at 01:23:16PM -0700,
 Damian Menscher  wrote 
 a message of 87 lines which said:

> > There are a great many public resolvers, the best known ones among
> > which are operated by the major US corporations that have cornered
> > a large proportion of Internet services and are often referred to
> > as “GAFA” (from the initials of Google, Amazon, Facebook and
> > Apple), or the “Big Four”.
> 
> 
> Could you please share the IPs for the DNS resolvers operated by Amazon,
> Facebook, and Apple?  I'm trying to determine whether I'm simply unaware of
> those three open recursives (and unable to find them via a search engine),
> or if you're simply spreading FUD for political reasons.

Please have a tea and read again the sentences you quote.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] DNS attacks against FR/BE/NL resolvers of Internet access providers

[Stephane Bortzmeyer]

On 1 and 2 September 2020, several French IAPs (Internet Access
Providers), including SFR and Bouygues, were "down". Their DNS
resolvers were offline, and it does indeed seem that this was the
result of an attack carried out against these resolvers.

https://www.afnic.fr/en/resources/blog/about-the-attack-on-french-isps-dns-resolvers.html

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Seeking Advice: RIPEstat no longer recognizes my sub-zone under .university

[Stephane Bortzmeyer]

On Mon, Sep 07, 2020 at 10:43:57AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 22 lines which said:

> Since the main weakness of this domain is the lack of diversity in
> authoritative name servers' IP addresses, I guess that your problem
> comes from a routing issue between RIPE NCC and 158.108.0.0/16 (and
> 2406:3100::/32).

Speaking of routing, and while it is probably not the root cause of
your problem, you may want to review the security of
158.108.0.0/16. There is one ROA for the origin 9411 (OK) but also
route objects for other origins such as 4618. One of them is in the
NTT IRR (others in RADB, which is probably less reliable).

Anyway, some RIPE Atlas probes seem to have trouble reaching your name servers:

% blaeu-resolve -r 100 --nameserver 158.108.216.53 --type A kasetsart.university
Nameserver 158.108.216.53
[158.108.216.5] : 20 occurrences 
[TIMEOUT] : 2 occurrences 
Test #27041050 done at 2020-09-07T08:50:23Z

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Seeking Advice: RIPEstat no longer recognizes my sub-zone under .university

[Stephane Bortzmeyer]

On Mon, Sep 07, 2020 at 02:52:45PM +0700,
 Pirawat WATANAPONGSE  wrote 
 a message of 123 lines which said:

> I notice that one of our zones, “kasetsart.university”, is no longer
> recognized by the RIPEstat Tool Suite [Reference:
>
>https://stat.ripe.net/widget/reverse-dns-ip#w.resource=158.108.216.5],

For me, the domain kasetsart.university works fine. It is also the
opinion of Zonemaster 
and of DNSviz
.

Since the main weakness of this domain is the lack of diversity in
authoritative name servers' IP addresses, I guess that your problem
comes from a routing issue between RIPE NCC and 158.108.0.0/16 (and
2406:3100::/32). Another guess (may be they're both true): the message
"kasetsart.university is of an unsupported resource type. It should be
a hostname." may come from a obsolete hardcoded list of TLDs at
RIPEstat (the other names are ancient TLDs).

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Cloudflare public DNS sometimes forwards incomplete subset of NSEC RRs

[Stephane Bortzmeyer]

On Tue, Sep 01, 2020 at 01:48:17AM -0400,
 Viktor Dukhovni  wrote 
 a message of 71 lines which said:

> * The apex wildcard record and signature identically ONLY from
>   Google, Verisign and Quad9.  From CloudFlare, I get the munin01
>   NSEC record and signature twice, but this alone fails to validate the
>   NODATA response.

AFAIK, Cloudflare uses Knot Resolver. I tested with another Knot
resolver and it works:

Local Knot resolver (+dnssec in .digrc):

% dig _25._tcp.mx.runbox.com TLSA

; <<>> DiG 9.16.6-Debian <<>> _25._tcp.mx.runbox.com TLSA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9840
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;_25._tcp.mx.runbox.com.IN TLSA

;; AUTHORITY SECTION:
runbox.com. 3600 IN SOA dns61.copyleft.no. hostmaster.copyleft.no. (
308471 ; serial
14400  ; refresh (4 hours)
3600   ; retry (1 hour)
1296000; expire (2 weeks 1 day)
3600   ; minimum (1 hour)
)
*.runbox.com.   3600 IN NSEC _acme-challenge.runbox.com. A MX RRSIG NSEC
munin01.runbox.com. 3600 IN NSEC ipmi.mysql01.runbox.com. A RRSIG NSEC
runbox.com. 3600 IN RRSIG SOA 13 2 86400 (
20200914155225 20200831142225 38438 runbox.com.
W8mB29w0BTau0mRPcduMsOJIkRFgTn8DKhBskr7pYJe2
AYQzWGTxV1fKTN0dWKpVj5ewIdUPuKl3KSSxmJ9lNw== )
*.runbox.com.   3600 IN RRSIG NSEC 13 2 3600 (
20200914155225 20200831142225 38438 runbox.com.
3VVEU97k3XDgYtHFscg3EUC/PpiwitKEjpgJDPBFSfu5
rSg165gENRgIMnYNtPhm11IqHSO7yY62C2l6PvnlrA== )
munin01.runbox.com. 3600 IN RRSIG NSEC 13 3 3600 (
20200914155225 20200831142225 38438 runbox.com.
4gSQplps2UJsbpD6qVCrxl9njcu3jjWWMrQN8fx83AIa
lDkYrl3uLycX+K+HKLUiSjAphBiSzDo/JQMx1WjRhg== )

;; Query time: 250 msec
;; SERVER: 192.168.2.254#53(192.168.2.254)
;; WHEN: Tue Sep 01 07:54:35 UTC 2020
;; MSG SIZE  rcvd: 546

Cloudflare :

% dig @1.1.1.1  _25._tcp.mx.runbox.com TLSA

; <<>> DiG 9.16.6-Debian <<>> @1.1.1.1 _25._tcp.mx.runbox.com TLSA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11561
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;_25._tcp.mx.runbox.com.IN TLSA

;; AUTHORITY SECTION:
runbox.com. 3600 IN SOA dns61.copyleft.no. hostmaster.copyleft.no. (
308471 ; serial
14400  ; refresh (4 hours)
3600   ; retry (1 hour)
1296000; expire (2 weeks 1 day)
3600   ; minimum (1 hour)
)
runbox.com. 3600 IN RRSIG SOA 13 2 86400 (
20200914155225 20200831142225 38438 runbox.com.
W8mB29w0BTau0mRPcduMsOJIkRFgTn8DKhBskr7pYJe2
AYQzWGTxV1fKTN0dWKpVj5ewIdUPuKl3KSSxmJ9lNw== )
munin01.runbox.com. 3600 IN NSEC ipmi.mysql01.runbox.com. A RRSIG NSEC
munin01.runbox.com. 3600 IN RRSIG NSEC 13 3 3600 (
20200914155225 20200831142225 38438 runbox.com.
4gSQplps2UJsbpD6qVCrxl9njcu3jjWWMrQN8fx83AIa
lDkYrl3uLycX+K+HKLUiSjAphBiSzDo/JQMx1WjRhg== )
munin01.runbox.com. 3600 IN NSEC ipmi.mysql01.runbox.com. A RRSIG NSEC
munin01.runbox.com. 3600 IN RRSIG NSEC 13 3 3600 (
20200914155225 20200831142225 38438 runbox.com.
4gSQplps2UJsbpD6qVCrxl9njcu3jjWWMrQN8fx83AIa
lDkYrl3uLycX+K+HKLUiSjAphBiSzDo/JQMx1WjRhg== )

;; Query time: 80 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Sep 01 07:56:00 UTC 2020
;; MSG SIZE  rcvd: 541


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Nameserver responses from different IP than destination of request

[Stephane Bortzmeyer]

On Tue, Sep 01, 2020 at 02:45:23AM +,
 P Vixie  wrote 
 a message of 22 lines which said:

> you know that the plural of anecdote isn't data:

I recently discovered this english word and I love it:

https://en.wiktionary.org/wiki/anecdata
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Strange behavior of covid.cdc.gov

[Stephane Bortzmeyer]

On Mon, Aug 31, 2020 at 10:12:04PM +0900,
 Yasuhiro Orange Morishita / 森下泰宏  wrote 
 a message of 18 lines which said:

> But it seems to be a little bit strange.  The auth servers of cdc.gov
> zone serve unneed (and unsigned) akam.cdc.gov zone.  But they still
> have DS RR for real akam.cdc.gov zone.

They also do not return a proper delegation:

% dig +dnssec +norec @icdc-us-ns2.cdc.gov. A akam.cdc.gov 
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +dnssec +norec 
@icdc-us-ns2.cdc.gov. A akam.cdc.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43497
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 70d47b392dfb22d2662352815f4d0d3fe1c90df99f508386 (good)
;; QUESTION SECTION:
;akam.cdc.gov.  IN A

;; AUTHORITY SECTION:
akam.cdc.gov.   3600 IN SOA a1-43.akam.net. adhelpdsk.cdc.gov. (
612558384  ; serial
300; refresh (5 minutes)
180; retry (3 minutes)
1209600; expire (2 weeks)
3600   ; minimum (1 hour)
)

;; Query time: 98 msec
;; SERVER: 198.246.96.92#53(198.246.96.92)
;; WHEN: Mon Aug 31 16:46:23 CEST 2020
;; MSG SIZE  rcvd: 129

% dig +dnssec +norec @icdc-us-ns2.cdc.gov. DNSKEY akam.cdc.gov
; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> +dnssec +norec 
@icdc-us-ns2.cdc.gov. DNSKEY akam.cdc.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44336
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 2e27a9b171983390a21696a65f4d0d54710de953e8dd107b (good)
;; QUESTION SECTION:
;akam.cdc.gov.  IN DNSKEY

;; AUTHORITY SECTION:
akam.cdc.gov.   3600 IN SOA a1-43.akam.net. adhelpdsk.cdc.gov. (
612558384  ; serial
300; refresh (5 minutes)
180; retry (3 minutes)
1209600; expire (2 weeks)
3600   ; minimum (1 hour)
)

;; Query time: 98 msec
;; SERVER: 198.246.96.92#53(198.246.96.92)
;; WHEN: Mon Aug 31 16:46:44 CEST 2020
;; MSG SIZE  rcvd: 129

Whuch may explain the strange error messages of DNSviz (the IP
addresses are for the parent zone).
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Stephane Bortzmeyer]

On Wed, Jul 08, 2020 at 09:15:02PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 57 lines which said:

> No. My BIND and Unbound personal resolvers (which do not have a NTA)
> get a reply and set AD.

There are probably several different instances for each authoritative
server of grantee.fema.gov, and they behave differently. Here, seen by
the RIPE Atlas probes, you can se that some probes can get a DNSKEY
(when using the DO bit) and some cannot (timeout):

% blaeu-resolve -4 -r 100 --nameserver ns-dc2gtm1.dhs.gov. --type DNSKEY 
--dnssec grantee.fema.gov.
Nameserver ns-dc2gtm1.dhs.gov.
[TIMEOUT] : 37 occurrences
[256 3 10 aweaabvxfgryn7jl7igk3k7zpjbmvovaepmsbnn/lsugzqz6pjgz6y3/7geibgg3 
ubrwa 256 3 10 aweaachfofxdoii8+/ljej5ctuursgky 
h3ydxjf6t/wurehzelr77yi0i8tmcpyibmo6a 257 3 10 
aweaabronsypatfnhwvyn0ipda3l6hp5zwzc2i2mlxts85hvsdnhpghirwzjaio mob3e 257 3 10 
aweaadfgkwupgfkp7qayvzzcrs5jza2d jlkzqkwrg90wxdvo5anbrxncoiw3kzv0 ugj+k] : 61 
occurrences
[ERROR: SERVFAIL] : 2 occurrences
Test #26219900 done at 2020-07-08T19:19:20Z

Probably because they do to different instances of ns-dc2gtm1.dhs.gov.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Dealing with the bizarre - grantee.fema.gov

[Stephane Bortzmeyer]

On Wed, Jul 08, 2020 at 11:20:27AM -0700,
 Brian Somers  wrote 
 a message of 38 lines which said:

> I can only suspect that all 3 of these resolvers have an NTA for
> this domain!

No. My BIND and Unbound personal resolvers (which do not have a NTA)
get a reply and set AD. The truth is elsewhere.

% dig A grantee.fema.gov.

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> A grantee.fema.gov.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62146
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL:
;; 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;grantee.fema.gov.  IN A

;; ANSWER SECTION:
grantee.fema.gov.   30 IN A 173.255.49.196
grantee.fema.gov.   30 IN RRSIG A 10 3 30 (
20200715002926 20200708002926
38990 grantee.fema.gov.

RolWLU7SxjgBJGOIXELMDVXK641r1oI3p7icXEJLjWM+

4GLdidyuwIqnSr5GyzG5zBSW4g+J9ZZWvz18asrCJcqp


+t+DtARbXoumyyTWMTKRh1TtqkQre3ncfM3vQAEOtRbp


Tjq3jmBdrwv+VQElWRYQ0H2Oy3NhiRQ6EJXNvOs=


)


grantee.fema.gov.


30


IN


RRSIG


A


10


3


30


(


20200712161915


20200705161915


25856


grantee.fema.gov.



NIKjzoiiFtvZ6KhH+eOF+ikxSU9iomF7aizRmN15Z23x



fVQkxB8sKRYtFdfWzlY5oBl0V/LVAXJI+TeuN4ovv+cT




7EZGYAC5q6y6I2CmcTtoDgmFHbSS90bLUC5ndYornCLD
  

[dns-operations] Fake “DNS Update” emails targeting site owners and admins

[Stephane Bortzmeyer]

Funny, DNSSEC is so successful that you can use it for phishing :-)

https://www.helpnetsecurity.com/2020/06/30/fake-dns-update/
___
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

[Stephane Bortzmeyer]

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?
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] dnsviz.net complaining "UDP_-_NOEDNS_" for gtld-servers.net

[Stephane Bortzmeyer]

On Fri, Jun 05, 2020 at 11:26:55AM +0200,
 Thomas Mieslinger  wrote 
 a message of 29 lines which said:

> I have a customer complaining being unable to send/receive email.

sportsproducts.net appear to DNS-work fine, so the problem is probably
elsewhere.

> https://dnsviz.net/d/sportsproducts.net/dnssec/
> 
> shows errors:
> sportsproducts.net/DS: No response was received from the server
> over UDP (tried 12 times). (2001:502:1ca1::30, 2001:503:d414::30,
> 2001:503:eea3::30, UDP_-_NOEDNS_)

Timeout with Verisign name servers. Unfortunately, it is too common
with the IPv6 Internet. But, unless the resolver is v6-only, it does
not prevent DNS resolution (otherwise, no .net name would work). So,
it is probably not the reason why your customer has problems.

A test with the RIPE Atlas probes, to show that a few of them have the problem:

% blaeu-resolve --nameserver 2001:502:1ca1::30 -r 100 --dnssec -q DS 
sportsproducts.net
Nameserver 2001:502:1ca1::30
[] : 96 occurrences 
[TIMEOUT] : 3 occurrences 
Test #25636763 done at 2020-06-05T11:20:54Z
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] About the coincheck.com hijacking

[Stephane Bortzmeyer]

There is something new in the hijacking of the domain name
coincheck.com
,
the hijacker created domain names quite similar to the normal domain
names of the namservers. I believe it is the first time I see that.

(Normal NS RRset is ns-405.awsdns-50.com, ns-650.awsdns-17.net,
ns-1515.awsdns-61.org, ns-1985.awsdns-56.co.uk. Hijacker's one is
ns-650.awsdns-017.net, ns-1515.awsdns-061.org,
ns-1985.awsdns-056.co.uk. Do you spot the difference?)

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] A strange DNS problem (intermittent SERVFAILs)

[Stephane Bortzmeyer]

On Sat, May 30, 2020 at 06:50:53PM +,
 dagon  wrote 
 a message of 41 lines which said:

>  How can you even load
>  such a zone in a modern authority server?  All modern auth
>  servers would fail, I believe.

It may be that the authority server is correct but there is a firewall
in front of it, filtering requests and generating REFUSED, timeouts,
etc. I've seen people putting broken middleboxes before perfectly
working BIND servers...
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] A strange DNS problem (intermittent SERVFAILs)

[Stephane Bortzmeyer]

Several users on Twitter reported problems accessing Banque Populaire
(a French bank) https://www.banquepopulaire.fr
https://www.ibps.loirelyonnais.banquepopulaire.fr
https://www.ibps.bpaca.banquepopulaire.fr
https://www.ibps.mediterranee.banquepopulaire.fr/

>From the limited reports, all errors point to a DNS issue. (For one
user, adding the IP address in /etc/hosts solved the problem.)

But testing with existing resolvers and with the RIPE Atlas probes do
not show a widespread outage.

The existing DNS configuration is clearly very questionable, such as a
zone delegated to just one name server, and a broken one, replying
REFUSED for NS and SOA queries.

The question is "how did this incorrect setup can produce *sometimes*
a resolution failure?"

Details in french, plus dig outputs (not in french) are at
.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Cloudflare Rose and Rick in .com authoritative Nameserver

[Stephane Bortzmeyer]

On Mon, Apr 20, 2020 at 03:40:56PM +0200,
 Raffaele Sommese  wrote 
 a message of 35 lines which said:

> registries do not enforce the consistency between glue records and
> the same records served by the authoritative nameservers, right?

Some do, some don't. That's the beauty of the Internet:-) "It
depends."

___
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

[Stephane Bortzmeyer]

On Thu, Apr 02, 2020 at 09:31:18PM +0800,
 Tessa Plum  wrote 
 a message of 7 lines which said:

> I think we can put the devices in our own network to protect such attacks.

Commercial boxes are typically optimised for HTTP, DNS is very
different. I remember a box which was creating an entry in memory for
every source IP address. Even with IPv4, an attack with randomised
addresses was sufficient to kill it. Not even mentioning IPv6 :-)

___
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

[Stephane Bortzmeyer]

On Thu, Apr 02, 2020 at 05:39:48PM +0800,
 Davey Song  wrote 
 a message of 111 lines which said:

> You said you are managing DNS for your university and your concern
> for secondary DNS is privacy. I'm not sure what exactly the privacy
> concerns are.

RFC 7626.

Also, it may raise issues about integrity/trust/etc. In that case,
DNSSEC certainly helps a lot.
___
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

[Stephane Bortzmeyer]

On Thu, Apr 02, 2020 at 11:05:48AM +0100,
 Tony Finch  wrote 
 a message of 30 lines which said:

> > ACLs in the server are not enough, you also need ingress filtering
> > on the borders of your network, to prevent packets claiming to be
> > from your network to get inside.
> 
> That kind of ingress filtering protects you against DDoSing
> yourself, which maybe the rest of the Internet isn't too bothered
> about :-)

I'm not sure I understand you.

___
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

[Stephane Bortzmeyer]

On Thu, Apr 02, 2020 at 03:06:17PM +0800,
 Tessa Plum  wrote 
 a message of 18 lines which said:

> I never knew BCP38 before. I will try to study it.

BCP38 is Good, *but* it protects others against you. So, to be
protected, you need the *others* to implement 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

[Stephane Bortzmeyer]

On Thu, Apr 02, 2020 at 05:12:29PM +0800,
 Tessa Plum  wrote 
 a message of 11 lines which said:

> All the packages were DNS requests, some queries like 'dig domain.com any'.
> but their IP address seems spoofed.

In that case, yes, RRL would help.
___
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

[Stephane Bortzmeyer]

On Thu, Apr 02, 2020 at 11:51:05AM +0800,
 Tessa Plum  wrote 
 a message of 37 lines which said:

> We were under some attack like UDP flood to the authority servers,

DNS or another type?

> The traffic size was about 20Gbps

Note that for DNS traffic, the useful metric is often
packets-per-second, not-bytes-per second. In most cases, that's what
kills the server.
___
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

[Stephane Bortzmeyer]

On Thu, Apr 02, 2020 at 03:06:49AM +,
 Paul Vixie  wrote 
 a message of 29 lines which said:

> to keep your own recursive servers from amplifying spoofed-source
> attacks, you need ACL's that make it unreachable outside your
> specific client base.

ACLs in the server are not enough, you also need ingress filtering on
the borders of your network, to prevent packets claiming to be from
your network to get inside.

> to keep your own servers of whatever kind from being ddos'd into
> congestion loss, you need massive overprovisioning including both
> local and global anycast.

If the congestion is on the link, yes, you are right. If it is on the
server, filtering solutions may be sufficient if there is an easy way
to sort out the bad traffic from the good one, and if they are faster
than the name server (Netfilter on Linux is fast, for instance.)
___
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

[Stephane Bortzmeyer]

On Wed, Apr 01, 2020 at 07:35:35PM -0700,
 Fred Morris  wrote 
 a message of 10 lines which said:

> Depends on what you mean. You might look at "response rate limiting" in for
> instance BIND. -- FWM

RRL protects people against you (when your name server is used as a
reflector) but not really you against the dDoS.

___
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

[Stephane Bortzmeyer]

On Thu, Apr 02, 2020 at 10:14:14AM +0800,
 Tessa Plum  wrote 
 a message of 14 lines which said:

> May I ask if there are any solutions for DDoS mitigation of DNS?

All solutions that were mentioned here are correct but incomplete:
there is no general solution against dDoS, because "it depends". There
are many types of dDoS. You will need several tools in your toolbox,
and someone knowledgeable to choose among them.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] question on query to DNS server's IPv6 interface

[Stephane Bortzmeyer]

On Tue, Mar 31, 2020 at 08:37:30PM +0800,
 Tessa Plum  wrote 
 a message of 13 lines which said:

> Another question, in DNS server, how to count how many queries were
> from IPv6 interface, and how many queries were from IPv4 interface?

It depends on the name server. Here, is an example with nsd:

% sudo nsd-control stats | grep udp
num.udp=3070553
num.udp6=1805679

(IPv4 and IPv6)

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Algorithm but no signature in .in?

[Stephane Bortzmeyer]

Some resolvers protest on .in. It seems they have a RSASHA256 key but
no RSASHA256 signatures, thus violating RFC 4035, section 2.2 "There
MUST be an RRSIG for each RRset using at least one DNSKEY of EACH
ALGORITHM".

(Cannot show a nice DNSviz picture, DNSviz seems broken at this time.)

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] DNS of Turk Telekom

[Stephane Bortzmeyer]

Anyone has more detailed concrete information about this "DNS attack"?

https://www.itnews.com.au/news/turk-telekom-says-internet-access-restored-after-cyber-attack-536767
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Stephane Bortzmeyer]

On Wed, Jan 08, 2020 at 07:05:04PM +0800,
 William C  wrote 
 a message of 15 lines which said:

> 1. how to check if a zone has a valid DNSSEC key?

If you are not a DNSSEC expert, DNSviz is a handy tool 

> 2. how to validate if the zone has been signed with correct key?

DNSviz again. Otherwise, regular DNS resolution, using a validating
resolver.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] help with a resolution

[Stephane Bortzmeyer]

On Wed, Jan 08, 2020 at 08:56:41AM +0800,
 William C  wrote 
 a message of 59 lines which said:

> Can you help check why public nameservers (all 8.8.8.8, 1.1.1.1, 9.9.9.9
> etc) can't resolve this domain?

As explained by several experts, this domain is DNSSEC-broken. This
has nothing to to with the public resolvers (on my own local resolver,
it fails as well), any resolver which validates signatures (they
should all do it) will have the same problem.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] IPv6 only for nameservers

[Stephane Bortzmeyer]

On Mon, Dec 30, 2019 at 05:18:01PM +0300,
 Anand Buddhdev  wrote 
 a message of 17 lines which said:

> If your domain's authoritative name servers have only IPv6
> addresses, then your domain will not be resolvable by many resolvers
> on the Internet, because many of them only have IPv4 connectivity.

This was in 2014 but I'm not sure it changed a lot since:

https://labs.ripe.net/Members/stephane_bortzmeyer/how-many-ripe-atlas-probes-can-resolve-ipv6-only-domain-names
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations