At 0:18 +0200 9/2/09, bert hubert wrote:
On Tue, Sep 1, 2009 at 10:35 PM, Edward Lewis<ed.le...@neustar.biz> wrote:
At 4:05 +0900 9/2/09, fujiw...@jprs.co.jp wrote:
Performance problem will be solved by better code and new hardware.
In my opinion, "Dynamically Generate PTR When Queried" works well.
I have to ask based on the experience I had with wildcards, how does this
work with:
It works very well. One large country's incumbent telco has all of its
subscribers behind a scripted powerdns server synthesising PTRs, and
with exception of the large hardware cost savings (these were gigabyte
size zones), nobody noticed.
1) Zone transfers?
2) Dynamic update?
1 & 2 typically don't happen in such cases.
3) DNSSEC?
This will pretty much break, unless you also teach the system how to
synthesise NSEC(3).
"It works very well"? - From your response it sounds like it
*doesn't* work with the things I mentioned. This is a good idea, a
good start. It just needs further development.
Without zone transfers, this approach lacks interoperability. The
master and slaves have to be the same make. Sure, you can achieve
all this with one implementation that shares a database backend - but
the DNS protocol doesn't have a standard way to plug in any database
to any name server.
Without dynamic update this approach is limited functionality in an
enterprise network. Dynamic update has a much higher profile in
operations than is discussed in the protocol fora. Serving static
data is easy and DNS scales real well doing that, but no so much when
it comes to changing data. Just about all the current hiccups I see
relate to incremental edits to zones.
And without DNSSEC, we don't have security for the answers and more
importantly makes me wonder if this new mechanism will grow with the
protocol. An aspect of DNSSEC development is that in just going
through the motions we uncovered a lot of errors in the protocol and
common implementations. Whenever I hear of an extension that does
not meld well with DNSSEC, I get concerned, wondering if the change
is a good architectural road to take.
I think there is a latent need to extend the DNS protocol to include
an answer synthesis mechanism that is more flexible than RFC 4592.
It's easy to come up with partial solutions, we need one that has all
the features or the current protocol.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
