Randy Bush | 28 Jun 08:45 2015

Re: .MW inconsistent zone updates?

the occasional packet can get through

rip.psg.com:/root# ping 196.45.188.5
PING 196.45.188.5 (196.45.188.5): 56 data bytes
64 bytes from 196.45.188.5: icmp_seq=2 ttl=44 time=360.147 ms
64 bytes from 196.45.188.5: icmp_seq=55 ttl=44 time=377.265 ms
64 bytes from 196.45.188.5: icmp_seq=78 ttl=43 time=368.701 ms
64 bytes from 196.45.188.5: icmp_seq=82 ttl=43 time=369.133 ms
64 bytes from 196.45.188.5: icmp_seq=85 ttl=43 time=360.161 ms
64 bytes from 196.45.188.5: icmp_seq=91 ttl=44 time=359.521 ms
64 bytes from 196.45.188.5: icmp_seq=97 ttl=43 time=360.262 ms
64 bytes from 196.45.188.5: icmp_seq=99 ttl=44 time=360.025 ms
64 bytes from 196.45.188.5: icmp_seq=105 ttl=43 time=360.261 ms
64 bytes from 196.45.188.5: icmp_seq=108 ttl=44 time=358.269 ms
64 bytes from 196.45.188.5: icmp_seq=158 ttl=44 time=360.564 ms
^C
--- 196.45.188.5 ping statistics ---
164 packets transmitted, 11 packets received, 93.3% packet loss
round-trip min/avg/max/stddev = 358.269/363.119/377.265/5.672 ms

rip.psg.com:/root# traceroute 196.45.188.5
traceroute to 196.45.188.5 (196.45.188.5), 64 hops max, 52 byte packets
 1  psg0 (147.28.0.4)  0.297 ms  0.228 ms  0.120 ms
 2  ge-100-0-0-15.r05.sttlwa01.us.bb.gin.ntt.net (165.254.106.17)  0.732 ms  0.838 ms  0.614 ms
 3  be3048.ccr21.sea02.atlas.cogentco.com (154.54.11.9)  23.479 ms  22.984 ms  23.227 ms
 4  be2085.ccr21.slc01.atlas.cogentco.com (154.54.2.198)  31.595 ms  31.877 ms  31.835 ms
 5  be2126.ccr21.den01.atlas.cogentco.com (154.54.25.65)  42.463 ms
    be2127.ccr22.den01.atlas.cogentco.com (154.54.25.69)  45.835 ms
    be2126.ccr21.den01.atlas.cogentco.com (154.54.25.65)  42.331 ms
 6  be2128.ccr21.mci01.atlas.cogentco.com (154.54.25.174)  54.302 ms
(Continue reading)

Randy Bush | 28 Jun 08:38 2015

Re: .MW inconsistent zone updates?

rip.psg.com:/root# ping 196.45.188.5
PING 196.45.188.5 (196.45.188.5): 56 data bytes
^C
--- 196.45.188.5 ping statistics ---
9 packets transmitted, 0 packets received, 100.0% packet loss
rip.psg.com:/root# ping 41.221.99.135
PING 41.221.99.135 (41.221.99.135): 56 data bytes
^C
--- 41.221.99.135 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

and, of course

rip.psg.com:/root# dig  <at> 196.45.188.5
^Crip.psg.com:/root# dig  <at> 196.45.188.5 mw. axfr

; <<>> DiG 9.10.2 <<>>  <at> 196.45.188.5 mw. axfr
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

and a border router thinks

r0.sea#sh ip bg 196.45.188.5
BGP routing table entry for 196.45.188.0/24, version 44268490
BGP Bestpath: deterministic-med
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1          3         
  Refresh Epoch 1
(Continue reading)

Gunter Grodotzki | 25 Jun 10:23 2015
Picon

.MW inconsistent zone updates?

Hello,

I did a domain update last week on cheki.mw, but it seems like some OPs 
are either sleeping or their syncing is not really working ;)

The following auth-ns is still delivering a old record:
mw.            21599    IN    NS    rip.psg.com.

$ dig +nocomments ns cheki.mw  <at> rip.psg.com

; <<>> DiG 9.9.5-9-Debian <<>> +nocomments ns cheki.mw  <at> rip.psg.com
;; global options: +cmd
;cheki.mw.            IN    NS
cheki.mw.        86400    IN    NS ns-1722.awsdns-23.co.uk.
cheki.mw.        86400    IN    NS ns-1022.awsdns-63.net.
cheki.mw.        86400    IN    NS ns-1137.awsdns-14.org.
cheki.mw.        86400    IN    NS    ns-279.awsdns-34.com.
;; Query time: 356 msec
;; SERVER: 147.28.0.39#53(147.28.0.39)
;; WHEN: Thu Jun 25 10:21:58 SAST 2015
;; MSG SIZE  rcvd: 178

Others, like the following, show the correct entry:
mw.            21599    IN    NS    chambo.sdnp.org.mw.
$ dig +nocomments ns cheki.mw  <at> chambo.sdnp.org.mw

; <<>> DiG 9.9.5-9-Debian <<>> +nocomments ns cheki.mw  <at> chambo.sdnp.org.mw
;; global options: +cmd
;cheki.mw.            IN    NS
cheki.mw.        86400    IN    NS athena.ns.cloudflare.com.
(Continue reading)

Tony Finch | 23 Jun 18:03 2015
Picon

sibling glue

A question for those who know more about registry rules than me...

In the .example zone there can be five kinds of delegation NS record
(taking each record separately rather than the whole delegation NS RRset).
The requirements I am stating below are from the DNS point of view rather
than from the registry point of view.

glue-forbidden.example.		IN	NS	ns0.example.net.
;
; You must not provide glue when the name server host name is not a
; subdomain of the parent domain (.example in this case).

not-glue.example.		IN	NS	ns1.example.
;
; A child zone's name server host name can be in the authoritative data
; for the parent zone. This isn't glue.

glue-required.example.		IN	NS	ns2.glue-required.example.
;
; You must provide glue when a child zone has a name server whose host
; name is a subdomain of the child zone's apex.

; There are two cases where a child zone has a name server whose host name
; is a subdomain of a different sibling child zone of the same parent zone.

sibling-must-glue.example.	IN	NS	ns2.glue-required.example.
;
; The name server of this child zone can also be a name server of its
; sibling zone, in which case the sibling delegation must provide glue.

(Continue reading)

Sebastian Castro | 18 Jun 01:09 2015
Picon

Call for Presentations - DNS-OARC Fall Workshop, Oct 2015

The next DNS-OARC Fall Workshop will take place in Montreal on Oct 3rd
and 4th, the weekend before NANOG65. DNS-OARC is requesting proposals
for presentations, with a preference for DNSSEC work. We are looking for
the whole spectrum, from measurement work using passive and active
techniques, to applications and potential new uses of DNSSEC.

This workshop intends to build from previous strong DNS-OARC workshops,
where operational content and research is welcome. Presentations from
DNS operators are particularly welcome, as well as from DNS researchers.
All DNS-related subjects are accepted, introduction to new tools,
visualizations, data analysis, DNSSEC and novel uses of the DNS.  If you
are an DNS-OARC member, and have a sensitive topic you would like to
present for members-only, we will accommodate those talks too. Time will
be available for lighting talks to fit short presentations (5 to 10
minutes).

Workshop Milestones
17 June 2015, Call for Presentations posted
17 June 2015, Open for submissions
30 July 2015, Deadline for submission
20 August 2015, Final Program published
1 October 2015, Final deadline for slideset submission

Details for abstract submission will be published here:

        https://indico.dns-oarc.net/event/24/call-for-abstracts/

The workshop will be organized on different tracks, depending on the
topics and the timing of each presentation. If you are interested in a
lightning talk, let us know at the time of submission.
(Continue reading)

Kevin C. | 11 Jun 06:06 2015

about anti-ddos DNS hostings

Hello,

Sorry this subject may have no relations to DNS technology.
But one of our customers, who is a small registrar, has about 20,000 
domains in our systems, increase slowly by day.
Due to frequent DDoS we have no capability to help him, but suggest him 
move to another provider.
Do you know which provider has a good anti-ddos systems and with a low 
price for bulk zones? I will suggest him switch to there.

Thanks.
Edward Lewis | 10 Jun 13:07 2015
Picon

Trying - Re: Fwd: Re: [Security] Glue or not glue?

On 6/9/15, 20:29, "Mark E. Jeftovic" <markjr@...> wrote:

>But I don't see it happening.

(Caution - this all soapbox jibber-jabber:)

http://www.goodreads.com/quotes/854398-trying-is-the-first-step-towards-fai
lure

“Trying is the first step towards failure” -- Homer Simpson

http://www.imdb.com/character/ch0000015/quotes

"No. Try not. Do... or do not. There is no try." -- Yoda

Both characters are right.

The context is "some kind of name server operator protocol where ops can
have some degree of control over entities that get delegated to them."
That would be a good thing to have, I agree.

I am jumping on the pessimism of this never happening.  A dynamic I have
to deal with in the DNS hosting industry (of which I was part of) is that
operators tend to not share and give up too easily because the standards
process is too onerous.  I know because I've done that.  I was once told
"we are capitalists, not here to help our competition."

I'm in a different place now, a place where standards matter in policy
making, and thus matter more so than in operations.  When an operational
issue came up recently, the first question given back to the operators was
(Continue reading)

calvin | 10 Jun 12:16 2015
Picon

Re: Fwd: Re: [Security] Glue or not glue?

Mark Andrews wrote:
> Message: 7 Date: Wed, 10 Jun 2015 11:09:45 +1000 From: Mark Andrews 
> <marka@...> To: "Mark E. Jeftovic"
<markjr@...> Cc: 
> dns-operations@... Subject: Re: [dns-operations] Fwd: Re: 
> [Security] Glue or not glue? Message-ID: 
> <20150610010946.8A5E1304675D@...> <SNIP>
> It exists "dig SOA zone  <at> server" and if you get back a SOA record
> for the zone with the "aa" bit set then you are good to go.  This
> check is supposed to be made BEFORE the delegation is completed.
> Unfortunately people complain when a delegation is not completed
> in 0.0001ms after hitting submit so all checking just skipped.
In co.za we do this before delegating to NS's. The registration proceeds 
irrespective.
On EPP, we queue the checks, the legacy email interface it just gets 
rejected.

Do we get it in the neck:

"Don't tell us how to run our NS's"
"Our system doesn't work that way"
"We can't provision our NS's so fast"
"Our hosting provider won't put stuff in their NS's until it's in the 
Registry"
"No one else does this"

and others.....

>
> If you want this to change behavior sue the registry and registrar
(Continue reading)

Paul Wouters | 9 Jun 18:10 2015
Picon

.co broken for non-stock queries?


I noticed that the .co TLD servers seem to not respond to various
queries, eg:

dig +norecurse -t openpgpkey roessner.co.  <at> ns1.cctld.co.
dig +norecurse -t cds roessner.co.  <at> ns1.cctld.co.
dig +norecurse -t uri roessner.co.  <at> ns1.cctld.co.

It oddly enough does return answers for the private use range.

Anyone know of a .co contact to ask what's going on?

Paul

Edward Lewis | 9 Jun 16:55 2015
Picon

Downgrade attack readiness Re: DNSSEC issue - why?

On 6/9/15, 10:24, "Casey Deccio" <casey-76/tULC84t2sTnJN9+BGXg@public.gmane.org> wrote:

But when you consider a downgrade attack, the attacker only needs the lowest hanging fruit.  That means that *any* DS (regardless of DNSKEY) with the weaker digest type could potentially be used for falsifying a DNSKEY.

I'm just going to throw this on the mat - perhaps we've (and I mean the loose collective of folks involved with DNSSEC over the decades) had a poor understanding of downgrade attacks (how they happen, etc.) and have poorly addressed them. Given that I've never seen one (downgrade attack) work (in practice/in the field), I've never been able to reverse engineer it.  Having an academic/theoretic understanding is often times not sufficient.

Like learning to take down a spinnaker on a sailboat on a calm day in the dock and then expecting to execute the steps heeled over in a gale.  Or learning to change a diaper on a doll and then expecting to do the same for the first time in the back seat of a car. ;)  Those are two areas where cleanroom experience didn't translate to real world experience so much.

In general - has anyone seen an actual attack thwarted by DNSSEC?  Or an attack beat a DNSSEC defense?  Not looking to justify the investment, looking for the opportunity to reverse engineer.
Attachment (smime.p7s): application/pkcs7-signature, 6226 bytes
<div>
<div>On 6/9/15, 10:24, "Casey Deccio" &lt;<a href="mailto:casey@...">casey@...</a>&gt; wrote:</div>
<span><div><br></div>
<blockquote><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>But when you consider a downgrade attack, the attacker only needs the lowest hanging fruit.&nbsp; That means that *any* DS (regardless of DNSKEY) with the weaker digest type could potentially be used for falsifying a DNSKEY.</div></div></div></div></div></blockquote></span><div><br></div>
<div>I'm just going to throw this on the mat - perhaps we've (and I mean the loose collective of folks involved with DNSSEC over the decades) had a poor understanding of downgrade attacks (how they happen, etc.) and have poorly addressed them. Given that I've never seen one (downgrade attack) work (in practice/in the field), I've never been able to reverse engineer it. &nbsp;Having an academic/theoretic understanding is often times not sufficient.</div>
<div><br></div>
<div>Like learning to take down a spinnaker on a sailboat on a calm day in the dock and then expecting to execute the steps heeled over in a gale. &nbsp;Or learning to change a diaper on a doll and then expecting to do the same for the first time in the back seat of a car. ;) &nbsp;Those are two areas where cleanroom experience didn't translate to real world experience so much.</div>
<div><br></div>
<div>In general - has anyone seen an actual attack thwarted by DNSSEC? &nbsp;Or an attack beat a DNSSEC defense? &nbsp;Not looking to justify the investment, looking for the opportunity to reverse engineer.</div>
</div>
George Michaelson | 9 Jun 15:10 2015
Picon

Re: DNSSEC issue - why?



On 9 June 2015 at 14:53, Edward Lewis <edward.lewis-lcZ7/HtyLAbYtjvyW6yDsg@public.gmane.org> wrote:
On 6/9/15, 7:42, "Mark Andrews" <marka-2cKsPvgpMDY@public.gmane.org> wrote:
ents that can be referenced
separately (like in RFP's and contracts).  I found that trying to make
code prefer newer technologies over old by fiat seems to backfire (like
the way DNS used to prefer v6 over v4 and now seems to have reversed,
looking at some observed behavoral studies).

interesting this crops up, and in a thread with Mark. I am told he recently confirmed that there is no systematic deliberate biassing towards V4 in the code: its just shorter RTT selection. 

I wonder if there is a non-intentional bias against V6 eg the order the calls are made, or a lazy evaluated IF statement logic, because we see overwhelmingly more V4 than V6 on dual-stack NS with no cached state.

-G
<div><div dir="ltr">
<br><div class="gmail_extra">
<br><div class="gmail_quote">On 9 June 2015 at 14:53, Edward Lewis <span dir="ltr">&lt;<a href="mailto:edward.lewis@..." target="_blank">edward.lewis@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
<span class="">On 6/9/15, 7:42, "Mark Andrews" &lt;<a href="mailto:marka@...">marka@...</a>&gt; wrote:<br></span>ents that can be referenced<br>
separately (like in RFP's and contracts).&nbsp; I found that trying to make<br>
code prefer newer technologies over old by fiat seems to backfire (like<br>
the way DNS used to prefer v6 over v4 and now seems to have reversed,<br>
looking at some observed behavoral studies).<br>
</blockquote>
</div>
<br>
</div>
<div class="gmail_extra">interesting this crops up, and in a thread with Mark. I am told he recently confirmed that there is no systematic deliberate biassing towards V4 in the code: its just shorter RTT selection.&nbsp;</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">I wonder if there is a non-intentional bias against V6 eg the order the calls are made, or a lazy evaluated IF statement logic, because we see overwhelmingly more V4 than V6 on dual-stack NS with no cached state.</div>
<div class="gmail_extra"><br></div>
<div class="gmail_extra">-G</div>
</div></div>

Gmane