Pete Ehlke | 1 Mar 2003 02:03

Re: tinydns and wildcards

On Fri, Feb 28, 2003 at 10:50:25PM +0000, Jonathan de Boyne Pollard wrote:
> KF> If you want to write a DNS server, implementing wildcards is 
> KF> not optional, and you can't make up your own either.  
> 
> False.  Proxy DNS servers have no need to know anything at all about
> wildcards, because wildcards are entirely an internal matter for content DNS
> servers.  Moreover, whether a content DNS server implements wildcards depends
> from how data are entered into its database and what kind of data those are. 
> Wildcards are just one mechanism that a content DNS server might provide for
> generating served content on the fly.  Other mechanisms are possible.

Fine. Perhaps Ketil should have said "If you're going to write an
authoritative name server that supports wildcards, you must do so in a
manner that is consistent with RFC 1034." 

BIND 9 gets it right. BIND 8 gets it wrong. Is anyone willing to defend
the proposition that tinydns gets it right?

D. J. Bernstein | 1 Mar 2003 02:27
Picon

Re: tinydns and wildcards

Pete Ehlke writes:
> "If you're going to write an authoritative name server that supports
> wildcards, you must do so in a manner that is consistent with RFC 1034." 

You are confused. The RFC 1034 wildcard specification is a suggested
configuration mechanism, not a requirement.

> BIND 9 gets it right.

False. The BIND company has admitted that BIND 9 doesn't follow the RFC
1034 wildcard algorithm.

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

Jefferson Cowart | 1 Mar 2003 02:32

Dynamic DNS

Is there any dynamic dns client/server that will work with tinydns? I
have one server that is on a dynamic IP address and I would like to be
able to provide dns for it from my other machine running tinydns.
However the only dynamic dns client/servers I have found are designed
for bind.

----------------
Thanks
Jefferson Cowart
Jeff <at> cowart.net 

spam filter | 1 Mar 2003 03:20

Large tinydns-data file kills tinydns

Hi,

I'm a DNS provider (I know how you feel about us Dan, but believe me,
most of my clients can't even spell DNS!) where I operate a network of 3
geographically separate servers, a web based interface (perl) and a
postgresql backend with scripts that dump changes to the servers 3 times
an hour. The system has been up and running for over a year with
absolutely no problems.

I had a serious issue yesterday, when out of the blue, my network of 3
DNS servers went down, taking nearly a thousand customers down with it.
It first looked like I was the victim of a distributed denial of service
attack; tailing the logs showed huge amounts of requests coming in, my
tinydns-rrd tool dns grapher shot up from an average 0.5 requests per
second to over 30. After trying to ipchains/iptable block the most
aggressive servers, I started to do some query tests all of which
failed. The server load at this point was a bit lighter and checking the
bandwidth consumption on my ISP's switches showed some traffic, but
certainly not enough to take down TinyDNS!

I checked the time the traffic spike started and it was exactly when the
cron job fired off to update the servers with a fresh data.cdb. My anger
of being clobbered by a DDOS suddenly disappeared and now my thoughts
turn to something a client did that my web interface didn't validate.
Looking at the diff's between updates of the data file revealed nothing
out of the ordinary. Note that my ordinary may not be the correct way to
do things, but they have worked great thus far and I saw know reason to
believe that anything this client did with regards to the records he can
create through our interface, would cause a problem with our server.

(Continue reading)

D. J. Bernstein | 1 Mar 2003 03:37
Picon

Re: Large tinydns-data file kills tinydns

How did you get the idea that this was a reasonable configuration? RTFM:
``You should omit ip if x has IP addresses assigned elsewhere in data.''

Fast DNS packets have a 512-byte limit. Slow DNS packets have a
65535-byte limit. It's a bad idea to go beyond 512 bytes of data for one
name, and it's impossible to go beyond 65535 bytes of data for one name.

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

spam filter | 1 Mar 2003 04:14

Re: Large tinydns-data file kills tinydns

Hi Dan, (wow fast response!)

D. J. Bernstein wrote:

>How did you get the idea that this was a reasonable configuration? RTFM:
>``You should omit ip if x has IP addresses assigned elsewhere in data.''
>  
>
It says I "should", not must ! ;-)

Ok, so this holds true for ALL my NS entries, I'll get right on it to 
clean it up. Like I said, things seemed to work well until now, it looks 
like I have to double check everything to be sure I don't get bit like 
this again.

Would this also be true for any other record types? For example, for 
CNAMEs it says:
"Don't use Cfqdn if there are any other records for fqdn."

Is this for the same reason? (Hey, here you say Don't!) :-))

>Fast DNS packets have a 512-byte limit. Slow DNS packets have a
>65535-byte limit. It's a bad idea to go beyond 512 bytes of data for one
>name, and it's impossible to go beyond 65535 bytes of data for one name.
>
So the reason I was getting hammered was that the responses where too 
big for the receiving server to understand?

Thanks again,

(Continue reading)

David Phillips | 1 Mar 2003 05:23

Re: Dynamic DNS

Jefferson Cowart writes:
> Is there any dynamic dns client/server that will work with tinydns? I
> have one server that is on a dynamic IP address and I would like to be
> able to provide dns for it from my other machine running tinydns.
> However the only dynamic dns client/servers I have found are designed
> for bind.

http://innominate.org/projects/tinydyndns/

--

-- 
David Phillips <david <at> acz.org>
http://david.acz.org/

Jonathan de Boyne Pollard | 1 Mar 2003 13:28

Re: Large tinydns-data file kills tinydns

Some more of your errors:

sf> =*.captainjoes.com:64.40.110.35:
sf> =*.chungseto.com:207.245.7.250:

Don't use bidirectional mappings with wildcards.  They don't work and the
notion is simply daft anyway.  Use a unidirectional mapping from the wildcard
to the IP address only.

sf> =captainjoes.com:64.40.110.35:
sf> =pics.conservart.com:64.40.110.35:
sf> =www.conservart.com:64.40.110.35:
sf> =conservart.com:64.40.110.35:
sf> =www.conservart.net:64.40.110.35:
sf> =conservart.net:64.40.110.35:
sf> =dschwartz.net:64.40.110.35:
sf> =www.dschwartz.net:64.40.110.35:

Don't use bidirectional mappings unless they are appropriate.  You've listed
64.40.110.35 in eight different bidirectional mappings in the snippet that you
posted alone.  Do you _really_ want to publish a mapping from that IP address
to at least eight different names ?  (Most softwares only use the first name
in such cases.)

I suspect that _all_ of these should be unidirectional mappings.

sf> Ccartise.com:www.cartise.ca:

This will cause things to go wrong.  Avoid client-side aliases in any case. 
Create separate '+' records for the two names mapping them to the appropriate
(Continue reading)

Jonathan de Boyne Pollard | 1 Mar 2003 12:50

Re: Large tinydns-data file kills tinydns

s> for CNAMEs it says:
s> "Don't use Cfqdn if there are any other records for fqdn."
s> Is this for the same reason? 

No.

s> So the reason I was getting hammered was that the responses 
s> where too big for the receiving server to understand?

Part of the reason that you were being hammered is that you only provide
DNS/UDP service, but the data sets that you were serving up were so large that
they required DNS/TCP service for their publication.

<URL:http://www.faqts.com./knowledge_base/view.phtml/aid/9673/fid/699>
<URL:http://cr.yp.to/djbdns/tcp.html#why>

Ketil Froyn | 1 Mar 2003 15:05

Re: tinydns and wildcards

On 1 Mar 2003, D. J. Bernstein wrote:

> The RFC 1034 wildcard specification is a suggested configuration
> mechanism, not a requirement.

I'd like to make a suggestion. For compatibility, tinydns should support
data of the type:
+*.name:192.168.1.1
the same way as BIND8 does. In addition, tinydns can include it's own
"improved" wildcard, something like:
+..name:192.168.1.1
that would act like the current tinydns wildcard. It should be omitted
when sending data with AXFR. Using the character "." might be a terrible
idea, but I didn't see any problems right now.

Ketil Froyn
ketil <at> froyn.name
http://ketil.froyn.name/


Gmane