[GnuDIP] gnudip tinydns

2002-02-14 Thread Thilo Bangert

Please remember to reply to the mailing list, not the original sender:

  http://gnudip2.sourceforge.net/#mailinglist

+

Hi,

i am about to set up gnudip with tinydns. is there anybody who has 
tried this. i understand that until the release of 2.3.5 there has not 
been anybody and a google search did not find anything that way

my first impression is, that it can't be that dificult...
but that is, how it usually goes, right?

kind regards
Thilo


--
GnuDIP Mailing List
http://gnudip2.sourceforge.net/#mailinglist



Re: [GnuDIP] gnudip tinydns MX - one more comment

2002-02-17 Thread Thilo Bangert

Please remember to reply to the mailing list, not the original sender:

  http://gnudip2.sourceforge.net/#mailinglist

+

On Sunday, 17. February 2002 19:23, you wrote:
 Creighton MacDonnell wrote:
   for gnudip this means the following: either the frontend needs a
   tinydns mode - where you are only allowed to enter ip addresses
   for mx records, or the gdiptinydns.pl needs to lookup the
   ipadress behind the entered domainname.
  
   personally i prefer the first solution, as it would keep the
   gdiptinydns.pl script clean and fast.
 
  And I would prefer to keep GnuDIP clean and simple. You can of
  course just turn MX off in the GnuDIP Administrative Settings.
  Then you can just ignore this in gdiptinydns.pl. How important is
  MX?

 I should also point out that if the MX name was looked up at the time
 the GUI user enters it, then a change to the IP address for the MX
 name would not get picked up when a reload is done. If it is done, it
 should be done in the reload process.

  Since Bersnstein may soon do this in tiny-data, perhaps you should
  not bother putting it into gdiptinydns.pl.

 I could add the lookup to gdiptinydns.pl without a lot of work. I
 could also add a back end option that would allow one to specify a
 maximum time between reloads, so that a reload would get done at
 intervals, and pick up MX address changes.

 Let me know.

this would make sense, but i still think patching gnudip is alot better 
and alot more tinydns like, because it lets you use gnudip + tinydns 
the way tinydns is meant. people using tinydns will be very aware of 
the implications mx and ns records have (CNAME also)...

i don't know

Thilo



--
GnuDIP Mailing List
http://gnudip2.sourceforge.net/#mailinglist



Re: [GnuDIP] nsupdate djb's dnscache are not friends :-(

2002-04-22 Thread Thilo Bangert

Please remember to reply to the mailing list, not the original sender:

  http://gnudip2.sourceforge.net/#mailinglist

+

On Monday, 22. April 2002 21:03, you wrote:
 Hi,

Hi


 I just installed GnuDIP 2.3.5 and was toying around and
 adjusting things when it suddenly stopped working. I
 couldn't update via web or via tcp... I checked and
 noticed that in fact, I wasn't able to make a
 successful nsupdate even via command line.

 I added -d to nsupdate and saw that the error message
 said something about not getting a SOA record.

 A host -t soa host.dyndomain.mydomain.com didn't get
 a SOA record but, as far as I remembered, never did.
 The SOA belongs to dyndomain.mydomain.com not to
 host.dyndomain.mydomain.com.

 After a while I remembered I had changed the order of
 the nameserver entries in /etc/resolv.conf in the
 GnuDIP host.

 Originally there was a BIND resolver (not the BIND
 authoritative server) and I had put it below a DJB's
 dnscache.

 After digging enough I noticed the following.

 With the BIND resolver I got the following:
  # dnsqr any host.dyndomain.mydomain.com
  255 host.dyndomain.mydomain.com:
  97 bytes, 1+0+1+0 records, response, authoritative, nxdomain
  query: 255 host.dyndomain.mydomain.com
  authority: dyndomain.mydomain.com 10 SOA ns1.dyndomain.mydomain.com
  hostmaster.dyndomain.mydomain.com 2002042214 10800 3600 360 10

 And with DJB's dnscache:
  # dnsqr any host.dyndomain.mydomain.com
  255 host.dyndomain.mydomain.com:
  41 bytes, 1+0+0+0 records, response, authoritative, nxdomain
  query: 255 host.dyndomain.mydomain.com

 Note that BIND includes an authority section for
 whoever has authority to that domain, whereas dnscache
 does not.

 The point is, if you are using nsupdate, you CAN'T
 resolve via dnscache.

why do you conclude that? i can't seem to follow you...

-- 
regards
Thilo

--
GnuDIP Mailing List
http://gnudip2.sourceforge.net/#mailinglist