[swinog] Re: Swisscom DNS issue: spectrum-conference.org wrongfully resolves to a bluewin address in swisscom mobile networks

[Daniel Stirnimann via swinog]

Yes, I understand the technical issues. And yes it's ugly. But do you have a 
better solution?


Swisscom should stop tampering with DNS, as it does not work, and is no 
solution to the problem.


I disagree, Swisscom still misses a lot of phishing and malware 
websites. I would like them to be way more aggressive. Their support 
staff has to deal with calls from infected customers. They might as well 
try as good a possible to prevent it from happening in the first place. 
If you belong to the <0.1% of people who want unfiltered DNS, just run 
your recursive resolver.



Part of the problem is that the user doesn’t get an error message at all, and 
then mails us „hey, your website is down“.


Eventually, web browser will show better responses for none resolvable 
domain names e.g. by utilizing Extended DNS Errors (RFC 8914).


EDE has code points for filtered or blocked DNS responses. Until web 
browser care more about DNS, I advice to be as verbose as possible when 
you block something.


For example, make the DNS output more verbose so that at least 
administrators realize why a domain name is blocked. Swisscom could have 
used a CNAME in the answer section to blocked.swisscom.com and they 
could also add an additional section with a SOA indicating the origin of 
the blocking. The RNAME field could be their report false positive email 
address and so on.


Daniel

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Swisscom DNS issue: spectrum-conference.org wrongfully resolves to a bluewin address in swisscom mobile networks

[Daniel Stirnimann via swinog]

Try http://195.186.208.193/

Daniel

On 23.04.2024 08:40, Marc Balmer wrote:



Swisscom returns this IP address for blocked domain names most likely because 
it assumes this website is compromised (phishing, malware).

If you visit this IP address in a web browser you are redirected to 
https://www.swisscom.ch/abuse-info

This website has a form to report false positive.



There is no such form.


___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Swisscom DNS issue: spectrum-conference.org wrongfully resolves to a bluewin address in swisscom mobile networks

[Daniel Stirnimann via swinog]

Swisscom returns this IP address for blocked domain names most likely 
because it assumes this website is compromised (phishing, malware).


If you visit this IP address in a web browser you are redirected to 
https://www.swisscom.ch/abuse-info


This website has a form to report false positive.

Daniel

On 22.04.2024 23:51, Marc Balmer via swinog wrote:


The domain name spectrum-conference.org 
 wrongfully resolves to 195.186.208.193 
when queried from bluewin/swisscom mobile networks.


It is registered to 46.175.8.9, which is the correct address.

Please fix the swisscom/bluewin.ch  DNS resolvers.


___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Debugging bluewin.ch emails not going through

[Daniel Stirnimann via swinog]

at least one delegation is broken:

ns1.init7.net:
200-30.135.144.213.in-addr.arpa. 86400 IN NSdns.nazgul.ch.
200-30.135.144.213.in-addr.arpa. 86400 IN NSdns.swill.org.

dig dns.swill.org
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16024
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Daniel


On 08.12.23 11:49, Maxim Samo via swinog wrote:

Hi,

I'm getting "421 EHLO temporary error - PTR lookup failed" when trying
to send any email to @bluewin.ch recipients.

My mailserver is mail.swill.org with proper PTR records configured though:

$ dig +short -t ptr 203.200-30.135.144.213.in-addr.arpa @8.8.8.8
mail.swill.org.

$ telnet 195.186.120.50 25
Trying 195.186.120.50...
Connected to 195.186.120.50.
Escape character is '^]'.
220 mxbw.bluewin.ch vimdzmsp-mxin03.bluewin.ch Swisscom AG ESMTP server
ready
ehlo mail.swill.org
421 EHLO temporary error - PTR lookup failed

Is there someone from bluewin.ch here that can help me work through this?

best,

Maxim

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Operational announcement: transition from NSEC3 to NSEC in the CH/LI zone

[Daniel Stirnimann via swinog]

Hi list,

We plan a DNSSEC signing change for the ch. and li. zone files.

Introduction:
Both NSEC and NSEC3 are mechanisms that provide signed DNS records as 
proof of non-existence for a given name or associated Resource Record 
Type in a DNSSEC signed zone. While they serve the same primary purpose, 
NSEC3 offers added features, such as not directly disclosing bounding 
domain name pairs and providing "opt-out support." This latter feature 
allows large registries to cover blocks of unsigned delegations with a 
single NSEC3 record, thereby only signing as many NSEC3 records as there 
are signed DS or other RRsets in the zone.


Recent trends and developments:
Since 2021, there's been a notable increase in the percentage of domain 
names with DNSSEC for .ch, jumping from 6% to 49% [1]. Additionally, the 
TLD zone files for both .ch and .li have been made publicly accessible 
for download in recent years [2]. These developments have rendered the 
argument for using NSEC3 with opt-out less compelling.


Our action plan:
SWITCH is set to transition from NSEC3 (utilizing opt-out) to NSEC for 
both the .ch and .li TLD zones. Given the high percentage of domain 
names already employing DNSSEC, this shift will result in only a modest 
increase in the size of the zone files. Importantly, transitioning to 
NSEC offers several benefits [3]:


* Enhanced performance and reduced latency
* Decreased resource utilization on both authoritative and recursive servers
* Potential bolstering of resilience against specific types of DoS attacks

Scheduled transition dates:
.li: 10th November 2023, 8 am CET
.ch: 10th November 2023, 10 am CET

Impact assessment:
We expect no operational impacts for end users. However, we value 
feedback and observations. If you have concerns or notice any anomalies 
related to this transition, please don't hesitate to contact us.


[1] https://www.nic.ch/statistics/dnssec/
[2] https://zonedata.switch.ch/
[3] https://datatracker.ietf.org/doc/html/rfc8198


--
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
https://switch.ch  https://swit.ch/linkedin  https://swit.ch/twitter
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: Swiss Domain Security Report Q3 2022

[Daniel Stirnimann via swinog]

Hi Adrian,


On 07.06.23 21:33, Adrian Ulrich via swinog wrote:

I'm pretty surprised that of the 1.7M domains with an MX record, only 57% have 
DKIM


I don't see how one could reliability gather this data from DNS:

DKIM allows you to specify a selector in the header of the mail: This mail for 
example will use 'sx1' as the selector (check out the header ;-) ):


$ dig +short txt sx1._domainkey.blinkenlights.ch
"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC[]


But without ever receiving a mail from me: how would you know?

You could try to send a query for '_domainkey.blinkenlights.ch' and you MAY 
receive a NOERROR reply - but that's not guaranteed: My DNS will just return an 
NXDOMAIN:


$ dig txt _domainkey.blinkenlights.ch|grep status:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10153



Your nameserver breaks https://www.rfc-editor.org/rfc/rfc8020

   This document states clearly that when a DNS resolver receives a
   response with a response code of NXDOMAIN, it means that the domain
   name which is thus denied AND ALL THE NAMES UNDER IT do not exist.

Daniel
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: DNSSEC auto-disabled by SWITCH on some .ch domains?

[Daniel Stirnimann via swinog]

On 01.05.23 15:48, Benoît Panizzon via swinog wrote:


It looks like Gandi at least messed up their Registrar UI.

 From their point of view, my 'algo 5' .ch domains have still DNSSEC
active but deleting DS or disabling DNSSEC hangs forever and upon
reloading my old algo 5 keys are back. I guess they perform some API
calls to Switch and this fails, because both disagree on the DNSSEC
status?


The nerd answer is that you can use Automated DNSSEC Provisioning [1] to 
enable DNSSEC. This also sends an EPP poll message to your registrar to 
update locally cached state information about a domain name. See also 
chapter 6.1 in our Automated DNSSEC Provisioning Guidelines [2]. I don't 
know if EPP poll messages have been used in the algo 5/7 removal 
procedure or if registrars received a list of affected domains and were 
instructed to refresh locally cached state. If the former and the domain 
state is still wrong then the registrar is not processing EPP poll messages.


The normal answer is that you should contact the registrar and ask him 
to refresh the domain.


Daniel

[1] https://www.nic.ch/de/security/cds/
[2] https://www.nic.ch/export/shared/.content/files/SWITCH_CDS_Manual_en.pdf
___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: DNSSEC auto-disabled by SWITCH on some .ch domains?

[Daniel Stirnimann via swinog]

I wasn't a part of this procedure so I cannot answer anything related to 
that. I can, however, respond to questions for which we make information 
available online.


If you want specific information about the procedure I suggest you ask 
your registrar or you can contact SWITCH at regis...@nic.ch.


On 01.05.23 14:12, Franco Hug via swinog wrote:

Would be interesting to see a chart similar to this one: 
https://www.nic.ch/de/statistics/dnssec/ which shows the different algorithms 
in use.


You can find the DNSSEC algorithm break down for the end of 2022 for .ch 
on slide 21:


https://www.nic.ch/export/shared/.content/files/SWITCH_Report_Registry_2022.pdf

DNSSEC algorithm Number Percentage
5 – RSASHA1 45 0.00%
7 – RSASHA1-NSEC3-SHA1 607 0.05%
8 – RSASHA256 97,098 8.96%
10 – RSASHA512 67 0.01%
13 – ECDSAP256SHA256 1,018,855 91.22%
14 – ECDSAP384SHA384 139 0.01%
15 – ED25519 61 0.01%
16 – ED448 14 0.00%

Older reports are published at:
https://www.nic.ch/about/



Since end of January 2023 you could not use them anymore.


Probably valid for new DNSSEC activations, had no effect on pre-existing algo 
5/7 domains.


Same PDF has some information on slide 15 which basically states:

* Nov 2022, you can not introduce algo 5 or 7 for a previously unsigned 
domain
* Jan 2023, you can not roll your algo 5 or 7 unless to a more modern 
algorithm



Cheers,
Daniel

___
swinog mailing list -- swinog@lists.swinog.ch
To unsubscribe send an email to swinog-le...@lists.swinog.ch

[swinog] Re: DNSSEC issue with swizzonic DNS servers?

[Daniel Stirnimann via swinog]

Hi Benoit

Not sure what the original problem was on the 27th of Dec but the 
current problem is as follow:


numberportability.ch has an NSEC negative proof at the zone apex which 
states that there are no other hostnames then numberportability.ch itself.


dig @dns1.swizzonic.ch numberportability.ch.  +dnssec +norec
...
;; AUTHORITY SECTION:
numberportability.ch.	900	IN	SOA	dns1.swizzonic.ch. 
hostmaster.swizzonic.ch. 2022121601 10800 3600 604800 86400
numberportability.ch.	900	IN	RRSIG	SOA 13 2 900 2023011900 
2022122900 10556 numberportability.ch. 
TyEySTihvSFvdHr+AIOwYV7P/7OwnEkkKmviAfpDM7Ls/7oSkE0YWpKT 
rtn2OLAcGayrejP3hYYdU9cH7+DddQ==
numberportability.ch.	86400	IN	NSEC	numberportability.ch. A NS SOA MX 
TXT RRSIG NSEC DNSKEY
numberportability.ch.	86400	IN	RRSIG	NSEC 13 2 86400 2023011900 
2022122900 10556 numberportability.ch. 
Cv2K3pWOJ739PgraeAseqUCXegIGJsrN5zmFRa2hKpohwKY/NCSx2RuJ 
q1PdHXPh6w9Es+Y6btCZNtuRfQ7iZg==


See the NSEC proof in the above query.

A DNSSEC validating resolver which supports and enables synthesized 
answers from cached NSEC, NSEC3 (rfc8198) will answer follow up queries 
for this domain name which fall outside the NSEC chain directly with 
NXDOMAIN. This problem only occurs if there is already a cached NSEC 
record. I guess this is not unlikely as most web browser do HTTPS and 
 qtype lookups in paralell to A queries. HTTPS and  do both not 
exist for numberportability.ch.


Such a DNSSEC validating resolver which synthesizes answers from cached 
NSEC, NSEC3 records will not log a DNSSEC validation error. The problem 
is that the NSEC proof is lying and not that it its DNSSEC signature is 
invalid.


All current open source DNS resolver software support synthesized 
answers from cached NSEC, NSEC3 (rfc8198). I tested knot-resolver, 
powerdns-recursor and BIND and unbound. In BIND the configuration option 
is called "synth-from-dnssec" which is enabled by default since BIND 
9.18. In knot-resolver there is no configuration option, it is always 
enabled. For powerdns-recursor you need v4.5 where it is enabled by 
default, option "aggressive-nsec-cache-size". For unbound you need v1.17 
but it is disabled by default. The option is "aggressive-nsec". Google 
Public DNS also supports it.


Note, synthesized answers from cached NSEC, NSEC3 is a very useful 
feature. To quote the unbound documentation [1]:


"Aggressive NSEC can result in a reduction of traffic on all levels of 
the DNS hierarchy but it will be most noticeable at the root, as 
typically more than half of all responses are NXDOMAIN.


Another benefit of a wide deployment of aggressive NSEC is the incentive 
to DNSSEC sign your zone. If you don’t want to have a large amount of 
queries for non-existing records at your name server, signing your zone 
will prevent this."


[1] 
https://unbound.docs.nlnetlabs.nl/en/latest/topics/privacy/aggressive-nsec.html


It is also very effective against random subdomain attacks, very common 
attack vector at the moment (See also rfc8198) where rate-limiting 
queries does not help. A DNS-OARC talk from 2017 by Petr Špaček also 
compared it to running the root zone locally, 
https://indico.dns-oarc.net/event/27/contributions/473/attachments/430/725/DNS-OARC-27-presentation-RFC7706-8198.pdf.


If you want to trigger the problem on your DNS resolver, you need to 
query for a NoData answer first e.g.:


dig numberportability.ch. 

The resolver caches the NSEC proof. You can then query for an existing 
name which will be synthesized because of the "lying" NSEC proof. e.g.:


dig www.numberportability.ch. A
-> synthesized NXDOMAIN instead of the answer record

If you are the zone owner of numberportability.ch, you need to tell 
Swizzonic that they should execute:


pdnsutil rectify-zone numberportability.ch

This will fix the problem temporarily until the zone is changed again by 
some users.


A possible (note I'm guessing) root problem is that Swizzonic uses a 
WebFrontend which directly access the Database with SQL statements. This 
breaks DNSSEC in PowerDNS. One has to use a WebFrontend which uses the 
PowerDNS API. See also https://github.com/PowerDNS/pdns/wiki/WebFrontends


Cheers,
Daniel


On 27.12.22 09:45, Benoit Panizzon via swinog wrote:

Hi List

Fancy another DNS issue hunt?

We have DNSSEC validation enabled on our BIND DNS Servers.

We started seeing:

no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 
2a01:8100:2901::1:183:202#53
no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 
2a01:8100:2901::1:183:201#53
no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 81.88.58.219#53
no valid RRSIG resolving 'www.numberportability.ch/DS/IN': 195.110.124.196#53

broken trust chain resolving 'www.numberportability.ch/HTTPS/IN': 
2a01:8100:2901::1:183:202#53
broken trust chain resolving 'www.numberportability.ch//IN': 
2a01:8100:2901::1:183:202#53
client @0x803541d60 X.X.X.X#27325 (www.numberportability.ch): query