From as112-ops at trex.fi  Wed Jan  8 03:23:13 2014
From: as112-ops at trex.fi (Aleksi Suhonen)
Date: Wed, 08 Jan 2014 05:23:13 +0200
Subject: [as112-ops] [DNSOP] Adoption of
 <draft-wkumari-dnsop-omniscient-as112-01.txt> as a WG work item? (fwd)
In-Reply-To: <Pine.LNX.4.64.1303151108320.8361@iskra.ottix.net>
References: <Pine.LNX.4.64.1303151108320.8361@iskra.ottix.net>
Message-ID: <52CCC4A1.3@trex.fi>

Hello,

On 03/15/2013 05:11 PM, William F. Maton Sotomayor wrote:
> (Aleksi where are you?  Care to contribute?)

I've had too many other things on my plate. Sorry.

On 2013-02-22, at 15:14, "Dickson, Brian" <bdickson at verisign.com> wrote:
>> Instead of delegating to omniscient AS112 servers, what about doing a
>> DNAME to a specific target "foo" (replace "foo" with what you will) in
>> the DNS tree?

Joe Able wrote:
> I've thought about this a bit, and I've decided that I quite like it.
>
> So, if I can paraphrase to ensure we're talking about the same thing,
> the current working omniscient plan involves:
>
>   - custom code

Has anyone been working on this in the mean time? An earlier email 
referred to the following code, but it doesn't do what was advertised:

http://code.google.com/p/evldns/source/browse/trunk/as112d.c

Joe Abley wrote:
> Your idea, however, involves
>
>   - hosting a known, empty zone on known nameservers
>   - pseudo-delegating new worthy zones by provisioning a DNAME at a
> suitable point in another zone
>   - no custom code
>   - no protocol discomfort, so long as we don't gag too badly on the use
> of DNAME

I understand that DNAMEs cause auto-generated CNAMEs which could be 
abused to seriously clog up the caches of recursing DNS servers if used 
with IPv6 reverse zones. Is this true?

Joe Abley wrote:
> Your idea has advantages, then.
>
> Anybody could decide to sink traffic for any name at AS112++ servers by
> installing a similar DNAME. This would become a standard way to dispense
> with and junk DNS traffic; perhaps we need to think about writing this
> up as AS112.ARPA and make it a more general mechanism than just a place
> to sink default-local-zones traffic.

For the record, I am all for this idea.

> Suppose AS112.ARPA is delegated to the nameservers BLACKHOLE-3.IANA.ORG
> and BLACKHOLE-4.IANA.ORG, and the AS112.ARPA zone is empty apart from an
> SOA (SOA.MNAME = PRISONER-2.IANA.ORG). The names of the servers don't
> matter much, except that they need not to be named under AS112.ARPA
> (since that would pollute the empty zone with A and AAAA RRSets).

BTW, blackhole-{3,4} only have AAAA records. I am of the opinion that we 
should request IANA to reserve IPv4 addresses for those names as well. 
Regardless of which model we go for or what zones are delegated there.

I also think it would be beneficial to have the proper local mirror name 
and the proper local mirror management email contacts in the SOA for 
AS112.ARPA. (Except if the zone is signed and AXFR'ed from ICANN.)

Yours,

-- 
	+358 4567 02048 / http://www.trex.fi/
	Aleksi Suhonen / TREX Regional Exchanges Oy

     `What I need,' shouted Ford, by way of clarifying his
     previous remarks, `is a strong drink and a peer-group.'
        -- Douglas Adams, Life the Universe and Everything

From jabley at hopcount.ca  Thu Jan  9 17:43:22 2014
From: jabley at hopcount.ca (Joe Abley)
Date: Thu, 9 Jan 2014 12:43:22 -0500
Subject: [as112-ops] [DNSOP] Adoption of
	<draft-wkumari-dnsop-omniscient-as112-01.txt> as a WG work
	item? (fwd)
In-Reply-To: <52CCC4A1.3@trex.fi>
References: <Pine.LNX.4.64.1303151108320.8361@iskra.ottix.net>
	<52CCC4A1.3@trex.fi>
Message-ID: <27FA2129-A3A8-46D3-89C2-6AE22162302A@hopcount.ca>


On 2014-01-07, at 22:23, Aleksi Suhonen <as112-ops at trex.fi> wrote:

> Has anyone been working on this in the mean time? An earlier email referred to the following code, but it doesn't do what was advertised:
> 
> http://code.google.com/p/evldns/source/browse/trunk/as112d.c

I don't think Ray has done anything else with that, but when I looked at the code it seemed like it should do what Warren's last omniscient draft said it should do. I'm sure he'd be interested in hearing if there are bugs.

> Joe Abley wrote:
>> Your idea, however, involves
>> 
>>  - hosting a known, empty zone on known nameservers
>>  - pseudo-delegating new worthy zones by provisioning a DNAME at a
>> suitable point in another zone
>>  - no custom code
>>  - no protocol discomfort, so long as we don't gag too badly on the use
>> of DNAME
> 
> I understand that DNAMEs cause auto-generated CNAMEs which could be abused to seriously clog up the caches of recursing DNS servers if used with IPv6 reverse zones. Is this true?

That's interesting. I guess the extent of the potential damage depends on the installed base of resolvers that support DNAME.

My immediate thought is that anybody who really cares about this problem is likely already running code recent enough to allow the DNAME itself to be cached, and the synthesised CNAMEs to be discarded (e.g. for reasons of performance in the case of code bases that pre-date DNAME, or because more recent alternatives came with DNAME support in their initial release).

Do you have operational war stories that suggest this is significant? It's difficult to imagine an experiment that could test the theory without causing collateral damage in the event that this really is a problem.

>> Suppose AS112.ARPA is delegated to the nameservers BLACKHOLE-3.IANA.ORG
>> and BLACKHOLE-4.IANA.ORG, and the AS112.ARPA zone is empty apart from an
>> SOA (SOA.MNAME = PRISONER-2.IANA.ORG). The names of the servers don't
>> matter much, except that they need not to be named under AS112.ARPA
>> (since that would pollute the empty zone with A and AAAA RRSets).
> 
> BTW, blackhole-{3,4} only have AAAA records. I am of the opinion that we should request IANA to reserve IPv4 addresses for those names as well. Regardless of which model we go for or what zones are delegated there.

That's the approach we took (the thinking has matured somewhat in the last eleven months). The most recent description of the proposal is here:

  http://tools.ietf.org/html/draft-ietf-dnsop-as112-dname

That draft is in a bit of a holding pattern, waiting for the newly-partially-reconstituted dnsop chairs to give direction as to whether we want to roll revised RFC6304-style text into this document, or publish a separate replacement for 6304 (my preference is the latter).

> I also think it would be beneficial to have the proper local mirror name and the proper local mirror management email contacts in the SOA for AS112.ARPA. (Except if the zone is signed and AXFR'ed from ICANN.)

I like that idea, too. We could preserve some more general RDATA for people who choose not to put their own details in there (for whatever reason).


Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.dns-oarc.net/pipermail/as112-ops/attachments/20140109/7ac01984/attachment.pgp>

From asjl at lpnz.org  Fri Jan 31 00:51:16 2014
From: asjl at lpnz.org (Andy Linton)
Date: Fri, 31 Jan 2014 13:51:16 +1300
Subject: [as112-ops] Node added at Wellington Internet Exchange
Message-ID: <CALS-_OoMFh8OKcQ=DMj5xCtHrdEmx61h-WOfHpq2KGby_n64wg@mail.gmail.com>

Who: Wellington Internet Exchange
Where:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/as112-ops/attachments/20140131/a8d3c665/attachment.htm>

From asjl at lpnz.org  Fri Jan 31 00:53:36 2014
From: asjl at lpnz.org (Andy Linton)
Date: Fri, 31 Jan 2014 13:53:36 +1300
Subject: [as112-ops] Node added at Wellington Internet Exchange
In-Reply-To: <CALS-_OoMFh8OKcQ=DMj5xCtHrdEmx61h-WOfHpq2KGby_n64wg@mail.gmail.com>
References: <CALS-_OoMFh8OKcQ=DMj5xCtHrdEmx61h-WOfHpq2KGby_n64wg@mail.gmail.com>
Message-ID: <CALS-_OqbirsYP-tJb=J-NtJ=M_U5OF75yPWGCfqouCx9K2RWeA@mail.gmail.com>

Who: Wellington Internet Exchange
Where: NZ
Unicast: 103.10.233.112 (blackhole.softnetlab.org)
Transit AS: 132003
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/as112-ops/attachments/20140131/31588356/attachment.htm>

From wmaton at ottix.net  Fri Jan 31 10:28:50 2014
From: wmaton at ottix.net (William F. Maton Sotomayor)
Date: Fri, 31 Jan 2014 05:28:50 -0500 (EST)
Subject: [as112-ops] Node added at Wellington Internet Exchange
In-Reply-To: <CALS-_OqbirsYP-tJb=J-NtJ=M_U5OF75yPWGCfqouCx9K2RWeA@mail.gmail.com>
References: <CALS-_OoMFh8OKcQ=DMj5xCtHrdEmx61h-WOfHpq2KGby_n64wg@mail.gmail.com>
	<CALS-_OqbirsYP-tJb=J-NtJ=M_U5OF75yPWGCfqouCx9K2RWeA@mail.gmail.com>
Message-ID: <alpine.DEB.2.03.1401310528340.6302@iskra.ottix.net>


Thank you for your support. :)

Will update the operator's list.

On Fri, 31 Jan 2014, Andy Linton wrote:

> Who: Wellington Internet ExchangeWhere: NZ
> Unicast: 103.10.233.112 (blackhole.softnetlab.org)
> Transit AS: 132003
> 
> 
> 
>

wfms

From wmaton at ottix.net  Fri Jan 31 12:32:41 2014
From: wmaton at ottix.net (William F. Maton Sotomayor)
Date: Fri, 31 Jan 2014 07:32:41 -0500 (EST)
Subject: [as112-ops] AS112 stats collection, DSC and DITL
Message-ID: <alpine.DEB.2.03.1401310722130.6302@iskra.ottix.net>


Hi folks,

 	Would like to solicit the collection of AS112 data coming from 
your respective nodes.  One then being looked at is how to gather this 
data centrally, and it may make sense for the fine purveyours of DSC to 
actually host this.  The results of OttIX's contribution can be seen here, 
for instance:

https://public.dsc.dns-oarc.net/grapher?node=as112&server=as112-ottix&plot=bynode

I think the key is not to transmit the XML files produced by DSC, but 
rather the *.dat files which are created as a result for graphing.  The 
process would normally happen as a result of processing the XML files into 
dat files for your sites anyways.  So why transfer XMLs if post-processing 
is already been done?  Rsyncing dat files makes better sense in this case.

So:

a) AS112 nodes should already be gathering stats for their nodes, even
    if they are internal and not viewable on the Internet; and,
b) rsync DSC results files to something central like OARC's DSC site above

Anyone interested?  Contact me offline please.

Finally, this same group should also strongly consider contributing to 
this year's DITL-fest.  Info here:

 	https://www.dns-oarc.net/oarc/data/ditl

Thanks,

wfms

From jonathan.stewart at gmail.com  Fri Jan 31 22:30:26 2014
From: jonathan.stewart at gmail.com (Jonathan Stewart)
Date: Fri, 31 Jan 2014 16:30:26 -0600
Subject: [as112-ops] Node added at Wellington Internet Exchange
In-Reply-To: <CALS-_OqbirsYP-tJb=J-NtJ=M_U5OF75yPWGCfqouCx9K2RWeA@mail.gmail.com>
References: <CALS-_OoMFh8OKcQ=DMj5xCtHrdEmx61h-WOfHpq2KGby_n64wg@mail.gmail.com>
	<CALS-_OqbirsYP-tJb=J-NtJ=M_U5OF75yPWGCfqouCx9K2RWeA@mail.gmail.com>
Message-ID: <CA+K1SUx2ojcq0S4Hu2ydvDqf2o1NJizjmoSRREZD3eVddVNQDg@mail.gmail.com>

Cool Andy!

Thanks for sharing this info with the list.

How busy has your node been so far?  Seems you have many peers at WIX.

Cheers from Canada,
Jonathan


On Thu, Jan 30, 2014 at 6:53 PM, Andy Linton <asjl at lpnz.org> wrote:

> Who: Wellington Internet Exchange
> Where: NZ
> Unicast: 103.10.233.112 (blackhole.softnetlab.org)
> Transit AS: 132003
>
>
>
> _______________________________________________
> as112-ops mailing list
> as112-ops at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/as112-ops
>
>


-- 
     Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dns-oarc.net/pipermail/as112-ops/attachments/20140131/9673efad/attachment.htm>

