headers
Matthew Dempsky | 1 Jun 2009 03:09
Favicon

Re: TTL From Parent or Child Zone?

On Sun, Mar 8, 2009 at 4:41 PM, Sabahattin Gucukoglu
<mail <at> sabahattin-gucukoglu.com> wrote:
> The data in the parent zone isn't authoritative.  If djbdns caches it,
> it's wrong, IMHO.  It should discard additional data as fast as
> possible in favour of genuine data from the authoritative servers.
> This really means that as soon as you've learned the address of a name
> server in additional data, you use it once and then throw the
> additional data away.

No, there's no security risk from caching the data, and doing so
improves performance and decreases load on the DNS.
Permalink | Reply | 8 comments |
headers
Sabahattin Gucukoglu | 1 Jun 2009 11:16

Re: TTL From Parent or Child Zone?

On 1 Jun 2009, at 02:09, Matthew Dempsky wrote:
> On Sun, Mar 8, 2009 at 4:41 PM, Sabahattin Gucukoglu
> <mail <at> sabahattin-gucukoglu.com> wrote:
>> The data in the parent zone isn't authoritative.  If djbdns caches  
>> it,
>> it's wrong, IMHO.  It should discard additional data as fast as
>> possible in favour of genuine data from the authoritative servers.
>> This really means that as soon as you've learned the address of a  
>> name
>> server in additional data, you use it once and then throw the
>> additional data away.
>
> No, there's no security risk from caching the data, and doing so
> improves performance and decreases load on the DNS.

Well yes, but it also makes your cache inaccurate for the case where  
the delegating name server always holds records that dominate the  
authoritative data due to long TTLs.  RFC 2181 specifically points  
this out, and specifically puts additional data right at the bottom of  
the list of things to hang onto, with the note that really you  
shouldn't be using it for more than pursuing initial queries.  Besides  
all that, it's the resource records we're interested in, not the  
delegation information.  That's what we ask name servers for.  And of  
course there is nothing to stop incidentally provided additional data  
from authoritative servers being cached; in some cases this means  
apparently redundant queries are asked, but with the assurance that  
you're always holding cached data from an authoritative source.   
(Zones whose delegation is different from their parents' should be  
easier to spot, too.)
(Continue reading)

Permalink | Reply | 7 comments |
headers
Paul Jarc | 1 Jun 2009 18:39
Picon

Re: TTL From Parent or Child Zone?

Sabahattin Gucukoglu <mail <at> sabahattin-gucukoglu.com> wrote:
> Well yes, but it also makes your cache inaccurate for the case where
> the delegating name server always holds records that dominate the
> authoritative data due to long TTLs.

For a given domain name and record type, dnscache keeps the record
that it received most recently.  So if it's looking up the address of
www.example.com, and the.com servers say that example.com has the name
server a.ns.example.com, with the address 1.2.3.4, dnscache will cache
that - but then once it talks to a.ns.example.com, it will get new
NS/A records for a.ns.example.com, which will replace the previous
records in the cache.  So then those records will expire according to
the TTLs from a.ns.example.com, not the TTLs given by the .com
servers.

paul
Permalink | Reply | 6 comments |
headers
Sabahattin Gucukoglu | 1 Jun 2009 19:23

Re: TTL From Parent or Child Zone?

On 1 Jun 2009, at 17:39, Paul Jarc wrote:
> Sabahattin Gucukoglu <mail <at> sabahattin-gucukoglu.com> wrote:
>> Well yes, but it also makes your cache inaccurate for the case where
>> the delegating name server always holds records that dominate the
>> authoritative data due to long TTLs.
>
> For a given domain name and record type, dnscache keeps the record
> that it received most recently.  So if it's looking up the address of
> www.example.com, and the.com servers say that example.com has the name
> server a.ns.example.com, with the address 1.2.3.4, dnscache will cache
> that - but then once it talks to a.ns.example.com, it will get new
> NS/A records for a.ns.example.com, which will replace the previous
> records in the cache.  So then those records will expire according to
> the TTLs from a.ns.example.com, not the TTLs given by the .com
> servers.

That's fine, but what happens when there's never a need to ask  
authoritative servers?

Suppose I want to look up bigbox.example.net, and that  
bigbox.example.net happens to be in the glue provided by the .net  
nameservers for example.net.  Now the cache gets the answer it wants  
having only gone as far as the .net nameservers.  That data isn't  
authoritative and almost certainly has a very long TTL.  How can  
example.net guarantee that the address record for bigbox.example.net,  
as specified in the example.net zone files and as served by the  
bigbox.example.net nameserver, will be seen by caches?

Cheers,
Sabahattin
(Continue reading)

Permalink | Reply | 5 comments |
headers
Paul Jarc | 1 Jun 2009 19:29
Picon

Re: TTL From Parent or Child Zone?

Sabahattin Gucukoglu <mail <at> sabahattin-gucukoglu.com> wrote:
> How can example.net guarantee that the address record for
> bigbox.example.net, as specified in the example.net zone files and
> as served by the bigbox.example.net nameserver, will be seen by
> caches?

By using a different name for the NS records, so that the .net servers
won't have any records for bigbox.example.net.

paul
Permalink | Reply | 0 comments |
headers
Matthew Dempsky | 1 Jun 2009 19:44
Favicon

Re: TTL From Parent or Child Zone?

On Mon, Jun 1, 2009 at 10:23 AM, Sabahattin Gucukoglu
<mail <at> sabahattin-gucukoglu.com> wrote:
> That's fine, but what happens when there's never a need to ask authoritative
> servers?

There's two ways to solve this problem.

The first is server administrators follow section 4.2.1 of RFC 1034,
which says parent servers should always serve the exact same records
that child servers do.  If you follow this rule, there's never a need
to contact the child servers.

The alternative way is to make dnscache spend extra CPU cycles and
extra network resources and add extra load on DNS infrastructure.

dnscache uses the former solution.
Permalink | Reply | 0 comments |
headers
Darren Gamble | 2 Jun 2009 17:58
Picon

RE: TTL From Parent or Child Zone?

Hi Sabahattin,

> authoritative and almost certainly has a very long TTL.  How can
> example.net guarantee that the address record for bigbox.example.net,
> as specified in the example.net zone files and as served by the
> bigbox.example.net nameserver, will be seen by caches?
> 
> Cheers,
> Sabahattin

In addition to the other helpful replies you've received, it should also
be noted that dnscache will always update its cache with information
received in the authoritative section of a DNS reply.

So in practice, this may not be a concern for you since your cache will
have the "child's" RRs as soon as the child serves a record...  assuming
dnscache is the only cache looking at your data, of course.  Other cache
servers' behavior may differ.

============================
Darren Gamble
Systems Architect, Regional Services
Shaw Cablesystems GP
630 - 3rd Avenue SW
Calgary, Alberta, Canada
T2P 4L4
(403) 781-4948
Permalink | Reply | 2 comments |
headers
Mark Johnson | 2 Jun 2009 19:42
Picon

Re: DNSCurve patch for djbdns-1.05

On Fri, May 29, 2009 at 11:59 PM, Matthew Dempsky <matthew <at> dempsky.org> wrote:
> If you would like to test out how the patch works with a
> DNSCurve-aware name server, you can try resolving some names within
> x.dempsky.org.  E.g., after running "dnstxt hello.x.dempsky.org", you
> should see
>
>    tx 0 16 hello.x.dempsky.org. x.dempsky.org. + 46551f42
>
> in your dnscache logs.  The "+" indicates that this query was sent
> using DNSCurve.

The query should go out using DNSCurve, but there should be no
response, correct?  I don't see anything in your patch about a private
key for tinydns, so unless you've got some unpublished bits, this
would be the expected behavior?
Permalink | Reply | 1 comment |
headers
Matthew Dempsky | 2 Jun 2009 21:15
Favicon

Re: DNSCurve patch for djbdns-1.05

On Tue, Jun 2, 2009 at 10:42 AM, Mark Johnson <johnsonm <at> gmail.com> wrote:
> The query should go out using DNSCurve, but there should be no
> response, correct?

The query for hello.x.dempsky.org should have a response, because
x.dempsky.org's name server is DNSCurve enabled.

In case you're interested, x.dempsky.org's name server is running the
DNSCurve forwarder from http://github.com/mrd/dnscurve/ (forwarding to
a tinydns server), but it still needs some more work before it's ready
for non-developers to start using.
Permalink | Reply | 0 comments |
headers
Matthew Dempsky | 2 Jun 2009 22:53
Favicon

Re: DNSCurve patch for djbdns-1.05

On Fri, May 29, 2009 at 9:59 PM, Matthew Dempsky <matthew <at> dempsky.org> wrote:
> I finally had some extra free time earlier today to polish my djbdns
> DNSCurve patch to the point of feeling comfortable publishing it.  You
> can download the patch from:
>
>    http://shinobi.dempsky.org/~matthew/patches/djbdns-dnscurve-20090529.patch

An updated patch is now available at:

  http://shinobi.dempsky.org/~matthew/patches/djbdns-dnscurve-20090602.patch

Previous patches changed the semantics of the dns_transmit_start
function to require the memory storing the query name to remain
constant during the duration of a query (similar to the 'servers'
argument).  Within the djbdns-1.05 package, this only affected
dnsfilter, but it potentially affects third-party packages that link
against libdns.  The 20090602 patch corrects this regression.

Also, thanks to everyone who has tested so far.
Permalink | Reply | 0 comments |

Gmane