Subject: does anybody use additional/authority records on RD/RA replies

From: bert hubert <[email-masked]>
Date: Sat, 11 Jan 2003 13:15:40 +0100

In a refreshing change, here is a question about DNS.

I'm wondering if anybody knows of any client library actually using
additional/authority records in answers to recursion desired/recursion
available questions, with the exception of the SOA negative presence
indication.

Thanks.

Regards,

bert hubert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Rob Austein <[email-masked]>
Date: Sat, 11 Jan 2003 11:40:19 -0500

> In a refreshing change, here is a question about DNS.

Thank you!

> available questions, with the exception of the SOA negative presence

Additional for sure: think about QTYPE=MX.

Dunno about authority: offhand I can't remember any use for it, but
that doesn't prove that somebody else hasn't got one.

--Rob

---

From: Paul Vixie <[email-masked]>
Date: Sat, 11 Jan 2003 18:33:49 +0000

> available questions, with the exception of the SOA negative presence

sure.  sendmail's internal getmxrr does this, to try to get the MX and A
from a single dns transaction.  as far as i know, so does kerberos's 
internal getsrvbyname.

---

From: bert hubert <[email-masked]>
Date: Sat, 11 Jan 2003 20:12:24 +0100

> from a single dns transaction.  as far as i know, so does kerberos's 

Thanks, also to Rob. Indeed, I only forgot about that one because my own
boneheaded mailer did not take advantage from that at one point.

But I wonder about the utility of authority in this case - I've already seen
the powerdns recursor, a work in progress, spit out the weirdest things.

An example is www.bibleinfo.org which defines its own NS records with a 10
second TTL. After those are passed, the 'best' NS records are the ORG ones,
which are then attached to the answer, leading to an overly large packet.

[btw, I wonder why the ORG NS records are in COM? Seems silly]

A simple solution to that is not allowing a child to lower the TTL of
existing records, but that does not solve the root issue of the silliness of
adding the 'best' NS records known. Was there a non-human rationale to
adding those?

Regards,

bert

---

From: Paul Vixie <[email-masked]>
Date: Sat, 11 Jan 2003 19:45:56 +0000

> adding the 'best' NS records known. Was there a non-human rationale to

the child zone owns the delegation point.  the parent's zone-bottom NS RR's
are not authoritative in the parent, they are just hints/glue.  the child's
data, no matter how icky the TTL's are, is what you have to keep, TTL and all.

you could keep an opaqued copy of the parent's hints/glue around, so that
when the child's NS RRset expires, you can go back to the glue that got you
to the child in the first place.  but you have to keep going back to the
child.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 11 Jan 2003 20:04:42 -0000

> Additional for sure: think about QTYPE=MX.

Clients have to be prepared to ask for A records in a new DNS query. The
MX response often doesn't have any additional data.

It is, of course, safe for a cache to leave out authority and additional
records. dnscache has always done this; BIND 9 can now do it, except for
SOA records, with the ``minimal-responses'' option.

One client---sendmail---tries to skip the A query by caching A records
from the MX response. I'm amused by the ``save network traffic'' excuse
for this complication. If you really care about DNS traffic, why aren't
you running a real DNS cache on the same machine?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Bruce Campbell <[email-masked]>
Date: Sat, 11 Jan 2003 22:33:48 +0100 (CET)

> you running a real DNS cache on the same machine?

It is possible, especially with the example that you've posted, that the
design decision that lead to trying to obtain an 'A' from the additional
section of a 'MX' answer was made at a time when Internet links were
relatively expensive, and/or at a time when the memory footprint of a DNS
cache was not available on every machine.

Of course nowadays, the design of a new piece of software doesn't have to
take into account costs incurred by the entity running their software as
bandwidth/memory/cpu is so cheap, mores the pity.

--==--
Bruce.

---

From: [email-masked]
Date: Sun, 12 Jan 2003 10:32:32 +1100

> available questions, with the exception of the SOA negative presence

	The update code in libresolv will take advantage of the NS RRset
	if it is there along with the address records in the additional
	section when determining the zone a particular domain name belongs
	to.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Michael Milligan <[email-masked]>
Date: Sat, 11 Jan 2003 16:43:10 -0700

> [btw, I wonder why the ORG NS records are in COM? Seems silly]

They are not "in COM" of course... the gTLD servers, which are authoritative 
for com, are also still authoritative for org.  I'm sure that's the case 
only for the transition of org to Afilias, but you never know how long QA 
can take when it comes to the gTLD servers...  ;-)

Side note:  I do find it interesting that a.gtld-servers.net and 
g.gtld-servers.net have TTLs of 172800 (2 days) for the org NS record set 
and the rest of the gTLD servers have 518400 (6 days).

Regards,
Mike

-- 
Michael Milligan  --  Free Agent  --  [email-masked]

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Jan 2003 01:12:13 -0000

Bruce Campbell writes:
> the memory footprint of a DNS cache

You think that it's better use of memory to have separate caches---plus
separate caching code---in every application?

Bad design decisions like this are responsible for most of the bloat in
programs like sendmail and named. It's particularly sad when one bloated
program uses the size of another bloated program as an excuse to add
even more bloat to the first instead of reusing the second.

---

From: Bruce Campbell <[email-masked]>
Date: Sat, 18 Jan 2003 11:57:37 +0100 (CET)

> separate caching code---in every application?

In the original context that I provided, it _was_ a better usage of
_resources_, not necessarily memory, to re-use information previously
received due to the greater expense of asking for the same information,
_at that point in time_ (ie, more expensive internet links, more expensive
cpu, more expensive memory).

--==--
Bruce.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 18 Jan 2003 12:22:11 -0000

Bruce Campbell writes:
> more expensive internet links, more expensive cpu, more expensive memory

I'm not saying that bandwidth, CPU time, and memory are free. I'm saying
that the costs of the strategy you're advocating outweigh the benefits.
A machine-wide cache is better than an ad-hoc cache in every program.

---

From: Bruce Campbell <[email-masked]>
Date: Mon, 20 Jan 2003 11:56:07 +0100 (CET)

On 18 Jan 2003, D. J. Bernstein wrote:

[ danny boy, you may wish to re-read this thread to understand why I keep
  putting in the original context.  I dislike having my words quoted out
  of context in order to uphold statements outside said context. ]

> Bruce Campbell writes:
: > On 16 Jan 2003, D. J. Bernstein wrote, removing the original context:
: > > You think that it's better use of memory to have separate caches---plus
: > > separate caching code---in every application?
: > In the original context that I provided, it _was_ a better usage of
: > _resources_, not necessarily memory, to re-use information previously
: > received due to the greater expense of asking for the same information,
: >_at that point in time_ (ie,
> > more expensive internet links, more expensive cpu, more expensive memory).
>
> I'm not saying that bandwidth, CPU time, and memory are free.

Neither am I.  You may wish to re-read this thread to understand the
difference between the inverse of 'more expensive', ie 'cheaper' and
'free'.

> I'm saying

Given that I haven't been advocating any particular design strategy for
writing programs today, I suspect that you meant to write:

| I'm saying that the costs of using such an old strategy today outweigh
| the benefits.

You may wish to re-read this thread to understand the difference between
the two statements.

> A machine-wide cache is better than an ad-hoc cache in every program.

Not quite correct.  You probably mean:

	A machine-wide cache is better than an ad-hoc cache in most
	programs written today.

There are programs written today which implement their own (DNS) caching
simply because their design goal is pure speed, and the local machine-wide
(DNS) cache, irrespective of the author of such, is too slow for their
particular needs.

You may wish to re-read the thread to understand why I put forward my
thoughts on such a design strategy for times past in the first place.

--==--
Bruce.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 20 Jan 2003 11:57:53 -0000

I'm not just saying that ad-hoc per-program DNS caches are bad design
today. I'm also saying that they were bad design twenty years ago.

The traffic argument is, and has always been, silly: a machine-wide
cache saves more traffic. The memory argument is, and has always been,
silly: a machine-wide cache uses less memory. The CPU-time argument is
not silly, but if you measure carefully then you'll see that it's wrong.

More importantly, all three arguments reflect a serious failure to put
costs in perspective. As Knuth wrote thirty years ago:

   There is no doubt that the ``grail'' of efficiency leads to abuse.
   Programmers waste enormous amounts of time thinking about, or
   worrying about, the speed of noncritical parts of their programs, and
   these attempts at efficiency actually have a strong negative impact
   when debugging and maintenance are considered. We _should_ forget
   about small efficiencies, say about 97% of the time; premature
   optimization is the root of all evil.

No rational estimate for the benefits of sendmail's ad-hoc DNS cache
could ever have justified the lines of code spent on that cache.

---

From: Alexis Yushin <[email-masked]>
Date: Mon, 20 Jan 2003 13:25:33 +0100 (CET)

>not silly, but if you measure carefully then you'll see that it's wrong.

I think the real arguement here is that resolving process, quite often
lengthy, potentionaly blocking operation, can dramatically impact the
performance of the application unless optimized. Having dns cache built
in ensures that the application does not rely on external software and
will function reasonably even when no machine-wide dns cache software
is in use, which is quite often the case.

Now if machine-level dns caching was a standard feature of the resolver
library or the operating system, I'm sure nobody would be implementing
custom built in program-level dns caches. Until them I'm afraid it does
make sense to avoid complicating dependancies.

Alexis