Zoltán Vigh | 30 May 11:30 2016
Picon

AXFR misconfiguration mail

Hi Everybody,


I would like to apologize to everybody. I made a mistake when I sent an email to DNS providers. I only  wanted to call everyone's attention the AXFR misconfiguration. It won’t happen again.


I accepted your opinion. Axfr transfer is not problem, it is a matter of personal choice.


<at> Dave Warren: Thank you for your opinion!


Regards,


Zoltán Vigh

<div><div dir="ltr">
<span><p dir="ltr"><span>Hi Everybody,</span></p>
<br><p dir="ltr"><span>I would like to apologize to everybody. I made a mistake when I sent an email to DNS providers. I only &nbsp;wanted to call everyone's attention the AXFR misconfiguration. It won&rsquo;t happen again. </span></p>
<br><p dir="ltr"><span>I accepted your opinion. Axfr transfer is not problem, it is a matter of personal choice.</span></p>
<br><p dir="ltr"><span> <at> Dave Warren: Thank you for your opinion!</span></p>
<p dir="ltr"><br></p>
<p dir="ltr"><span>Regards,</span></p>
<br><span>Zolt&aacute;n Vigh</span></span><br>
</div></div>
Stephane Bortzmeyer | 29 May 10:35 2016
Picon

hello@...: AXFR Securit - alert - XXXXXX.fr]

We received this since, apparently, they send email to every email
address in the changed: attribute of the whois output :-( (I'm not
involved in the management of this domain name.)

Does anyone know these people who spread FUD about AXFR-enabled
domains?

----- Forwarded message from AXFR Check Team <hello@...> -----

Date: Sun, 29 May 2016 07:22:38 +0000 (UTC)
From: AXFR Check Team <hello@...>
To: [many unrelated email addresses]
Subject: AXFR Securit - alert - XXXXXX.fr

   Dear XXXXXX.fr DNS Provider,
   Our research team found some security issue in some of your DNS server
   configurations. These misconfigured DNS are very vulnerable, and easy
   to abuse.

   Here are some of potential affected DNS for example:
   ns.XXXXXX.fr

   Affected domains actually:
   1

   About DNS Zone Transfer AXFR Requests May Leak Domain Information:

   https://www.us-cert.gov/ncas/alerts/TA15-103A

   Check affected DNS and domains on AXFR CHECK API
   http://api.axfrcheck.com/api/provider/XXXXXX.fr

   You can fix the problem if you disbale AXFR transfer on your dns
   servers.

   For example:

   BIND:

   allow-transfer {"none";};

   PowerDNS:

   disable-axfr=yes

   If you need help to configure the setting correctly, reply to this
   email, and we will help you.

   Who we are?
   [1]axfrcheck.com

   If we helped you, or you want to support our work, please [2]DONATE us,
   to help the web a more secure place!

   Regards,
   Zoltan Vigh

   Twitter: [3] <at> ptzool

   LinkedIn: [4]https://hu.linkedin.com/in/zvigh

   AXFR Check Team

References

   1. http://axfrcheck.com/
   2. http://axfrcheck.com/
   3. https://twitter.com/ptZool
   4. https://hu.linkedin.com/in/zvigh

----- End forwarded message -----
Stephane Bortzmeyer | 27 May 10:44 2016
Picon

tjw.ietf@...: Working Group Last Call: draft-ietf-dnsop-nxdomain-cut]

This proposal may have practical consequences for DNS operations so
people on this list may want to read the draft and to report opinions
on the DNSOP working group mailing list (not to be confused with this
dns-operations mailing list).
Picon
From: Tim Wicinski <tjw.ietf@...>
Subject: Working Group Last Call: draft-ietf-dnsop-nxdomain-cut
Date: 2016-05-26 12:53:06 GMT
There has been some good discussion from the working group on the list, 
and with the recent discussion on root server tar pitting, it makes 
sense to move this document along.

This starts a Working Group Last Call for draft-ietf-dnsop-nxdomain-cut

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/

This is a Standards Track document.

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

This starts a two week Working Group Last Call process, and ends at 
midnight 10 June 2016.

thanks
tim

_______________________________________________
DNSOP mailing list
DNSOP@...
https://www.ietf.org/mailman/listinfo/dnsop
There has been some good discussion from the working group on the list, 
and with the recent discussion on root server tar pitting, it makes 
sense to move this document along.

This starts a Working Group Last Call for draft-ietf-dnsop-nxdomain-cut

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-nxdomain-cut/

This is a Standards Track document.

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

This starts a two week Working Group Last Call process, and ends at 
midnight 10 June 2016.

thanks
tim

_______________________________________________
DNSOP mailing list
DNSOP@...
https://www.ietf.org/mailman/listinfo/dnsop
Stephane Bortzmeyer | 22 May 17:18 2016
Picon

More DNSSEC validators to expect

New version of Linux' systemd has DNSEC validation enabled by default:

http://news.softpedia.com/news/systemd-230-launches-with-dnssec-enabled-by-default-in-systemd-resolved-more-504339.shtml
Jacques Latour | 18 May 22:43 2016
Picon

TLD Monitoring Tools

Hi,

I'm putting a list of TLD monitoring tools as a resource for all and TLDOPS group, got a couple example below,
if you know of a good tools, please let me know.  Anything that provides insight on the TLD.

DNSSEC Checker:
     DNSvis - 			http://dnsviz.net/d/ca/dnssec/

     DNSSEC Early warning: 	http://www.dnssek.info/

DNS STATUS: 
     DNS-OARC TLD Monitoring     https://tldmon.dns-oarc.net/nagios/ 

     RIPE Atlas DNS Monitoring      https://atlas.ripe.net/dnsmon 

SECURITY TOOLS/API/REPORT:
     ?

Thanks,

Jacques

万润夏 | 18 May 08:44 2016
Picon

Tools to assemble fragments

Hi, everyone,

I am doing a data analysis work for the queries and responses captured in my recursive server. I find the DNS data has some fragments due to large DNS package and it is tricky to assemble them. Would anyone tell me any works of assembling IP layer fragments or any tools to parse DNS message from tcpdump/dnscap data?



Best

Runxia Wan


---------------
Runxia Wan(Brian)

Research Engineer
BII Lab

Beijing Internet Institute(BII)

rxwan <at> biigroup.cn

<div>

<p dir="LTR" align="JUSTIFY"><span lang="en-us">Hi, everyone,</span></p>

<p dir="LTR" align="JUSTIFY"><span lang="en-us">I am doing a</span><span lang="en-us"> data analysis work for the queries and responses captured in my recursive server. I find the DNS data</span><span lang="en-us"> has some fragments</span><span lang="en-us"> due to large DNS package</span><span lang="en-us"> and it is tricky to assemble them. Would anyone tell me any works of assembling IP layer fragments</span><span lang="en-us"> or any tools to parse DNS message from</span><span lang="en-us"> tcpdump/dnscap data</span><span lang="en-us">?</span><span lang="en-us"></span></p>

<p dir="LTR" align="JUSTIFY"><span lang="en-us"></span></p>
<br><br><p dir="LTR" align="JUSTIFY"><span lang="en-us">B</span><span lang="en-us">est</span></p>

<p dir="LTR" align="JUSTIFY"><span lang="en-us">Runxia Wan</span><span lang="en-us"></span></p>

<p dir="LTR"><span lang="en-us"></span><span lang="en-us"></span><span lang="zh-cn"><br>---------------<br>Runxia Wan(Brian)</span></p>

<p dir="LTR"><span lang="zh-cn">Research Engineer<br>
BII Lab</span></p>

<p dir="LTR"><span lang="zh-cn">Beijing Internet Institute(BII)</span></p>

<p dir="LTR"><span lang="en-us"></span><span lang="en-us"></span><span lang="zh-cn">rxwan <at> biigroup.cn</span><span lang="en-us"></span><span lang="en-us"></span><span lang="zh-cn"></span></p>

<p dir="LTR" align="JUSTIFY"><span lang="en-us"></span><span lang="zh-cn"></span></p>

<p dir="LTR" align="JUSTIFY"><span lang="en-us"></span></p>

</div>
RunxiaWan | 18 May 08:50 2016

Tools to assemble fragments

Hi, everyone,

I am doing a data analysis work for the queries and responses captured in my recursive server. I find the DNS data has some fragments due to large DNS package and it is tricky to assemble them. Would anyone tell me any works of assembling IP layer fragments or any tools to parse DNS message from tcpdump/dnscap data?



Best

Runxia Wan


---------------
Runxia Wan(Brian)

Research Engineer
BII Lab

Beijing Internet Institute(BII)

rxwan-5xNe+R/M6j3M1kAEIRd3EQ@public.gmane.org

<div>

<p dir="LTR" align="JUSTIFY"><span lang="en-us">Hi, everyone,</span></p>

<p dir="LTR" align="JUSTIFY"><span lang="en-us">I am doing a data analysis work for the queries and responses captured in my recursive server. I find the DNS data has some fragments due to large DNS package and it is tricky to assemble them. Would anyone tell me any works of assembling IP layer fragments or any tools to parse DNS message from tcpdump/dnscap data?</span></p>
<br><br><p dir="LTR" align="JUSTIFY"><span lang="en-us"></span></p>

<p dir="LTR" align="JUSTIFY"><span lang="en-us">Best</span></p>

<p dir="LTR" align="JUSTIFY"><span lang="en-us">Runxia Wan</span></p>

<p dir="LTR"><span lang="en-us"></span><span lang="en-us"></span><span lang="zh-cn"><br>---------------<br>Runxia Wan(Brian)</span></p>

<p dir="LTR"><span lang="zh-cn">Research Engineer<br>
BII Lab</span></p>

<p dir="LTR"><span lang="zh-cn">Beijing Internet Institute(BII)</span></p>

<p dir="LTR"><span lang="en-us"></span><a href="mailto:rxwan@..."><span lang="en-us"></span><span lang="en-us"></span><span lang="zh-cn"></span><span lang="zh-cn">rxwan@...</span><span lang="en-us"></span></a><span lang="en-us"></span><span lang="en-us"></span><span lang="zh-cn"></span></p>

</div>
Sue Graves | 18 May 04:27 2016
Picon

The DNS-OARC facility relocation is complete

Thanks for your patience during this time.

Please let us know if you notice any issues with any of our services or
connectivity.

Best Regards,
Sue
Julie Hedlund | 12 May 20:02 2016
Picon

REMINDER: Call for Participation -- ICANN DNSSEC Workshop at ICANN 56 in Helsinki, Finland

REMINDER: Call for Participation -- ICANN DNSSEC Workshop at ICANN 56 in Helsinki, Finland

 

The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN 56 meeting on 27 June 2016 in Helsinki, Finland.  The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.  For reference, the most recent session was held at the ICANN meeting in Marrakech, Morocco on 09 March 2016. The presentations and transcripts are available at:  https://meetings.icann.org/en/marrakech55/schedule/wed-dnssec.

 

Examples of the types of topics we are seeking include:

 

1. DNSSEC Deployment Challenges

 

The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC.  In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the nature:

— What are your most significant concerns with DNSSEC, e.g., implementation, operation or something else?

— What do you expect DNSSEC to do for you and what doesn't it do?

— What do you see as the most important trade-offs with respect to doing or not doing DNSSEC?

 

We are interested in presentations related to any aspect of DNSSEC such as zone signing, DNS response validation, applications use of DNSSEC, registry/registrar DNSSEC activities, etc.

 

2.  DNSSEC by Default

 

As more and more applications and systems are available with DNSSEC enabled by default, the vast majority of today’s applications support DNSSEC but are not DNSSEC enabled by default.    Are we ready to enable DNSSEC by default in all applications and services. We are interested in presentations by implementors on the reasoning that led to enable DNSSEC by default in their product or service.  We are also interested in understanding  those that elected not to enable DNSSEC by default and why, and what their plans are.

 

3. DNSSEC Encryption Algorithms

 

How do we make DNSSEC even more secure through the use of elliptic curve cryptography? What are the advantages of algorithms based on elliptic curves? And what steps need to happen to make this a reality? What challenges lie in the way?  Over the past few months there have been discussions within the DNSSEC community about how we start down the path toward adding support for new cryptographic algorithms such as Ed25519 and Ed448. At ICANN 55 in Marrakech we had a panel session that explored why elliptic curve cryptography was interesting and some high level views on what needs to happen.  At ICANN 56 we are interested in presentations that dive into greater detail about what needs to be done and how we start the process. More background information can be found in this document: https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/

 

In addition, we welcome suggestions for additional topics.

 

If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to dnssec-helsinki-pYXoxzOOsG8@public.gmane.org by **Wednesday, 18 May 2016**

 

We hope that you can join us.

 

Thank you,

Julie Hedlund

 

On behalf of the DNSSEC Workshop Program Committee:

 

Mark Elkins, DNS/ZACR

Cath Goulding, Nominet UK

Jean Robert Hountomey, AfricaCERT

Jacques Latour, .CA

Xiaodong Lee, CNNIC

Luciano Minuchin, NIC.AR

Russ Mundy, Parsons

Ondřej Surý, CZ.NIC

Yoshiro Yoneya, JPRS

Dan York, Internet Society

Attachment (smime.p7s): application/pkcs7-signature, 6262 bytes
<div><div class="WordSection1">
<p class="MsoNormal"><span>REMINDER: Call for Participation -- ICANN DNSSEC Workshop at ICANN 56 in Helsinki, Finland<p></p></span></p>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN 56 meeting on 27 June 2016 in Helsinki, Finland.&nbsp;&nbsp;The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments.&nbsp;&nbsp;For reference, the most recent session was held at the ICANN meeting in Marrakech, Morocco on 09 March 2016. The presentations and transcripts are available at:&nbsp;&nbsp;<a href="https://meetings.icann.org/en/marrakech55/schedule/wed-dnssec">https://meetings.icann.org/en/marrakech55/schedule/wed-dnssec</a>. <p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>Examples of the types of topics we are seeking include:<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>1. DNSSEC Deployment Challenges<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>The program committee is seeking input from those that are interested in implementation of DNSSEC but have general or particular concerns with DNSSEC.&nbsp;&nbsp;In particular, we are seeking input from individuals that would be willing to participate in a panel that would discuss questions of the nature:<p></p></span></p></div>
<div><p class="MsoNormal"><span>&mdash; What are your most significant concerns with DNSSEC, e.g., implementation, operation or something else?<p></p></span></p></div>
<div><p class="MsoNormal"><span>&mdash; What do you expect DNSSEC to do for you and what doesn't it do?<p></p></span></p></div>
<div><p class="MsoNormal"><span>&mdash; What do you see as the most important trade-offs with respect to doing or not doing DNSSEC?<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>We are interested in presentations related to any aspect of DNSSEC such as zone signing, DNS response validation, applications use of DNSSEC, registry/registrar DNSSEC activities, etc.<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>2.&nbsp;&nbsp;DNSSEC by Default<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>As more and more applications and systems are available with DNSSEC enabled by default, the vast majority of today&rsquo;s applications support DNSSEC but are not DNSSEC enabled by default.&nbsp;&nbsp;&nbsp;&nbsp;Are we ready to enable DNSSEC by default in all applications and services. We are interested in presentations by implementors on the reasoning that led to enable DNSSEC by default in their product or service.&nbsp;&nbsp;We are also interested in understanding&nbsp;&nbsp;those that elected not to enable DNSSEC by default and why, and what their plans are.<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>3. DNSSEC Encryption Algorithms<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>How do we make DNSSEC even more secure through the use of elliptic curve cryptography? What are the advantages of algorithms based on elliptic curves? And what steps need to happen to make this a reality? What challenges lie in the way?&nbsp;&nbsp;Over the past few months there have been discussions within the DNSSEC community about how we start down the path toward adding support for new cryptographic algorithms such as Ed25519 and Ed448. At ICANN 55 in Marrakech we had a panel session that explored why elliptic curve cryptography was interesting and some high level views on what needs to happen.&nbsp;&nbsp;At ICANN 56 we are interested in presentations that dive into greater detail about what needs to be done and how we start the process. More background information can be found in this document:&nbsp;<a href="https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/">https://datatracker.ietf.org/doc/draft-york-dnsop-deploying-dnssec-crypto-algs/</a><p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>In addition, we welcome suggestions for additional topics.<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>If you are interested in participating, please send a brief (1-2 sentence) description of your proposed presentation to <a href="mailto:dnssec-helsinki@...">dnssec-helsinki@...</a> by **Wednesday, 18 May 2016**≤p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>We hope that you can join us.<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>Thank you,<p></p></span></p></div>
<div><p class="MsoNormal"><span>Julie Hedlund<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>On behalf of the DNSSEC Workshop Program Committee:<p></p></span></p></div>
<div><p class="MsoNormal"><span><p>&nbsp;</p></span></p></div>
<div><p class="MsoNormal"><span>Mark Elkins, DNS/ZACR<p></p></span></p></div>
<div><p class="MsoNormal"><span>Cath Goulding, Nominet UK<p></p></span></p></div>
<div><p class="MsoNormal"><span>Jean Robert Hountomey, AfricaCERT<p></p></span></p></div>
<div><p class="MsoNormal"><span>Jacques Latour, .CA<p></p></span></p></div>
<div><p class="MsoNormal"><span>Xiaodong Lee, CNNIC<p></p></span></p></div>
<div><p class="MsoNormal"><span>Luciano Minuchin, NIC.AR<p></p></span></p></div>
<div><p class="MsoNormal"><span>Russ Mundy, Parsons<p></p></span></p></div>
<div><p class="MsoNormal"><span>Ond&#345;ej Sur&yacute;, CZ.NIC<p></p></span></p></div>
<div><p class="MsoNormal"><span>Yoshiro Yoneya, JPRS<p></p></span></p></div>
<div><p class="MsoNormal"><span>Dan York, Internet Society<p></p></span></p></div>
</div></div>
Sue Graves | 10 May 00:40 2016
Picon

Notice: DNS-OARC Systems Facility Relocation May 14-18th


Please be advised that DNS-OARC will be relocating its equipment and
services to a new facility during next week starting this Saturday,
May 14th thru Wednesday the 18th.  There will be multiple sporadic
outages during this time affecting ALL services and ALL systems as a
result.

The main public and OARC Member-facing services, including websites,
email, mailing lists, indico and jabber are planned to be re-located
on Sunday 15th, and we hope to keep the total outage down to a few
hours. Our dataset and analysis servers will be taken out of service
on Saturday 14th, and are planned to be back in service late Monday
16th or early Tuesday 17th. All work is planned to be performed during
daytime hours Pacific time (UTC-8).

During the outages, we will post system availability updates on
LinkedIn, Twitter, Facebook, Google+ and Jabber.

Another email confirming recommissioning status will be sent once
email is back up and until we are completed.

If you encounter any issues after we have announced services have been
restored, please contact us via the usual channels of e-mail to
<admin  <at>  dns-oarc.net>, phone to +1 650 423 1344, or on jabber.

Thanks in advance for your patience and cooperation, and our apologies
for any inconvenience this might unavoidably cause.
Once we are up and running in our new home we'll be in a strengthened
position to support and improve the quality, connectivity and growth
of our services to our Members and the DNS Community.

DNS-OARC Staff
~~~~
https://www.facebook.com/DNS-OARC-1706328039584929/?fref=ts

https://www.linkedin.com/groups/3193714

https://medium.com/dns-oarc-news

https://twitter.com/dnsoarc

https://plus.google.com/s/dns-oarc
Stephane Bortzmeyer | 9 May 10:12 2016
Picon

Re: domain has no MX record

On Sat, May 07, 2016 at 06:54:50AM +0800,
 support@...
<support@...> wrote 
 a message of 21 lines which said:

> when you click the subscribe button, the address is related to
> lists.ceph.com, like this one,
> ceph-users-join@...
> 
> but lists.ceph.com does have no MX setup.

OK, but it has a A, so it should work (RFC 5321, "If an empty list of
MXs is returned, the address is treated as if it was associated with
an implicit MX RR, with a preference of 0, pointing to that host"). If
it does not, it means the sending mail server is broken, as simple as
that.

Gmane