George Michaelson | 24 Oct 05:26 2014
Picon

Re: resolvers considered harmful

I am probably a contrarian, but having lived the time of not having DNS, into the time of having a simple DNS, to the time of a complex DNS I can't understand, I yearn for a simpler DNS.

The web obviously works. It works without "resolvers" as the assumed norm. Caches and Proxies exist but the basics are written to assume they aren't there, and what I _love_ is that well behaving proxies and caches intrude X-Trace lines into the thing so you can tell who is in the loop for debug and analysis. (I am simplifying)

If we return to a world where people ask questions, and agents forwarding on their behalf, or answering on the authoritative source's behalf tell you so, then I'd be happy.

I liked the various proposals to re-state DNS in JSON. Precisely because it would trivially work as a service over HTTP(s) and would be arguably no worse than what we have.

-George





On 24 October 2014 11:46, Edward Lewis <edward.lewis <at> icann.org> wrote:
Talk about a DNS amplification attack - a seven page paper getting 60+ messages.  I didn’t do the math, but I bet more was written about the paper than in the paper.  With all this list traffic, I feel compelled to join in.  If you have work to do, you might want to skip the rest of the message.

Most of my thoughts are in Jason’s reply below.  To extend #2 - besides the small sample size, the patterns used in the initial data set represent only one class of use cases (the home user).  Inside enterprises, recursion is used in many imaginative (I’ll go with that word) ways, from having to live with legacy set ups, non-standard services using not-quite cookie cutter implementations.  If I were to judge the paper, I’d first complain that the input data set was way too restrictive.  (Not every use of the Internet is from a Google Ad running flash in a browser ;) - sorry a poor jab at Geoff.)  (Look, seriously, I’m kidding.)

The DNS is not a client-server protocol, it is a system composed of a lot of client-server relationships (e.g., a Notify client is tied to an AXFR server and a notify server is tied to an AXFR client - one example of how the system twists and turns the notion of client-server around).  I mention this because “removing” the recursive elements is forcing DNS in to a client-server model - one should be wary of trying to do such a retrofit.  DNS is a query-response protocol, but not a client-server protocol.  (I’d say it might even pre-date client-server as a normal way to write protocols.  I’m not sure of that, I do recall lecturing on what “client-server” meant well after RFC 1034/RFC 1035 were published.)

Suggesting removing the caches isn’t even really a change to the protocol, as the “service” of iteratively finding answers still needs to be done somewhere.  (If you shoved the iteration the other way, away from the edges, towards the core, you back to the POTS.)  One of the points I want to highlight is that “specialization is good” - having one implementation specialize in finding information is better than breaking this work load amongst a lot of not-as-well-written-for-the-job code fragments.  (I think I may have seen that appear in one reply.)  Beside the blue-sky statement that specialization is good, there was a recent thread on this list where someone found a set of servers that gave answers to specific questions - but dig +trace failed.  I’d once seen this - my code to poke at servers failed to get answers, but a well-written BIND recursive server managed to navigate the muddy waters and find the answer.  What heuristics BIND uses to find answers are a lot more developed than a causal observer might assume.  Loosing caching loses concentration of well-written code.

The DNS is not an easy system to dissect.  There are so many aspects to its architecture.  It’s ugly in a lot of places and one wonders how it functions at all.  Believe me, I’ve had this thing up on the lift and the undercarriage is a mess.  The astounding thing is that it works at all - and it works so well there’s a huge industry built to operate it.  I still can’t believe that specialists cross oceans on nearly a monthly basis just to talk about it.  I.e., when anyone thinks they can improve the system by one little tweak, they will probably be in for a rude awakening.  Still, I wouldn’t build another protocol like this.

(Time for the showing my age comment.) The only thing I find annoying about academic papers is the two-column style.  I have to blow the font size up so big I have to read down one and then scroll back up the other side.

Won’t we want caching on the Interplanetary Network? ;)


Interesting paper – thanks for giving the list a heads up. My comments:

1 – I think the claim “First, removing resolvers simplifies the overall system” is a matter of opinion. I may even argue the opposite, that the prevalence of large scale resolvers simplifies the overall system (but as an operator of one, I am admittedly biased).

2 – The sample size of a resolver serving 100 home users seems small. You may want to try to collect data from larger networks.

3 – I am not sure that authoritative server operators would be prepared for the large increase in query volumes, and not sure they’d be prepared to mitigate that by compromising with longer TTLs.

Regards
Jason Livingood

<div>
<div dir="ltr">I am probably a contrarian, but having lived the time of not having DNS, into the time of having a simple DNS, to the time of a complex DNS I can't understand, I yearn for a simpler DNS.<div><br></div>
<div>The web obviously works. It works without "resolvers" as the assumed norm. Caches and Proxies exist but the basics are written to assume they aren't there, and what I _love_ is that well behaving proxies and caches intrude X-Trace lines into the thing so you can tell who is in the loop for debug and analysis. (I am simplifying)</div>
<div><br></div>
<div>If we return to a world where people ask questions, and agents forwarding on their behalf, or answering on the authoritative source's behalf tell you so, then I'd be happy.</div>
<div><br></div>
<div>I liked the various proposals to re-state DNS in JSON. Precisely because it would trivially work as a service over HTTP(s) and would be arguably no worse than what we have.</div>
<div><br></div>
<div>-George</div>
<div><br></div>
<div><br></div>
<div><br></div>
<div><br></div>
</div>
<div class="gmail_extra">
<br><div class="gmail_quote">On 24 October 2014 11:46, Edward Lewis <span dir="ltr">&lt;<a href="mailto:edward.lewis@..." target="_blank">edward.lewis <at> icann.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">

<div>
<div>Talk about a DNS amplification attack - a seven page paper getting 60+ messages.&nbsp; I didn&rsquo;t do the math, but I bet more was written about the paper than in the paper.&nbsp; With all this list traffic, I feel compelled to join in.&nbsp; If you have work to do, you
 might want to skip the rest of the message.</div>
<div><br></div>
<div>Most of my thoughts are in Jason&rsquo;s reply below.&nbsp; To extend #2 - besides the small sample size, the patterns used in the initial data set represent only one class of use cases (the home user).&nbsp; Inside enterprises, recursion is used in many imaginative (I&rsquo;ll
 go with that word) ways, from having to live with legacy set ups, non-standard services using not-quite cookie cutter implementations.&nbsp; If I were to judge the paper, I&rsquo;d first complain that the input data set was way too restrictive. &nbsp;(Not every use of the
 Internet is from a Google Ad running flash in a browser ;) - sorry a poor jab at Geoff.) &nbsp;(Look, seriously, I&rsquo;m kidding.)</div>
<div><br></div>
<div>The DNS is not a client-server protocol, it is a system composed of a lot of client-server relationships (e.g., a Notify client is tied to an AXFR server and a notify server is tied to an AXFR client - one example of how the system twists and turns the
 notion of client-server around).&nbsp; I mention this because &ldquo;removing&rdquo; the recursive elements is forcing DNS in to a client-server model - one should be wary of trying to do such a retrofit.&nbsp; DNS is a query-response protocol, but not a client-server protocol.
 &nbsp;(I&rsquo;d say it might even pre-date client-server as a normal way to write protocols.&nbsp; I&rsquo;m not sure of that, I do recall lecturing on what &ldquo;client-server&rdquo; meant well after RFC 1034/RFC 1035 were published.)</div>
<div><br></div>
<div>Suggesting removing the caches isn&rsquo;t even really a change to the protocol, as the &ldquo;service&rdquo; of iteratively finding answers still needs to be done somewhere. &nbsp;(If you shoved the iteration the other way, away from the edges, towards the core, you back to
 the POTS.) &nbsp;One of the points I want to highlight is that &ldquo;specialization is good&rdquo; - having one implementation specialize in finding information is better than breaking this work load amongst a lot of not-as-well-written-for-the-job code fragments. &nbsp;(I think
 I may have seen that appear in one reply.) &nbsp;Beside the blue-sky statement that specialization is good, there was a recent thread on this list where someone found a set of servers that gave answers to specific questions - but dig +trace failed.&nbsp; I&rsquo;d once seen
 this - my code to poke at servers failed to get answers, but a well-written BIND recursive server managed to navigate the muddy waters and find the answer.&nbsp; What heuristics BIND uses to find answers are a lot more developed than a causal observer might assume.
 &nbsp;Loosing caching loses concentration of well-written code.</div>
<div><br></div>
<div>The DNS is not an easy system to dissect.&nbsp; There are so many aspects to its architecture.&nbsp; It&rsquo;s ugly in a lot of places and one wonders how it functions at all.&nbsp; Believe me, I&rsquo;ve had this thing up on the lift and the undercarriage is a mess.&nbsp; The astounding
 thing is that it works at all - and it works so well there&rsquo;s a huge industry built to operate it.&nbsp; I still can&rsquo;t believe that specialists cross oceans on nearly a monthly basis just to talk about it.&nbsp; I.e., when anyone thinks they can improve the system by
 one little tweak, they will probably be in for a rude awakening.&nbsp; Still, I wouldn&rsquo;t build another protocol like this.</div>
<div><br></div>
<div>(Time for the showing my age comment.) The only thing I find annoying about academic papers is the two-column style.&nbsp; I have to blow the font size up so big I have to read down one and then scroll back up the other side.</div>
<div><br></div>
<div>Won&rsquo;t we want caching on the Interplanetary Network? ;)</div>
<div><br></div>
<span>
<div>
<span>From: </span>&lt;Livingood&gt;, Jason &lt;<a href="mailto:Jason_Livingood@..." target="_blank">Jason_Livingood@...</a>&gt;<br><span>Date: </span>Thursday, October 23, 2014 at 17:30<br><span>To: </span>"<a href="mailto:mallman <at> icir.org" target="_blank">mallman@...</a>" &lt;<a href="mailto:mallman@..." target="_blank">mallman@...</a>&gt;, "<a href="mailto:dns-operations@..." target="_blank">dns-operations <at> dns-oarc.net</a>" &lt;<a href="mailto:dns-operations@..." target="_blank">dns-operations@...</a>&gt;<br><span>Subject: </span>Re: [dns-operations] resolvers considered harmful<br>
</div>
<div><div class="h5">
<div><br></div>
<blockquote>
<div>
<div>
<div>Interesting paper &ndash; thanks for giving the list a heads up. My comments:</div>
<div><br></div>
<div>1 &ndash; I think the claim &ldquo;First, removing resolvers simplifies the overall system&rdquo; is a matter of opinion. I may even argue the opposite, that the prevalence of large scale resolvers simplifies the overall system (but as an operator of one, I am admittedly
 biased).</div>
<div><br></div>
<div>2 &ndash; The sample size of a resolver serving 100 home users seems small. You may want to try to collect data from larger networks.</div>
<div><br></div>
<div>3 &ndash; I am not sure that authoritative server operators would be prepared for the large increase in query volumes, and not sure they&rsquo;d be prepared to mitigate that by compromising with longer TTLs.</div>
<div><br></div>
<div>Regards</div>
<div>Jason Livingood</div>
</div>
</div>
</blockquote>
</div></div></span>
</div>

</blockquote>
</div>
<br>
</div>
</div>
Bob Harold | 23 Oct 16:30 2014
Picon

Re: dns-operations Digest, Vol 105, Issue 26


Date: Wed, 22 Oct 2014 15:38:14 -0400
From: Andrew Sullivan <ajs <at> anvilwalrusden.com>
To: dns-operations <at> dns-oarc.net
Subject: Re: [dns-operations] resolvers considered harmful
Message-ID: <20141022193814.GI37494-3JaWX8cVOKDjCrcO1DDANg@public.gmane.org>
Content-Type: text/plain; charset=us-ascii

On Wed, Oct 22, 2014 at 11:19:45AM -0700, David Conrad wrote:
>
> That cost is discussed in the paper (section 5).

Their model doesn't make it a "large" increase, and I think that's
because of their unrealistic assumptions about actual use.  The
problem is that the really popular domains on the Internet (Google is
one example they do discuss) have completely different patterns than
everyone else.  The mitigation technique of increasing TTLs imposes a
cost on the operator of the popular domain (a cost in terms of
flexibility).  The authors seem to think this is no large cost, and I
disagree.

--
Andrew Sullivan

I think one of the assumptions that is likely wrong is the cache times.  Many computers are turned off at the end of the day, which clears the cache, so the numbers should be recalculated with one day max cache time as a possible worst case.

Also, the two day TTL's on top-level zones are already too long.  If I am forced to move from one DNS provider to another, being down for two days is a problem.  Anything longer is even worse.

-- 
Bob Harold
University of Michigan 

<div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote">
<br>
Date: Wed, 22 Oct 2014 15:38:14 -0400<br>
From: Andrew Sullivan &lt;<a href="mailto:ajs@...">ajs <at> anvilwalrusden.com</a>&gt;<br>
To: <a href="mailto:dns-operations@...">dns-operations <at> dns-oarc.net</a><br>
Subject: Re: [dns-operations] resolvers considered harmful<br>
Message-ID: &lt;<a href="mailto:20141022193814.GI37494@...">20141022193814.GI37494@...</a>&gt;<br>
Content-Type: text/plain; charset=us-ascii<br><br>
On Wed, Oct 22, 2014 at 11:19:45AM -0700, David Conrad wrote:<br>
&gt;<br>
&gt; That cost is discussed in the paper (section 5).<br><br>
Their model doesn't make it a "large" increase, and I think that's<br>
because of their unrealistic assumptions about actual use.&nbsp; The<br>
problem is that the really popular domains on the Internet (Google is<br>
one example they do discuss) have completely different patterns than<br>
everyone else.&nbsp; The mitigation technique of increasing TTLs imposes a<br>
cost on the operator of the popular domain (a cost in terms of<br>
flexibility).&nbsp; The authors seem to think this is no large cost, and I<br>
disagree.<br><br>
--<br>
Andrew Sullivan<br><br>
</blockquote>I think one of the assumptions that is likely wrong is the cache times.&nbsp; Many computers are turned off at the end of the day, which clears the cache, so the numbers should be recalculated with one day max cache time as a possible worst case.<br clear="all"><div><br></div>
<div>Also, the two day TTL's on top-level zones are already too long.&nbsp; If I am forced to move from one DNS provider to another, being down for two days is a problem.&nbsp; Anything longer is even worse.</div>
<div>
<br>--&nbsp;<br>Bob Harold<br>
</div>
<div>University of Michigan&nbsp;</div>
<div><br></div>
</div></div></div></div>
Mark Allman | 22 Oct 18:47 2014

resolvers considered harmful


Short paper / crazy idea for your amusement ...

Kyle Schomp, Mark Allman, Michael Rabinovich.  DNS Resolvers Considered
Harmful, ACM SIGCOMM Workshop on Hot Topics in Networks (HotNets),
October 2014.  To appear.
http://www.icir.org/mallman/pubs/SAR14/

Abstract:
  The Domain Name System (DNS) is a critical component of the Internet
  infrastructure that has many security vulnerabilities.  In particular,
  shared DNS resolvers are a notorious security weak spot in the system.
  We propose an unorthodox approach for tackling vulnerabilities in
  shared DNS resolvers: removing shared DNS resolvers entirely and
  leaving recursive resolution to the clients.  We show that the two
  primary costs of this approach---loss of performance and an increase
  in system load---are modest and therefore conclude that this approach
  is beneficial for strengthening the DNS by reducing the attack
  surface.

Comments welcome.

allman

--
http://www.icir.org/mallman/


Short paper / crazy idea for your amusement ...

Kyle Schomp, Mark Allman, Michael Rabinovich.  DNS Resolvers Considered
Harmful, ACM SIGCOMM Workshop on Hot Topics in Networks (HotNets),
October 2014.  To appear.
http://www.icir.org/mallman/pubs/SAR14/

Abstract:
  The Domain Name System (DNS) is a critical component of the Internet
  infrastructure that has many security vulnerabilities.  In particular,
  shared DNS resolvers are a notorious security weak spot in the system.
  We propose an unorthodox approach for tackling vulnerabilities in
  shared DNS resolvers: removing shared DNS resolvers entirely and
  leaving recursive resolution to the clients.  We show that the two
  primary costs of this approach---loss of performance and an increase
  in system load---are modest and therefore conclude that this approach
  is beneficial for strengthening the DNS by reducing the attack
  surface.

Comments welcome.

allman

--
http://www.icir.org/mallman/

Paul Vixie | 20 Oct 23:25 2014

namecheap to the white courtesy phone, please

it's not april 1. please stop.

vixie

re:

$ dig  <at> dns1.registrar-servers.com +short thereitwas.com CNAME
thereitwas.com.s3-website-us-east-1.amazonaws.com.

$ dig +trace thereitwas.com

; <<>> DiG 9.8.2 <<>> +trace thereitwas.com
;; global options: +cmd
.                       74554   IN      NS      h.root-servers.net.
.                       74554   IN      NS      k.root-servers.net.
.                       74554   IN      NS      g.root-servers.net.
.                       74554   IN      NS      d.root-servers.net.
.                       74554   IN      NS      f.root-servers.net.
.                       74554   IN      NS      j.root-servers.net.
.                       74554   IN      NS      m.root-servers.net.
.                       74554   IN      NS      e.root-servers.net.
.                       74554   IN      NS      b.root-servers.net.
.                       74554   IN      NS      l.root-servers.net.
.                       74554   IN      NS      i.root-servers.net.
.                       74554   IN      NS      c.root-servers.net.
.                       74554   IN      NS      a.root-servers.net.
;; Received 509 bytes from 10.62.200.11#53(10.62.200.11) in 158 ms

com.                    172800  IN      NS      k.gtld-servers.net.
com.                    172800  IN      NS      c.gtld-servers.net.
com.                    172800  IN      NS      g.gtld-servers.net.
com.                    172800  IN      NS      i.gtld-servers.net.
com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      e.gtld-servers.net.
com.                    172800  IN      NS      h.gtld-servers.net.
com.                    172800  IN      NS      f.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
com.                    172800  IN      NS      l.gtld-servers.net.
com.                    172800  IN      NS      d.gtld-servers.net.
com.                    172800  IN      NS      j.gtld-servers.net.
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 492 bytes from 192.112.36.4#53(192.112.36.4) in 5253 ms

thereitwas.com.         172800  IN      NS      dns2.registrar-servers.com.
thereitwas.com.         172800  IN      NS      dns1.registrar-servers.com.
thereitwas.com.         172800  IN      NS      dns3.registrar-servers.com.
thereitwas.com.         172800  IN      NS      dns4.registrar-servers.com.
thereitwas.com.         172800  IN      NS      dns5.registrar-servers.com.
;; Received 369 bytes from 192.55.83.30#53(192.55.83.30) in 432 ms

thereitwas.com.         60      IN      CNAME  
thereitwas.com.s3-website-us-east-1.amazonaws.com.
.                       518400  IN      NS      a.root-servers.net.
.                       518400  IN      NS      b.root-servers.net.
.                       518400  IN      NS      c.root-servers.net.
.                       518400  IN      NS      d.root-servers.net.
.                       518400  IN      NS      e.root-servers.net.
.                       518400  IN      NS      f.root-servers.net.
.                       518400  IN      NS      g.root-servers.net.
.                       518400  IN      NS      h.root-servers.net.
.                       518400  IN      NS      i.root-servers.net.
.                       518400  IN      NS      j.root-servers.net.
.                       518400  IN      NS      k.root-servers.net.
.                       518400  IN      NS      l.root-servers.net.
.                       518400  IN      NS      m.root-servers.net.
;; Received 303 bytes from 173.245.59.40#53(173.245.59.40) in 139 ms

--

-- 
Paul Vixie
Stephane Bortzmeyer | 20 Oct 11:27 2014
Picon

IETF working group on DNS privacy

Yes, I know, it is not really operations. But it may have an influence
on DNS operations so I prefer the operations people to be aware of it:
IETF just created a working group on DNS privacy, named DPRIV :-)

The charter of the working group, if you want to know what this group
is up to, is <http://datatracker.ietf.org/wg/dprive/charter/>

If you want to participate and do not know IETF rules, you should
first read the Tao <http://www.ietf.org/newcomers.html> Otherwise, the
group's official mailing list is
<https://www.ietf.org/mailman/listinfo/dns-privacy>

Do note that some possible tools for improving DNS privacy are not
discussed in this DPRIVE working group but in other groups. For
instance, QNAME minimisation is currently proposed for adoption by the
DNSOP working group (deadline is today).

Paul Hoffman | 19 Oct 04:10 2014

Source data about root server anycast locations?

Greetings again. The map and lists at <http://www.root-servers.org/index.html> have a lot of data that
would be valuable to analyze, particularly how close recursives are to root nodes (even if that's just
geographic/political closeness). RSSAC is just getting started with publishing reports, and anycast
location and proliferation has not been covered in the reports covered so far.

Has anyone (maybe DNS-OARC?) kept snapshots of this type of data? Any clues would be appreciated.

--Paul Hoffman
Bernhard Schmidt | 16 Oct 10:35 2014
Picon

DNSSEC Validation Errors with Wildcards

Hi,

we have recently enabled outbound TLSA/DANE on our Postfix MTAs and have
come across a number of validation errors. These have the following in
common:

- The zone where the mailserver (right side of the MX record of the
target domain) resides in is signed
- there is a wildcard record on the zone level
- lookup of mailserver A/AAAA works fine and is authenticated
- lookup of _25._tcp.mailserver TLSA leads to SERVFAIL on our resolver
(BIND 9.9.5), Google DNS and both DNS-OARC resolvers

Examples:

_25._tcp.vdlc.nl
_25._tcp.mail.plexx.eu
_25._tcp.relay01.tt-mb.nl
_25._tcp.mail.cdv.cz

Sometimes DNSVIZ shows errors in the NSEC chaining (i.e. on the tt-mb.nl
zone), but for example the mail.cdv.cz one looks fine. Yet I cannot
validate the response.

Can anyone shed some light on this issue? Is there a signing error or a
validation error? If there is a signing error, is this a bug of some
commonly used software?

Thanks,
Bernhard
Lyle Giese | 15 Oct 00:08 2014
Picon

need someone else to look at these servers

A customer is trying to send email to a customer that is using 
secureserver.net for email.

Their MX record points to presmtp.ex3.secureserver.net.

This is where things get screwy.

Dig(+trace) shows that presemtp.ex3.secureserver.net has the following 
auth servers:

gns1.secureserver.net
gns2.secureserver.net
gns3.secureserver.net

However when I query these servers directly using dig, I get back No 
servers could be reached.
(dig  <at> gns1.secureserver.net presmtp.ex3.secureserver.net)

When I use +notcp option, I get back:

Warning: EDNS query returned status FORMERR - retry with '+noedns'.

If I use +notcp and +noedns, it works and I get the A record.

If I use +noedns, it works and I get the A record.

Am I doing something wrong or are their servers/load balancers screwed 
up?  I know something is wrong, but would like someone with a bit more 
knowledge to look at this and give their opinion.

Thanks,
Lyle Giese
LCR Computer Services, Inc.
Stephane Bortzmeyer | 14 Oct 09:00 2014
Picon

ShellShock exploit through the DNS

Funny: an OS sends the result of some DNS queries to bash, allowing
the DNS operator to attack DNS clients with ShellShock:

http://packetstormsecurity.com/files/128650

What about an evil AS 112 operator attacking 168.192.in-addr.arpa
users?
Franck Martin | 14 Oct 08:39 2014
Picon

Explaining DNSSEC issues

I found this tool quite good to report the most common DNSSEC issues. It looks at SOA, A, AAAA, and MX records
of a zone and is visually nearly intuitive.

http://dnsviz.net/d/dns-oarc.net/dnssec/

The type of errors I see are like:
http://dnsviz.net/d/eucom.mil/dnssec/

Where an important record is not signed

Or like:
http://dnsviz.net/d/au/dnssec/

Where the delegation is not set (DS). For dot au, it is on purpose so testing can occur before going live by the
end of this month: http://www.auda.org.au/industry-information/au-domains/dnssec/
I found this tool quite good to report the most common DNSSEC issues. It looks at SOA, A, AAAA, and MX records
of a zone and is visually nearly intuitive.

http://dnsviz.net/d/dns-oarc.net/dnssec/

The type of errors I see are like:
http://dnsviz.net/d/eucom.mil/dnssec/

Where an important record is not signed

Or like:
http://dnsviz.net/d/au/dnssec/

Where the delegation is not set (DS). For dot au, it is on purpose so testing can occur before going live by the
end of this month: http://www.auda.org.au/industry-information/au-domains/dnssec/
han feng | 11 Oct 07:43 2014
Picon

DNS BoF <at> DNS OARC 2014 Fall LA

Hi all:

We are working on organizing a DNS BoF at DNS OARC 2014 Fall in LA, and we wanted to  
share the test report regarding to DNS dynamic update and xfr (please refer to the 
attachment), and ask your opinions on the topics that we should cover on this BoF.

Some interesting topics we thought of: 
- What approach you are using to perform zone updation, replication and synchronization
- Why dynamic update and xfr is or isn't your choice

looking forward to hear your thoughts.

Date : 12th Orc 2014 (Sunday)
Time : 6pm to 9pm 
Room : TBD 

feng

Attachment (DNS Dynamic Update Performace Study.ppt): application/vnd.ms-powerpoint, 2064 KiB
Hi all:

We are working on organizing a DNS BoF at DNS OARC 2014 Fall in LA, and we wanted to  
share the test report regarding to DNS dynamic update and xfr (please refer to the 
attachment), and ask your opinions on the topics that we should cover on this BoF.

Some interesting topics we thought of: 
- What approach you are using to perform zone updation, replication and synchronization
- Why dynamic update and xfr is or isn't your choice

looking forward to hear your thoughts.

Date : 12th Orc 2014 (Sunday)
Time : 6pm to 9pm 
Room : TBD 

feng


Gmane