[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 

[swinog] New nameserver node for LI/CH at SwissIX

[Daniel Stirnimann]

Hello Swinog,

The TLD zones .ch/.li make use of the RcodeZero Anycast DNS service of
nic.at since a few weeks (The nameserver letters d.nic.ch/d.nic.li to be
precise). Nic.at has now added an anycast node at SwissIX. In order to
get the best possible RTT and increased resiliency against potential
DDOS attacks on the DNS infrastructure we encourage network operators
peering at SwissIX without using the route servers to get in contact
with nic.at for direct peering:

AS1921, Peering @ SwissIX https://peeringdb.com/ix/60
IP addresses: 91.206.52.164, 2001:7f8:24::a4
Contact: o...@nic.at

The RcodeZero Anycast DNS node at this location provides DNS services
for multiple other TLDs.

Best regards,
Daniel
--
SWITCH DNS Operations




___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] our zimbra webmail server is on the swisscom dns blacklist ...

[Daniel Stirnimann]

The domain name zimbox.ch seems to be listed on some phishing blocklists
[1]. I found entries at G-Data (VT) and at SURBL:

http://www.surbl.org/surbl-analysis
-> zimbox.ch is listed in PH
   A ticket for list removal of this domain is already in our queue

https://www.virustotal.com/gui/domain/zimbox.ch/detection
-> G-Data, https://www.gdata.de/impressum

It looks like de-listing at SURBL is ongoing. You may want to contact
G-Data yourself.

Kind regards,
Daniel


[1]
https://mxtoolbox.com/SuperTool.aspx?action=blacklist%3azimbox.ch=toolpage

On 24.07.20 08:40, Tobias Oetiker wrote:
> Hi All
> 
> We are running a zimbra web mail server https://zimbox.ch for our
> customers. Yesterday afternoon swisscom has put its IP (46.140.183.201)
> on their DNS blacklist
> (https://www.swisscom.ch/de/res/hilfe/internet/internetguard/url-checker.html).
> Since the thing is running https, this leads to people with swisscom
> internet access to get some cryptic error message about SSL problems
> from their browser when they want to read their mail.
> 
> No, the server is not hacked, and we are running the latest version of
> zimbra web mail on it.
> 
> We have filled in the swisscoms 'de-blacklisting' web form but nothing
> has happened yet. We also called the swisscom kmu-hotline, but no, sorry
> we can not do anything.
> 
> Any advice ? For now we are advising our customers to set their dns
> server in their computers to 8.8.8.8 ...
> 
> By the light of day, swisscom is directly damaging our business with
> this ...
> 
> cheers
> tobi (angry)
> -- 
> Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> www.oetiker.ch t...@oetiker.ch +41 62 775 9902
> 
> 
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
> 


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Missing DNS A records for several domains hosted by swisscom.com

[Daniel Stirnimann]

It looks like that the affected domain names have not been updated to
the (new) MX hosts:

mx01.mailsecurity.swisscom.com.
mx02.mailsecurity.swisscom.com.

So, I guess its a domain owner problem and not a Swisscom problem.

For example, spital-lachen.ch used to have
mtainXX.mailsecurity.swisscom.com. until June 2019 and has since moved
to mxXX.mailsecurity.swisscom.com.

Daniel

On 07.02.20 10:45, Tobi wrote:
> Hi
> 
> hope someone from Swisscom reads here. We're currently seeing that DNS A
> records for MX hosts of several domains disappeared. They all using
> 
>> mtainXX.mailsecurity.swisscom.com
> 
> as MX record. But there are no A records for those MX
> 
> 
> ; <<>> DiG 9.11.14-RedHat-9.11.14-2.fc31 <<>>
> mtain01.mailsecurity.swisscom.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47048
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;mtain01.mailsecurity.swisscom.com. INA
> 
> ;; AUTHORITY SECTION:
> swisscom.com. 574 IN  SOA dns3.swisscom.com. 
> admin\.dns.swisscom.com.
> 42532 21600 3600 604800 600
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fr Feb 07 10:42:03 CET 2020
> ;; MSG SIZE  rcvd: 113
> 
> 
> ; <<>> DiG 9.11.14-RedHat-9.11.14-2.fc31 <<>>
> mtain02.mailsecurity.swisscom.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 56271
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;mtain02.mailsecurity.swisscom.com. INA
> 
> ;; AUTHORITY SECTION:
> swisscom.com. 574 IN  SOA dns3.swisscom.com. 
> admin\.dns.swisscom.com.
> 42532 21600 3600 604800 600
> 
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Fr Feb 07 10:42:03 CET 2020
> ;; MSG SIZE  rcvd: 113
> 
> 
> According to our passive DNS data there are at least 63 domains using
> one of these hosts as their MX.
> 
> --
> 
> Cheers
> 
> tobi


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] swinog Digest, Vol 174, Issue 3

[Daniel Stirnimann]

The pointers have been given before. This is your problem:

https://www.spamhaus.org/query/ip/79.134.251.203

Daniel

On 11.07.19 14:25, Andreas Fink wrote:
> Except that this is not applicable. In my case my mailserver is not
> hosted at Swisscom but on my own infrastructure, is on the same IP since
> years, has proper MX records and reverse DNS entries and has delivered
> email to the same bluewin customer yesterday successfully. Only the
> reply on that receiver today which I received and replied again got
> rejected. And the response is cryptic to me.  
> 
> And if you mail to ab...@bluewin.ch  you get
> the same error...
> 
> So who is this famous DNSNULL I should contact?
> 
> 
> 
>> On 11 Jul 2019, at 13:49, Florin sfetea > > wrote:
>>
>> See 
>> https://community.swisscom.ch/t5/E-Mail/Bluewin-akzeptiert-E-Mails-von-eigener-Domain-nicht/td-p/570002
>>  
>>  
>> Beste Grüsse, Regards si s-auzim de bine 
>> Florin Sfetea
>>  
>> *From: *swinog-requ...@lists.swinog.ch
>> 
>> *Sent: *Thursday, July 11, 2019 12:00
>> *To: *swinog@lists.swinog.ch 
>> *Subject: *swinog Digest, Vol 174, Issue 3
>>  
>> Send swinog mailing list submissions to
>>   swinog@lists.swinog.ch 
>>  
>> To subscribe or unsubscribe via the World Wide Web, visit
>>   http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
>> or, via email, send a message with subject or body 'help' to
>>   swinog-requ...@lists.swinog.ch
>> 
>>  
>> You can reach the person managing the list at
>>   swinog-ow...@lists.swinog.ch 
>>  
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of swinog digest..."
>>  
>>  
>> Today's Topics:
>>  
>>    1. bluewin & DNSNULL (Andreas Fink)
>>  
>>  
>> --
>>  
>> Message: 1
>> Date: Thu, 11 Jul 2019 11:32:38 +0200
>> From: Andreas Fink mailto:af...@list.fink.org>>
>> To: "swi...@swinog.ch " > >
>> Subject: [swinog] bluewin & DNSNULL
>> Message-ID: <75da5d85-1a68-4d10-94b8-6237fd9d5...@list.fink.org
>> >
>> Content-Type: text/plain; charset="us-ascii"
>>  
>>  
>> Does any one have a clue what DNSNULL means in the following context
>> of a mail delivery error?
>>  
>>  
>>  
>> <@bluewin.ch
>>  >
>> (mx-v02.bluewin.ch
>>  :
>> 554 mxbw.lb.bluewin.ch
>>  vim
>> dzmsp-mxin12.bluewin.ch
>>  
>> Swisscom AG IP: 79.134.251.203, You are not allowed 
>> to send us mail. Please see DNSNULL if you feel this is in
>> error)Reporting-MTA: dns; mail.fink.org
>>  
>> Arrival-Date: Thu, 11 Jul 2019 11:19:58 +0200
>> ...


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] .CH/.LI DNSSEC Algorithm Rollover

[Daniel Stirnimann]

Hello,

for your information, SWITCH will perform a DNSSEC algorithm rollover
from RSA to ECDSA for ch. and li.

ECDSA uses smaller keys and signatures than their RSA counterparts,
which means responses to DNS queries are smaller.

ECDSA was already standardised for use in DNSSEC in 2012. While
switch.ch has been signed with ECDSA since 2016, IANA the root zone
operator has only recently allowed TLDs to use it.

The changes to the ch. and li. zones DNSKEY record are as following with
times reported in UTC:

2018-11-21T13:30 Add new ECDSA key to DNSKEY record set
2018-12-21T13:30 Remove old RSA key from DNSKEY record set

Between this interval, the chain of trust for ch. and li. will be
updated in the root zone to point to the new ECDSA key only.

Operators of DNSSEC validating DNS resolvers do not need to do anything.
In the unlikely case that your validating DNS resolver only understands
RSA but not ECDSA, then it will answer to ch. or li. queries as if they
were not DNSSEC signed.

You can test which DNSSEC algorithms are supported by the DNS
resolver(s) configured on your system by visiting:
https://rootcanary.org/test.html

Best regards,
Daniel Stirnimann, SWITCH

-- 
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
daniel.stirnim...@switch.ch, www.switch.ch



signature.asc
Description: OpenPGP digital signature

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Google DNS on Salt Mobile

[Daniel Stirnimann]

Hello Greg,

> It seems like Salt is no longer supplying their own DNS servers when
> establishing an LTE connection. Instead, the network responds with Google DNS
> servers (8.8.8.8 8.8.4.4).

They seem to use a mix of Google Public DNS and own resolvers.

I noticed this a year ago as well:
https://twitter.com/seckle_ch/status/935547795066572800

Measurements from Apnic about DNSSEC validation rate for end users of
Salt and use of Google Public DNS does not show a clear trend:
https://stats.labs.apnic.net/dnssec/AS15796?c=CH=0=30=1

Daniel


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

[swinog] Sporadic DNS resolver error for *.mail.protection.outlook.com

[Daniel Stirnimann]

looks like the authoritative nameservers cannot handle EDNS(0) queries
(standardized in 1999, rfc2671). While this is not a problem per see,
the FORMERR response is not according RFC. For more details see:
https://ednscomp.isc.org/ednscomp/17c95198e4#edns

Name resolution therefore relies on retries by the resolver until it
figured out how to talk to this authoritative nameserver.

I guess this could be the source of your problem as such retries are
error prone or can lead to timeouts.

If you are using BIND you can avoid this retries all together by using:

// avoid using EDNS(0) for the following nameservers
server 157.55.234.42 { edns false; };
server 157.56.112.42 { edns false; };
server 23.103.145.81 { edns false; };
server 157.56.112.42 { edns false; };

See BIND ARM manual for more information:
https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch06.html#server_statement_grammar

Note, EDNS workarounds are going to disappear. See:
https://ripe76.ripe.net/presentations/159-edns.pdf

Daniel, SWITCH

On 22.05.18 11:09, Ralf Zenklusen, BAR Informatik AG wrote:
> Hi,
> 
> we see sporadic DNS resolver errors for A records of
> *.mail.protection.outlook.com
> 
> Only a few per day vs many successful lookups.
> 
>  
> 
> Anybody else seeing these?
> 
>  
> 
>  
> 
>  
> 
> Kind regards
> 
> Ralf
> 
>  
> 
>  
> 
>  
> 
> 
> 
> *Ralf Zenklusen *
> Dipl. El. Ing. HTL
> Leiter Internet       
>  
> 
>     
> 
>   
> 
> *BAR *Informatik AG
> Weidenweg 235
> 3902 Brig-Glis
> Tel +41 27 922 48 48
>   
> 
>   
> 
> www.barinformatik.ch
> www.rhone.ch
> r.zenklu...@barinformatik.ch
> 
> 
> 
> 
> 
> 
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
> 


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] datacomm/vtxnet and quicknet/kfsb are missing TLS on their mailservers

[Daniel Stirnimann]

> Since you seem to like quotes, Jon Postel had one for you:
> 
> "Be liberal in what you accept, and conservative in what you send"

I thought this mindset is outdated:

https://tools.ietf.org/html/draft-thomson-postel-was-wrong-02

Daniel


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] 'known' DNS Problems with Migros Banking App?

[Daniel Stirnimann]

Hello Benoit,

I have just tested the Migros Banking App on Android on a WiFi network
with an IPv4 only address. The dns resolver is validating and has an
IPv4 and IPv6 address to resolve names.

If I start the App on my smartphone it resolves the following domain names:
secure.migrosbank.ch. A
mid.mbmid.ch. A

Both work without a problem and the App starts successfully. I also
checked the domain names and nameservers. I don't see any problems
except for the small issue with the additional authoritative nameserver
(ns1.datacenter-migros.ch.) which should not cause any problems.

So, maybe it's a local device-, network problem of your customer and not
of your infrastructure.

Daniel, SWITCH

On 09.08.16 13:47, Benoit Panizzon wrote:
> Hello
> 
> One customer contacted us, because the Migros Banking App does not work
> from within our network and asked me to contact the Migros NOC to find
> out what we should change to make it work.
> 
> From the Migros NOC I got the feedback, that this is an issue they
> observed with customers whose ISP have IPv6 enabled DNS Server. They
> recommend that either the ISP disables IPv6 on the nameservers, or that
> the customers uses a different ISP, for example via Mobile Phone
> Hotspot to use their Banking app.
> 
> Apparently UPC Cablecom is another ISP with the same issue and cablecom
> is able to resolve the issue by disabling IPv6 for the affected
> customers.
> 
> I am a bit puzzled. I first suspected a DNSSEC issue as our servers do
> validate DNSSEC. But this does not seem to be the case.
> 
> I can resolve the hostnames without any problems via our DNS Servers.
> 
> Our DNS Servers are IPv6 enabled. When another DNS Server has an
> IPv6 address, they will prefer IPv6.
> But our customer does not get an IPv6 address. So his local resolver
> does only know the IPv4 address of our DNS Servers. The Migros DNS
> Servers do not publish an IPv6 address. So how is IPv6 involved in this
> issue?
> 
> The Domain in Question: mbmid.ch is:
> 
> mbmid.ch.   241 IN  NS  ns1.datacenter-migros.ch.
> mbmid.ch.   241 IN  NS  migze104.migros.ch.
> mbmid.ch.   241 IN  NS  migze100.migros.ch.
> 
> ns1.datacenter-migros.ch. 146   IN  A   164.14.130.66
> migze100.migros.ch. 3222IN  A   146.67.146.20
> migze104.migros.ch. 3222IN  A   193.8.177.201
> 
> They are not DNSSEC Signed.
> 
> The only issue I found is that ns1.datacenter-migros.ch is not
> published in the registrar glue record, but this also would not lead to
> a failure to resolve the hostname.
> 
> Has anyone else come across that issue and could give me a hint where
> to further investigate?
> 
> -Benoît Panizzon-
> 


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] 20 Minuten Online gehackt?

[Daniel Stirnimann]

Das Problem ist weniger 20min als der AD-Server von Tamedia. Aktuell
kommt der Schadcode halt nur via 20min.ch. Aber in der Vergangenheit
waren auch andere Tamedia Seiten betroffen. Siehe auch:

http://securityblog.switch.ch/2016/02/10/attack-of-the-killer-ads/
http://www.govcert.admin.ch/blog/13/swiss-advertising-network-compromised-and-distributing-a-trojan

Da das Thema bald ein 1 Jahr ist! Sollte die Empfehlung wohl etwas
generischer lauten:

 1. Add Blocker z.B. ublock Origin
 2. Kein IE verwenden (das Exploit-Kit hat es bisher nur auf User-Agent
   abgesehen, welche die Strings "Windows NT Trident" enthalten. Also
   IE only und ohne Edge Browser.
 3. Alle Tamedia Seiten blockieren :-|

Persönlich denke ich, dass Punkt 1. genügt. 20min.ch blockieren hilft
dir in 2 Wochen wohl schon nicht mehr.

Daniel

On 07.04.16 17:42, i...@spiron.ch wrote:
> Hallo Zusammen
> 
> Hatte soeben einen Tipp bekommen dass 20 Minuten Online gehackt wurde.
> 
> http://www.tagesanzeiger.ch/schweiz/standard/Bundesverwaltung-blockiert-Website-von-20-Minuten/story/24411901
> 
> Seite ist bei uns gesperrt. Würde euch das auch empfehlen um schaden
> vorzubeugen.
> 
> Grüsse aus Wallisellen
> 
> Rony Spitzer
> 
>  
> 
> Netzwerk &  Broadcast Services
> 
>  
> 
> kameramann.ch  GmbH
> 
> Hertistrasse 25
> 
> 8304 Wallisellen - Zürich
> 
> NEU mit sechs fiber-basierten und vernetzten AVID- und Premiere Suiten.
> 
> Der grösste, private Anbieter für ENG- und Postproduktion-Services in
> der Region Zürich. 
> 
> 
> 
> 
> ___
> swinog mailing list
> swinog@lists.swinog.ch
> http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
> 


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] .ch registrars : goodbye nic.ch, but where to go then ?

[Daniel Stirnimann]

Hi Benoit

Transfer of a DNSSEC signed domain is supported by SWITCH, of course.

The problem is that many registrars fail to accept a DNSSEC signed
domain which has *two* or more DS records for a single DNSKEY. As SWITCH
used to publish digest type 1, 2 (and later 4) for each signed domain
(if you were a direct customer of SWITCH) this setup is common. If I
remember correctly, there are still about 180 such domain names in ch.

Me privately as well as at SWITCH we stumbled over this issue when
transferring a signed domain. There are two workarounds:

1) you remove DNSSEC for your domain during the transfer

2) you tell SWITCH to remove all but *one* DS record for your signed
domain. Afterwards, the transfer works just fine.

In the mean time, SWITCH is trying to educate the registrars we know of
who have problems with accepting signed domains with more then one
digest. If you don't mind, please send me the name of the registrar
directly.

We are also in the process of implementing a DNSSEC test procedure which
registrars have do before they can send/receive DNSSEC data over EPP.
Maybe we should have done this earlier.

Daniel

-- 
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
daniel.stirnim...@switch.ch, http://www.switch.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Troubles with IPv6 queries to whois.nic.ch?

[Daniel Stirnimann]

Hello Benoît

I'm not sure at what time and from which IPv6 address you tried.
I just tried to find log entries with my co-workers operating
whois.nic.ch for 2001:4060:dead::/48 on the 26th Apr 2015 and found nothing.

If you want me to look into this, can you provide exact information?

Regards,
Daniel, SWITCH

On 26.04.15 12:24, Benoît Panizzon wrote:
 Hello
 
 Who else experiences that problem since a couple of days?
 
 $ whois direktion.ch
 The number of requests per client per time interval is
 restricted. You have exceeded this limit.
 Please wait a moment and try again.
 
 (query was done via IPv6)
 
 $ whois -h 130.59.31.241 direktion.ch
 whois: This information is subject to an Acceptable Use Policy.
 See http://www.nic.ch/terms/aup.html
 
 
 Domain name:
 direktion.ch
 [...]
 
 works!
 
 I'm not doing more than max 10 queries/week from that specific ipv6 address, 
 probably much less.
 
 I'm not aware of having other clients within my /48 network doing any queries 
 to whois.nic.ch (yes, my blacklist scripts do a lot of queries to 
 whois.ripe.net and other RIR's to get abuse contacts, but not to switch)
 
 -Benoît-
 
 
 ___
 swinog mailing list
 swinog@lists.swinog.ch
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
 

-- 
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
daniel.stirnim...@switch.ch, http://www.switch.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] Troubles with IPv6 queries to whois.nic.ch?

[Daniel Stirnimann]

The mentioned problem turned out to be a bug in whois.nic.ch when
handling IPv6 requests. The bug only appears in rare events. We will of
course fix it.

Daniel

On 27.04.15 10:38, Daniel Stirnimann wrote:
 Hello Benoît
 
 I'm not sure at what time and from which IPv6 address you tried.
 I just tried to find log entries with my co-workers operating
 whois.nic.ch for 2001:4060:dead::/48 on the 26th Apr 2015 and found nothing.
 
 If you want me to look into this, can you provide exact information?
 
 Regards,
 Daniel, SWITCH
 
 On 26.04.15 12:24, Benoît Panizzon wrote:
 Hello

 Who else experiences that problem since a couple of days?

 $ whois direktion.ch
 The number of requests per client per time interval is
 restricted. You have exceeded this limit.
 Please wait a moment and try again.

 (query was done via IPv6)

 $ whois -h 130.59.31.241 direktion.ch
 whois: This information is subject to an Acceptable Use Policy.
 See http://www.nic.ch/terms/aup.html


 Domain name:
 direktion.ch
 [...]

 works!

 I'm not doing more than max 10 queries/week from that specific ipv6 address, 
 probably much less.

 I'm not aware of having other clients within my /48 network doing any 
 queries 
 to whois.nic.ch (yes, my blacklist scripts do a lot of queries to 
 whois.ripe.net and other RIR's to get abuse contacts, but not to switch)

 -Benoît-


 ___
 swinog mailing list
 swinog@lists.swinog.ch
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

 

-- 
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
daniel.stirnim...@switch.ch, http://www.switch.ch


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] .com registrar that offers DS records and IPv6 Glue

[Daniel Stirnimann]

Hi Benoit,

I have no recommendation but the following might still be of interest.

ICANN publishes a list of registrars which support DNSSEC (last updated
March 2014)
https://www.icann.org/resources/pages/deployment-2012-02-25-en

I randomly picked one in Europe joker.com. They seem to support IPv6
glue records as well and seem to have an office in Zug!

Daniel
On 23.05.14 10:04, Benoit Panizzon wrote:
 Hello
 
 I'm on a task that turn out to be harder that I expected.
 
 From switch.ch registered .ch domains I'm used to be able to specify the IPv6 
  
 addresses of my DNS servers and to upload the DS keys needed for the DNSSEC 
 chain.
 
 Now I would like to do the same for a .com domain.
 
 But as of today I could not find any registrar (maybe except of godaddy, but 
 I 
 want to avoid them) that is able to do both, IPv6 and DNSSEC.
 
 I'm looking for a registrar for a .com domain who is able to publish IPv6 
 addresses for the DNS glue records and does allow DS records to be set. 
 Preferalby in switzerland or at lease one which offers minimum support in 
 case 
 of troubles.
 
 Which ones can your recommend?
 
 -Benoit-
 
 
 ___
 swinog mailing list
 swinog@lists.swinog.ch
 http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog
 


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog

Re: [swinog] nic.ch no NS

[Daniel Stirnimann]

nic.ch is in the ch zone itself. So it's not a zone of its own.

You will find it in whois so that people see that it's not available
anymore.

btw. SOA record reveals that:

dig nic.ch soa

;  DiG 9.8.5-P1  nic.ch soa
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 28601
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;nic.ch.IN  SOA

;; AUTHORITY SECTION:
ch. 3582IN  SOA a.nic.ch. helpdesk.nic.ch. 
2014050715 900 600 1209600 3600


Daniel,
SWITCH


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog