Topic: Accessing sme resources from internal computers NOT using sme for DNS

[rgmhtt]

I have systems that I want to be able to access sme services, but they cannot use sme for their dns resolver.  Since I run my own DNS server (BIND on Centos 5), I want that server to secondary my sme domain.

I have searched around here, but not on the tinydns website, is there a way within the sme framework to allow a server to fetch a domain, or is this wide open and all I have to do is set up the slave information in my primary server?

I did find: http://forums.contribs.org/index.php/topic,42527.0.html

Which pointed me to where tinydns keeps its records:  /var/services/tinydns/root/data

Is there any other directory I should be looking at?

[David Harper]

You can configure SME to use an upstream corporate DNS server.

You would then instruct your SME clients to use SME Server as their primary DNS server (this is done automatically if you use SME as the DHCP Server); they would inherit all your records from the existing CentOS DNS server.

[rgmhtt]

This I understand.  But it is the other direction that I am concerned about.

sme is domain test.htt-consult.com.  I want my OTHER systems, not just those in this domain to access the sme server.  Now I will set up an NS record for the delegation.  So this will direct other 'corporate' users to the sub-domain.  But I would like to have my corporate DNS server secondary the domain.  So sme would have to allow my server to do a fetch and to send a notify to it.  Of course if you ARE using DYNDNS (which in an earlier post I was told you were not), then that would be a lot of notifies and fetches, perhaps not the best thing to do!

[janet]

rgmhtt

I'm unsure what you are trying to do.
Are you wanting to configure sme server as a public secondary Nameserver, and fetch zones from a primary nameserver ?

sme is not a public nameserver in it's default configuration.

[rgmhtt]

I will be quite detailed.

sme1 is on an RFC1918 network (I know all about rfc1918, I was one of the authors) and running as domain test.htt-consult.com.

onlo.htt-consult.com is the master DNS server for htt-consult.com; onlo is a Centos 5 system.  As such, onlo will have in the htt-consult-zone file records to delegate test.htt-consult.com to sme1.test.htt-consult.com and I will have to have a glue record so that this is resolvable within this zone file (you are not suppose to put an IP address in an NS RR, so you get these glue problems in delegations).

At this point, if medon.htt-consult.com that uses onlo.htt-consult.com as its DNS server, needs to access URL http://www.test.htt-consult.com, it will query onlo which will return that sme1 is authoritative for test.htt-consult.com.  medon will then query sme1 (that is the way it should work) and get 192.168.128.12 as the IP address of the URL.

Fine.  It SHOULD work, and I hope to have this setup later today....

[oops, onlo can query sme1 itself, and return the IP information and cache this result for later use.  This is frequently the way things are done, and can result in some fun cache poisoning situations]

But additionally, I would like onlo to be a secondary server for the zone test.htt-consult.com.  This is very standard DNS stuff, but care has to be taken if the zone in question is updated via DYNDNS.

So to setup a secondary DNS, there are two steps:

On the primary you add an NS record for the secondary server, and you setup a notify to that server so it gets the changes pushed to it, rather than having to pull.

On the secondary, you define the zone and create the file(s) where the zone information will be stored.

So for sme, I have to be able to add this second NS record into the test.htt-consult.com zone file, and I have to specify it to notify onlo of any changes.

Is that clearer than typical DNS mud?

BTW, although I have been configuring BIND since '93, I tend to use webmin.  I frequently make changes 'by hand' but just as often use the webmin BIND tool.  When you only make DNS changes once every few months, you have to think:  'Now how do I do that again'.

[janet]

rgmhtt

Clear as mud !
Good luck.
It can be done if you know what you are doing.

[rgmhtt]

ARGH!!!

sme will not honor requests as master to a stub....

There is no way to add a second NS record or anything else.

And I have to split....

Well at least I will probably see Daniel to ask him directly about doing this with tinydns, plus there will be LOTS of BIND people.

[janet]

rgmhtt

... doing this with tinydns...

Here's an earlier version of the rpm mentioned elsewhere. It may give clues or help to achieve what you want.
http://www.gormand.com.au/smeserver/WIP/smeserver-tinydns-public/

[CharlieBrady]

I have systems that I want to be able to access sme services, but they cannot use sme for their dns resolver.  Since I run my own DNS server (BIND on Centos 5), I want that server to secondary my sme domain.

Don't do that. If you have existing DNS infrastructure, then don't use SME server for DNS services for your LAN.

I have searched around here, but not on the tinydns website, is there a way within the sme framework to allow a server to fetch a domain, or is this wide open and all I have to do is set up the slave information in my primary server?

The tinydns website is the place to learn about tinydns. That said, SME server has no axfr service - there is no TCP access to the authoritative data that tinydns serves in SME server. Records are only accessible via the recursive resolver - dnscache.

[OT - Maybe I'm the only one, but I find your frequent references to your many achievements tiresome.]

[rgmhtt]

Don't do that. If you have existing DNS infrastructure, then don't use SME server for DNS services for your LAN.

I was coming to that conclusion.  Just have to get all the CNAMES I need to set up.  This seems to be well covered in the docs.

The tinydns website is the place to learn about tinydns. That said, SME server has no axfr service - there is no TCP access to the authoritative data that tinydns serves in SME server. Records are only accessible via the recursive resolver - dnscache.

Which is pretty much all NTdomain needs, all the more reason to stay away from AD type services.  Thanks for confirming this.

[OT - Maybe I'm the only one, but I find your frequent references to your many achievements tiresome.]

When I set up a couple local networks:

192.168.128.16     255.255.255.240     16           
208.83.67.144    255.255.255.248    8    192.168.128.17    
208.83.67.152        255.255.255.248    8    192.168.128.17

And get the following message:

Operation status report

Successfully added network 208.83.67.144/255.255.255.248 via router 192.168.128.17.

Your server will grant local access privileges to 8 IP addresses in the range 208.83.67.144 to 208.83.67.151.

Warning: the ProFTPd FTP server cannot handle this nonstandard subnet mask. The simpler specification 208.83.67. will be used instead.

===============================================

What is non-standard here?  Perfectly proper CIDR blocks, thank you.  I suppose another bug report.  If I wanted to allow ALL of my /26 allocation I would use 255.255.255.192 for net 208.83.67.128.  But I don't want all of my address space to access sme, so this is correct.

There is a LOT OF GOOD work here, and I really recognize what has gone into this, as I have played around with a lot of the separate pieces and have worked with enough really good people to appreciate what it has taken to integrate this all together.

I can write standards, some really good some 'challenging'.  Others can code software, some really good, some well.  And then there are those than can make it all come together.  My hat off to you all.

[cactus]

Warning: the ProFTPd FTP server cannot handle this nonstandard subnet mask. The simpler specification 208.83.67. will be used instead.

Not sure, but my guess is that ProFTPd considers A, B and C class subnets as standard as yours:

Successfully added network 208.83.67.144/255.255.255.248 via router 192.168.128.17.

Your server will grant local access privileges to 8 IP addresses in the range 208.83.67.144 to 208.83.67.151.

seems to be replaced by a C-class subnet as far as I can tell:

Warning: the ProFTPd FTP server cannot handle this nonstandard subnet mask. The simpler specification 208.83.67. will be used instead.

There is a LOT OF GOOD work here, and I really recognize what has gone into this, as I have played around with a lot of the separate pieces and have worked with enough really good people to appreciate what it has taken to integrate this all together.

But I get the impression you are forgetting that SME Server is to be a replacement of Microsoft SBS alike products and is intended for an audience unfamiliar with linux that want to have a manageable FLOSS replacement without too many hassle. Your desired setup seems rather complicated and judging from all references to your experience you are well beyond the level of understanding that is considered par as well as beyond the level of intended use of SME Server here.

I can write standards, some really good some 'challenging'.  Others can code software, some really good, some well.  And then there are those than can make it all come together.  My hat off to you all.

[OT - Maybe I'm the only one, but I find your frequent references to your many achievements tiresome.]

I have to agree with Charlie here, you have stated more than enough what your field of experience is and where you stand in that... so please when giving extensive replies be on topic and leave that part out... I think it might have the opposite affect of what you desire, as it might scare people from replying as they are not such gurus as you say you are.

[Stefano]

[OT - Maybe I'm the only one, but I find your frequent references to your many achievements tiresome.]

hey, are you into my mind?
I was thinking the same and writing a post to ask the same.. should I worry about that?

Ciao
Stefano

p.s. rgmhtt: your CV and experience is impressive I hope you can teach something to me/us, I will be pleased to learn.