Chris Thompson | 28 Aug 14:38 2014
Picon
Picon

First new gTLD using ICANN's "Name Collision Occurrence Management Framework"

The gTLD "otsuka", created sometime in the last 24 hours, appears to be the
first to use the wildcards described at

https://www.icann.org/news/announcement-2-2014-08-01-en  https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf

That is, it contains

*.otsuka.  3600  IN  A    127.0.53.53
*.otsuka.  3600  IN  TXT  "Your DNS configuration needs immediate attention see https://icann.org/namecollision"
*.otsuka.  3600  IN  SRV  10 10 0 your-dns-needs-immediate-attention.otsuka.
*.otsuka.  3600  IN  MX   10 your-dns-needs-immediate-attention.otsuka.

and the corresponding RRSIGs.

What do people think about this business? Is anyone taking specific precautions
to detect attempts to connect to 127.0.53.53?

--

-- 
Chris Thompson               University of Cambridge Information Services,
Email: cet1@...    Roger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715       Cambridge CB3 0RB, United Kingdom.
Carsten Strotmann | 27 Aug 12:49 2014
Picon

DNSSEC "strict" mode useful?

Hello,

Would a DNSSEC "strict" mode in DNS resolver software be useful?

I define DNSSEC "strict" mode as a mode of DNS resolver operation where
only DNSSEC validated data will be returned.

Today the default mode of operation is to return data with AD flag for
validated data, SERVFAIL for validation failures, and data without AD
flag for all insecure data (no DNSSEC trust chain).

A DNS resolver in "strict" mode would never return data without AD flag
to a client. So either data + AD flag or SERVFAIL.

Use-cases:

DNSSEC "strict" mode is not to be used for generic DNS name resolution
in the public internet but

* in closed DNS environments with different parties, where by policy all
  DNS must be DNSSEC secured

* for a service in the public Internet where it is known that all DNS
  communication must be DNSSEC secured

Today such a "strict" mode configuration is possible by configuring
explicit trust anchor(s) for every domain to be secured. However this does
not scale. 

In my view it would be useful to have a configuration switch to tell a
(Continue reading)

Keith Mitchell | 27 Aug 21:40 2014
Picon

DNS-OARC Fall 2014 Workshop - Los Angeles, California, 11th-13th October

Here's a reminder that public registration for OARC's Fall Workshop and
Member AGM is open. This will take place on the 11th to 13th October, in
Los Angeles, California, USA, and will be held jointly with the ICANN
ccNSO Tech Day.

This will be held at the same location (Hyatt Regency Century Plaza) as
the ICANN51 meeting - we're grateful to Microsoft for once again being
our Platinum and Social sponsor for this workshop, and to ICANN for
being Meeting Host.

You can find more information about the workshop at:

   https://indico.dns-oarc.net/event/workshop-2014-10

Registration is open at:

   https://indico.dns-oarc.net/confRegistrationFormDisplay.py?confId=20

as we are likely limited to 120 places for this workshop, priority may
be given to speakers, sponsors, and OARC members, so early registration
is recommended.

We have a very strong agenda for this meeting, you can see presentations
as we confirm them at:

   https://indico.dns-oarc.net/contributionListDisplay.py?confId=20

Due to heavy demand for accommodation in the area during ICANN week, we
have arranged a reserved block of rooms for Workshop attendees at
the nearby Crowne Plaza Beverley Hills, which is about 1.5 miles away
(Continue reading)

Calin Nemes | 21 Aug 02:45 2014
Picon

Virgin Media (AS5089)

Hi,

Anyone from Virgin Media that is on this list mind sending me an email offline?

Regards,
Calin
<div><div dir="ltr">
<div class="gmail_default">Hi,</div>
<div class="gmail_default"><br></div>
<div class="gmail_default">
Anyone from Virgin Media that is on this list mind sending me an email offline?</div>
<div class="gmail_default"><br></div>
<div class="gmail_default">
Regards,</div>
<div class="gmail_default">Calin</div>
</div></div>
German Hoeffner | 16 Aug 00:34 2014

Hello from the dns.watch project!


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello everyone!

First of all, a short introduction of myself: My name is German Hoeffner
and I'm working for companies in the hosting sector. One of those
companies is Ideal-Hosting which I am also a shareholder of.
Ideal-Hosting UG (haftungsbeschränkt) is a hosting company located in
Germany, which has (fortunately) very strict data privacy law. We're
involved in many projects which we think the "Internet community"
benefits of.

I've recently been informed that dns.watch was discussed on this mailing
list some time ago. I went through the archive thread (which you can
find here:
https://lists.dns-oarc.net/pipermail/dns-operations/2014-July/011948.html)
and noticed that there are some open questions.

Q: Who is operating DNS.WATCH?
A: Ideal-Hosting is operating the DNS.WATCH Project as a not-for-profit
project. It's important to us that the users and people who are
interested in the project know who is running DNS.WATCH and that they
can reach us in case any they have any questions or issues with our service.

Q: Why are the resolvers slow from certain locations?
A: While we're operating an excellent network in Frankfurt, Germany,
we're not anycasted (yet). We already have specific plans on anycasting
the resolvers and it should go live later this year. However, we will
continue to offer explicit Germany only resolver addresses, as this is
important for some people.

Q: Why is DNSSEC not enabled on dns.watch
A: It is currently not possible for us to set DNSSEC (DS) entries with
the domain api of our registrar. As soon as this is possible, we'll
start using DNSSEC.

Thanks again for all the suggestions and comments on the first thread.
We take all feedback serious, as you can see we've now enabled mail on
the domain as well.

Questions, anyone?

- -- 
Sincerely,
German Hoeffner

DNS.WATCH Administrator
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT7osCAAoJEFXDutqVVa2xJc0H/212nUv/ddkWmfQsfW6xdFAB
SHDMML20UmJEcsvp4lUzIWhSZeohyn0LTFEe4OsyfJNsYWN2tsk0ZCKyRbRdOrmK
PdoLurxkezO18W7wJwJZeVkFBP/1UEMHG5E/uMnUXPPUEstDOJkZulkPV/NxSMqt
CFf7YG6g0Z3nWLH9NZ85oOlcHAS0XnFVz5ej1BoymqVYSMQtO6OPtpXZ3RYwsCz2
J6er2njYK+1bY5AtJGYIbPEhT4xvlquuPbKHsqPPoQTas2ZzRx41surcPff5XIgi
Ifi5ghfP240wgOImoJcIHODyjk7+YMukm5iWR3nUYgF+6GfQMt7hnAVmNr/4i6A=
=l9QH
-----END PGP SIGNATURE-----

Jake Zack | 14 Aug 19:48 2014
Picon

DNS load-balancing/failover using an ASR 9xxx (few questions)

Anyone doing this?

 

Previously I’d been using Cisco 3945’s and 3845’s running standard IOS…thus using Cisco IP SLA + track to do DNS queries of each server and add/remove them from the cluster.

 

In the ASR 9xxx series with IOS XR, the “ipsla” that it has available doesn’t seem to do either TCP connections or UDP DNS queries.  It seems my only real option is to monitor for ICMP reachability and nothing else.

 

Anyone have a better solution?  I’ve considered throwing a wrapper around BIND doing OSPF updates and such…but it seems unideal.

 

-Jake

DNS Administrator – CIRA (.CA TLD)

<div>
<div class="WordSection1">
<p class="MsoNormal">Anyone doing this?<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Previously I&rsquo;d been using Cisco 3945&rsquo;s and 3845&rsquo;s running standard IOS&hellip;thus using Cisco IP SLA + track to do DNS queries of each server and add/remove them from the cluster.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">In the ASR 9xxx series with IOS XR, the &ldquo;ipsla&rdquo; that it has available doesn&rsquo;t seem to do either TCP connections or UDP DNS queries.&nbsp; It seems my only real option is to monitor for ICMP reachability and nothing else.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Anyone have a better solution?&nbsp; I&rsquo;ve considered throwing a wrapper around BIND doing OSPF updates and such&hellip;but it seems unideal.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">-Jake<p></p></p>
<p class="MsoNormal">DNS Administrator &ndash; CIRA (.CA TLD)<p></p></p>
</div>
</div>
Davey Song | 13 Aug 03:13 2014
Picon

About EDNS0

Hi, everybody

I’m a newbie on this mailing list. Hope you guys forgive my carelessness on previous discussion on the same question. 

My question is that I heard that EDNS0 does not work well because the misbehavior of mid-box like firewall or IPS which degrade the function of EDNS0. I wondering if there is any measurement report or statistic which support this point and show how severe it is. 

Thank you!
Davey

<div><div dir="ltr">
<div>Hi, everybody</div>
<div><br></div>
<div>I&rsquo;m a newbie on this mailing list. Hope you guys forgive my carelessness on previous discussion on the same question.&nbsp;</div>
<div><br></div>
<div>My question is that I heard that EDNS0 does not work well because the misbehavior of mid-box like firewall or IPS which degrade the function of EDNS0. I wondering if there is any measurement report or statistic which support this point and show how severe it is.&nbsp;</div>
<div><br></div>
<div>Thank you!</div>
<div>Davey</div>
<div><br></div>
</div></div>
Stephane Bortzmeyer | 12 Aug 18:59 2014
Picon

A report on a DNS issue that was causing page redirections

Long and technically detailed story of a big DNS blunder, with
unexpected consequences:

http://blog.qbaka.com/post/94537269389/a-report-on-a-dns-issue-that-was-causing-page

The author says "your domain name registrar can introduce an error to
the root domain database and match your domain to an incorrect DNS
servers (this actually happened earlier in history of some domain
registrars)" but my human memory cannot find an actual documented
case. Anyone can mention one or was it just speculation?

DNSSEC would have mitigated the problem if the domain had been
properly managed, which was apparently not the case.

George Michaelson | 7 Aug 02:14 2014
Picon

Re: Curious use of cname

we all said symlinks were a bad idea when Berkeley did them. We also all use them. The properties OF the symlink matter more than people realize, because 99% of the time, they care about the properties of the object pointed to by the symlink.

when Sun added ${symbolic} expansion on the fly to symlinks we all said it was a bad idea.. I dont think many of us use that any more much.

oh sorry: did I say symlink? I meant CNAME. Morally, the DNSSEC sigs over the CNAME are like the properties of the symlink. All the rest is about the target.




On Thu, Aug 7, 2014 at 10:06 AM, Andrew Sullivan <ajs-RsVSZkj6gwlUdzlNrMYSsNBPR1lH4CV8@public.gmane.org> wrote:
On Thu, Aug 07, 2014 at 07:51:53AM +1000, Mark Andrews wrote:
> Those with developers that don't read RFC 1034 which tried to prevent
> this from happening.

You're probably right.  But of course, RFC 1034 was written a number
of years ago, and some of the protocol-specification language that
later became well-understood isn't used in it.  In particular,

> RR.  If a CNAME RR is present at a node, no other data should be
> present; this ensures that the data for a canonical name and its aliases
> cannot be different.

this makes it sound like "nothing at a CNAME but a CNAME is a good
idea" instead of "if you have a CNAME, that means by definition
nothing else can be there."  To a naïve reader, the text above might
read as, "You shouldn't do this, but you could.  But it'd have a bad
consequence, and you don't want that, right?"  What it should say, of
course, is more like, "CNAME just means that the name you looked up is
actually some other name, therefore there MUST be no other data at the
owner name of a CNAME."  Something like that.

I've talked to people who've been facile with the DNS for a number of
years, who didn't get that this wasn't some arbitrary rule, but was
the very meaning of "canonical name".  If you explain it, the lights
always go on.  But RFC 1034 does a poor job of explaining it.

<div>
<div dir="ltr">we all said symlinks were a bad idea when Berkeley did them. We also all use them. The properties OF the symlink matter more than people realize, because 99% of the time, they care about the properties of the object pointed to by the symlink.<div>
<br>
</div>
<div>when Sun added ${symbolic} expansion on the fly to symlinks we all said it was a bad idea.. I dont think many of us use that any more much.</div>
<div><br></div>
<div>oh sorry: did I say symlink? I meant CNAME. Morally, the DNSSEC sigs over the CNAME are like the properties of the symlink. All the rest is about the target.</div>
<div><br></div>
<div><br></div>
</div>
<div class="gmail_extra">
<br><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 10:06 AM, Andrew Sullivan <span dir="ltr">&lt;<a href="mailto:ajs@..." target="_blank">ajs@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<div class="">On Thu, Aug 07, 2014 at 07:51:53AM +1000, Mark Andrews wrote:<br>
&gt; Those with developers that don't read RFC 1034 which tried to prevent<br>
&gt; this from happening.<br><br>
</div>You're probably right. &nbsp;But of course, RFC 1034 was written a number<br>
of years ago, and some of the protocol-specification language that<br>
later became well-understood isn't used in it. &nbsp;In particular,<br><div class="">
<br>
&gt; RR. &nbsp;If a CNAME RR is present at a node, no other data should be<br>
&gt; present; this ensures that the data for a canonical name and its aliases<br>
&gt; cannot be different.<br><br>
</div>this makes it sound like "nothing at a CNAME but a CNAME is a good<br>
idea" instead of "if you have a CNAME, that means by definition<br>
nothing else can be there." &nbsp;To a na&iuml;ve reader, the text above might<br>
read as, "You shouldn't do this, but you could. &nbsp;But it'd have a bad<br>
consequence, and you don't want that, right?" &nbsp;What it should say, of<br>
course, is more like, "CNAME just means that the name you looked up is<br>
actually some other name, therefore there MUST be no other data at the<br>
owner name of a CNAME." &nbsp;Something like that.<br><br>
I've talked to people who've been facile with the DNS for a number of<br>
years, who didn't get that this wasn't some arbitrary rule, but was<br>
the very meaning of "canonical name". &nbsp;If you explain it, the lights<br>
always go on. &nbsp;But RFC 1034 does a poor job of explaining it.<br><div class="HOEnZb"><div class="h5">
<br>
Best regards,<br><br>
A<br><br>
--<br>
Andrew Sullivan<br><a href="mailto:ajs@...">ajs@...</a><br>
_______________________________________________<br>
dns-operations mailing list<br><a href="mailto:dns-operations@...">dns-operations <at> lists.dns-oarc.net</a><br><a href="https://lists.dns-oarc.net/mailman/listinfo/dns-operations%0Adns-jobs" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-operations<br>
dns-jobs</a> mailing list<br><a href="https://lists.dns-oarc.net/mailman/listinfo/dns-jobs" target="_blank">https://lists.dns-oarc.net/mailman/listinfo/dns-jobs</a>
</div></div>
</blockquote>
</div>
<br>
</div>
</div>
intdnsops intdnsops | 7 Aug 00:24 2014
Picon

resolvers - which do you care about?

We are working on a DNS consistency check tool tool and a component
includes checking several public recursive name servers for the latest
SOA/A/AAAA records and TTLs. The zones we publish often have TTLs
measured in the 7+ day range, changes are incredibly low volume, and
we always plan on waiting out the TTL. Of all the public resolvers in
the wild - which ones do you care about? While some services like
OpenDNS & Google provide a web based interface to issue a cache clear
- do any services offer an API style cache clear/zone drop?

If providing a list of resolvers you care about, please limit to open
resolvers and resolvers that provide a web based cache check tool.

Best regards.
John Wobus | 6 Aug 20:15 2014
Picon

Curious use of cname

 From everything I know, this is wrong and it's apparently making our
nameservers give inconsistent results.  What nameserver allows
this and what might they be attempting to accomplish?

John Wobus
Cornell University IT

dig +norecurs mx cjsarchitects.com  <at> dns3.name-services.com.

; <<>> DiG 9.4.3-P3 <<>> +norecurs mx cjsarchitects.com  <at> dns3.name- 
services.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37294
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cjsarchitects.com.		IN	MX

;; ANSWER SECTION:
cjsarchitects.com.	1800	IN	MX	20 mx2.emailsrvr.com.
cjsarchitects.com.	1800	IN	MX	10 mx1.emailsrvr.com.

;; Query time: 22 msec
;; SERVER: 98.124.193.1#53(98.124.193.1)
;; WHEN: Wed Aug  6 14:08:34 2014
;; MSG SIZE  rcvd: 85

dig +norecurs a cjsarchitects.com  <at> dns3.name-services.com.

; <<>> DiG 9.4.3-P3 <<>> +norecurs a cjsarchitects.com  <at> dns3.name- 
services.com.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26019
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cjsarchitects.com.		IN	A

;; ANSWER SECTION:
cjsarchitects.com.	1800	IN	CNAME	ext.squarespace.com.

;; Query time: 18 msec
;; SERVER: 98.124.193.1#53(98.124.193.1)
;; WHEN: Wed Aug  6 14:08:34 2014
;; MSG SIZE  rcvd: 65


Gmane