ns / host setup on DNS for www access question...

Chris_H

Chris_H

Greetings,

While I've been doing this sort of thing for quite some time. I have to recognize, that doesn't mean I do it the best -- or even correct way. ;) So as I'm setting up DNS on another box, as an experiment to potentially replace BIND forever; I'm wondering how I might best resolve web resolution. I have no interest in creating a www host. I would like resolution as follows:

Code: 
SERVER#1 (slave for domain.tld and hosts web access)
ns1.domain.tld

SERVER#2 (primary (authoritive) ns for domain.tld)
ns0.domain.tld
So given that ns0 is SOA
Code: 
$ORIGIN domain.tld.
@ SOA ns0.domain.tld.
All attempts to visit domain.tld via the web, will probe ns0.
Would the following solve it effectively/correctly?
Code: 
ns1 IN CNAME domain.tld.

Thanks.

--chris
 
What is it you actually want? When someone tries to connect to an address that is part of your domain domain.tld the resolution strictly follows the delegation settings that you have set for your domain at the domain registrar of domain tld. What you have in the zone files on your name server(s) is just necessary repetition of this information.
 
Greetings @kpa, and thank you for your reply.
Yes, I know. But the domain.tld is served by both ns1.domain.tld, and ns0.domain.tld.
Since ns0.domain.tld is SOA (Start Of Authority), any, and all queries will first use ns0. Which means that attempts to browse to domain.tld will land at ns0.domain.tld. The traditional solution, is to simply add the host www. So web clients will land on which ever server(s) have a www address. However, since I have no wish to add a www host (only provide www access), and I want that ns1 provide it. So, in an effort to encourage www access attempts to be directed to ns1 (the slave ns for domain.tld), I imagined that simply using a CNAME via
Code: 
ns1  IN  CNAME  domain.tld.
would be the best (or correct?) solution.

I hope I was clearer this time. :)

Thanks again, for taking the time to respond.

--chris

P.S.
Code: 
ns0  IN  A  123.456.789.876
ns1  IN  A  123.456.789.877
Different IP's, and different boxes.
www = webserver (HTTPd).

The original rr SRV used to serve this purpose. But has been since obsoleted.
 
Last edited by a moderator:
No, SOA record does not set preference for the name servers. The client may choose to use either one of the name servers listed for the domain.

Since you want the plain address domain.tld to land on a specific server, this is the usual way to do it:

Code: 
$ORIGIN domain.tld
...
        IN SOA  ns0.domain.tld. hostmaster.domain.tld. (
...
        IN NS         ns0
        IN NS         ns1

ns0   IN A          123.124.125.2
ns1   IN A          123.124.125.3 
...
domain.tld.  IN A  123.124.125.126

Note the dot at the end of domain.tld., it is needed to state that the address is absolute and not relative to $ORIGIN.

Also note that "browsing" a domain name domain.tld without the leading www part isn't anything special. It generates a same kind of DNS query as does browsing of http://www.domain.tld but because of few technical details matching the query in the zone file requires the kind of trick I've shown above.
 
Thanks @kpa. I really appreciate you staying with me on this. :)
OK. The the redundancy bit was a given -- the more, the merrier (so long as the header remains under 512). But now you've thrown me:
Code: 
$ORIGIN domain.tld
...
        IN SOA  ns0.domain.tld. hostmaster.domain.tld. (
...
        IN NS         ns0
        IN NS         ns1

ns0   IN A          123.124.125.2
ns1   IN A          123.124.125.3 
...
domain.tld.  IN A  123.124.125.126
domain.tld. IN A 123.124.125.126 -- where did this IP come from?

Thanks again.

--chris
 
Last edited by a moderator:
Chris_H said:
domain.tld. IN A 123.124.125.126 -- where did this IP come from?

Thanks again.

--chris
Click to expand...

Sorry, I didn't read all the details of your posts. That's just a generic example where a host unrelated to the name server hosts is used as the www server. It could be like this if you want direct it to ns1:

Code: 
domain.tld.  IN A  ns1

If that does not work then try with the explicit IP address:

Code: 
domain.tld.  IN A  123.124.125.3

Again these addresses are just examples, adapt to your real configuration.
 
Any connection to domain.tld will connect to that IP address. So ssh domain.tld logs you in on 123.124.125.126. Similarly http://domain.tld will connect to the web server on 123.124.125.126 port 80.
 
Ahh... Got it. :)
Traditionally I use:
Code: 
$TTL  3600
$ORIGIN domain.tld.
@  IN  SOA  ns1.domain.tld. root.localhost. (
;serial
;refresh
;retry
;expire
) ;minimum

  NS  ns1.domain.tld.
  NS  ns0.domain.tld.

  MX  0   mx0.domain.tld.
  MX  99  mx1.domain.tld.

  A  123.456.789.876

ns1  IN  A  123.456.789.876
ns0  IN  A  123.456.789.877

; But as per your suggestion, I'll add

domain.tld.  IN A  123.456.789.877
Did I understand you correctly? :)
This won't cause a loop, will it?

Thanks again @kpa. Much appreciated.

--chris

OH! Thanks for the reply @SirDice. You replied while I was replying. :)
 
Last edited by a moderator:
You want domain.tld to expand to only one or two different addresses? You already have the 876 for domain.tld (assuming it actually works that way, I do remember there was a reason to do it the way I've shown...) and you'll be adding 877 also for domain.tld. This set up would return two different A records for domain.tld as far as I can see.
 
Crap. Sorry. :(
To be clearer...
ns0 is SOA
ns1 is slave
I want web (www/httpd) to serve from ns1.

Again, sorry, and thanks.

--chris
 
Then use only this:

Code: 
domain.tld.  IN A  123.456.789.877

Or ns1 in place of the IP address, my memory is hazy if it really works that way.
 
I think there's a lot of confusion here.

The most important part here is to think of both the DNS- and the webserver as two separate entities. They don't interfere with each other and both perform completely different tasks. The only relation between the two is that the DNS server is used to resolve the right IP address to use.

I want web (www/httpd) to serve from ns1.
Click to expand...
I think you should approach your line of thinking a bit different. You don't want to serve from ns1, you want your webserver to run on the same box as your second DNS server.

And to allow people to access your website, without the www prefix, you want to point the A entry for the domain itself to the IP which is also used by the second DNS server.

So looking at your last example you should either remove the "A 123.456.789.876" or remove the domain.tld. entry and point your A record to the right IP address (so 877 instead of 876).
 
Greetings @ShelLuser, and thank you for your reply.

Well, as experience has proven; your suggestion results in log errors from the BIND (maybe different, as I'm switching to unbound) were "out of zone" or "lame server", when I used:
Code: 
$ORIGIN domain.tld.
without
Code: 
  IN  A  soa.ser.ver.ip

ns0  IN  A  soa.ser.ver.ip
ns1  IN  A  ano.th.er.ip
and only
Code: 
ns0  IN  A  soa.ser.ver.ip
ns1  IN  A  ano.th.er.ip

So. Given @kpa's advice. My only concern, would be what I see as a potential loop. As to the "protocol". It's a given that one seeking a service, will probe the appropriate port(s) until receiving an answer, or drop the request. That was never an issue, back in the day, when the stanza SRV was available/used. Seems a pity to have dropped it.

Conversely; when serving www/httpd on the secondary server (as shown above), the primary (SOA) received the majority of requests for www/httpd access. Hence my OP. :)

Thanks again, for the reply.

--chris
 
Last edited by a moderator:
SRV records are definitely in use today and are getting more and more use. I don't know where you got the idea that they have been dropped?
 
Hmmm, must have been a mis-read on my part. :r I could have sworn when reading a related RFC, that it had been "depreciated". Maybe it was the BIND doc's, it's been awhile. I'll re-read the appropriate RFC's immediately. Thanks for the "heads up". :)

--chris
 
Chris_H said:
I suppose I could always use one of acme.com's httpd's to simply throw a "301 Permanent" from the SOA. Or perhaps better; a rule in pf(4).

--chris
Click to expand...

Umm I think you still haven't gotten a few things about how DNS works. Both the primary and the secondary server must serve the same data because you can't tell the clients to prefer one server over the other. If you want to serve different data based on the client's IP address that's possible with the "view" feature of BIND but even then all the servers should return the same data to the same client.

Also do you understand that a web browser does not use the NS records when making a HTTP connection? What the browser does is a DNS query to the system resolver using the hostname of the URL. The system resolver deals with the "dirty" details of finding out the answer to the query, the answer may come from a local caching resolver or maybe from an external forwarder listed in /etc/resolv.conf. Regardless of how the query is resolved the web browser uses the raw IP address/addresses from the result of the query to make the HTTP connection.
 
kpa said:
Umm I think you still haven't gotten a few things about how DNS works. Both the primary and the secondary server must serve the same data because you can't tell the clients to prefer one server over the other. If you want to serve different data based on the client's IP address that's possible with the "view" feature of BIND but even then all the servers should return the same data to the same client.

Also do you understand that a web browser does not use the NS records when making a HTTP connection? What the browser does is a DNS query to the system resolver using the hostname of the URL. The system resolver deals with the "dirty" details of finding out the answer to the query, the answer may come from a local caching resolver or maybe from an external forwarder listed in /etc/resolv.conf. Regardless of how the query is resolved the web browser uses the raw IP address/addresses from the result of the query to make the HTTP connection.
Click to expand...

Greetings @kpa, and thanks for the reply. Already understood -- all of it. :) My intention is simply to avert unnecessary traffic. Past experience with this scenario, proved to be less than desirable. I was constantly bombarded with requests on port 80 on the SOA -- especially Google. I'm hoping to somehow thwart that. Which is why I posed the question (OP) -- perhaps not as concisely as I should have. :p

Anyway, with your kind wake up call, regarding SRV records. All the rest is probably moot. Thanks again, by the way. :)

Best wishes.

--chris
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top