[AusNOG] Are domain name server pointers reliant on registrar name server?

Mon Oct 29 15:58:19 EST 2018

Hi Peter, 

This scenario has happened a lot in the past before having dedicated hosting
DNS servers where DNS functions were shared for hosting and recursive
lookups. 

I suspect it still happens in smaller organisations where a client delegates
the name servers to new authoritative DNS servers without advising the
previous hosting party. I know of a few registrars that have a lot of stale
orphaned records on their servers. 

I have certainly had to raise tickets where outdated records were being
provided to clients effectively but unintentionally 'poisoning' the DNS
responses.

Proper auditing and reporting would resolve this issue.

Kind Regards,

Jim.

From: AusNOG <ausnog-bounces at lists.ausnog.net> On Behalf Of Christopher
Hawker
Sent: Monday, 29 October 2018 3:30 PM
To: Peter Fern <ausnog at 0xc0dedbad.com>; ausnog at lists.ausnog.net
Subject: Re: [AusNOG] Are domain name server pointers reliant on registrar
name server?

This is something that I have regularly seen with cPanel servers, where if a
local server is looking for www.example.com <http://www.example.com>  and it
sees that the cPanel DNS within that cluster contain a zone for example.com,
it will not look any further as it considers it "authoritative", although it
may not be.

Example: John Doe's website and domain registration for example.com is
hosted with WebHost A on server1, and the DNS is with CloudFlare. The
customer has correctly changed the nameserver records with WebHost A to
point to CloudFlare (as you would expect one to). However, WebHost A is not
aware that John has changed the nameservers over to CloudFlare and server1
still sees that there is a DNS zone for example.com on the DNS cluster. So
server1 still thinks that the local DNS cluster is authoritative but
everywhere else on the WWW see CloudFlare as authoritative.

CH.

  _____  

From: AusNOG <ausnog-bounces at lists.ausnog.net
<mailto:ausnog-bounces at lists.ausnog.net> > on behalf of Peter Fern
<ausnog at 0xc0dedbad.com <mailto:ausnog at 0xc0dedbad.com> >
Sent: Monday, 29 October 2018 3:05 PM
To: ausnog at lists.ausnog.net <mailto:ausnog at lists.ausnog.net> 
Subject: Re: [AusNOG] Are domain name server pointers reliant on registrar
name server? 

This is indeed a confusing response.

Why does your nameserver have records for a domain it does not host?  If a
user has delegated their DNS away to some other nameservers, you should not
be serving any records from your nameservers, so the described scenario
should never happen. Sounds like a problem for VentraIP to fix.

On 29/10/18 2:38 pm, Bradley Silverman wrote:

Hi Matt, 

To answer your specific question, no they wouldn't.

BUT there is an exception:

If your site was hosting with us it does add one small layer of complexity,
which often trips people up.

Servers are very arrogant, and assume they are the be all and end all. So
for instance, let's say you are using Cloudflare as your Nameservers for
example.com.au <http://example.com.au> , and your domain is with Synergy
Wholesale.

Synergy Wholesale has the nameservers:
ns1.cloudflare.com <http://ns1.cloudflare.com>  (I realize that is wrong)

ns2.cloudflare.com <http://ns2.cloudflare.com>   

Cloudflare has the same nameservers plus:
An A record pointing to the VentraIP Server you are on
(s111.syd2.hostingplatform.net.au <http://s111.syd2.hostingplatform.net.au>
)

A MX record pointing to Outlook 365 for your email

VentraIP on S111.syd2 has the records:
An A record pointing to itself 

A MX Record pointing to itself (the default for web hosting generally
speaking).

In this circumstance, S111.syd2.hostingplatform.net.au will assume it is the
DNS host. The issue comes when your website has something like a contact
form, or another user that uses VentraIP (and is on that server) tries to
send an email, it will try to deliver locally.

This is where Remote MX (in cPanel) comes into play, it tells
S111.syd2.hostingplatform.net.au <http://S111.syd2.hostingplatform.net.au>
that it isn't the email host, and to send the email out into the world to
find it's own way.

The other time this will get messy is if you have a sub domain defined on
S111.syd2 for test.example.com.au <http://test.example.com.au>  and also
have an A record defined at Cloudflare pointing off to
otherhostingcompany.com <http://otherhostingcompany.com> , the rest of the
world will go to otherhostingcompany.com <http://otherhostingcompany.com>
for the domain test.example.com.au <http://test.example.com.au> , but
s111.syd2 will look at it's own subdomain for the site, only important in
cases where your website at example.com.au <http://example.com.au>  actually
looks at test.example.com.au <http://test.example.com.au> .

I hope that answers it and doesn't make it more confusing for you!

  <https://static.ventraip.com.au/email/ventraip-corporate-mail-gif.gif> 

Bradley Silverman
Technical Operations \\ VentraIP Australia
M: +61 418 641 103 | P: +61 3 9013 8464 | ventraip.com.au
<https://ventraip.com.au/> 

On Mon, Oct 29, 2018 at 11:41 AM Matt Selbst <matt.j.selbst at gmail.com
<mailto:matt.j.selbst at gmail.com> > wrote:

Hey Bradley,

Thanks for your answer. So assuming I'm not using you for DNS hosting (e.g.
using a third party like CloudFlare or AWS Route53) then would your name
servers ever be involved in DNS queries for my domain?

-Matt

On Mon, Oct 29, 2018 at 10:13 AM Bradley Silverman
<bsilverman at staff.ventraip.com <mailto:bsilverman at staff.ventraip.com> >
wrote:

Hi Matt, 

A lot of confusing answers in here, even to me and this is my job to
understand them.

To answer your exact question without filler information:

Your registrar (Synergy Wholesale, TPP Wholesale, NetRegistry) need to have
the Nameserver records (ns1.server.net <http://ns1.server.net>  and
ns2.server.net <http://ns2.server.net> ) for the domain (Example.com.au
<http://Example.com.au> ). 

Then your actual nameservers (ns1.server.net <http://ns1.server.net>  and
ns2.server.net <http://ns2.server.net> ) actually require the exact same
nameserver records. Trust me, I have seen things go awry when this isn't the
case.

While you are technically reliant on the root, auDA, and Affilias, all their
job is to get someones request to the .com.au namespace TO the actual
.com.au domains, and not something you ever have to worry about.

All you need to do is make sure both your registrar and your nameservers
point to your nameservers. Does that make sense?

  <https://static.ventraip.com.au/email/ventraip-corporate-mail-gif.gif> 

Bradley Silverman
Technical Operations \\ VentraIP Australia
M: +61 418 641 103 | P: +61 3 9013 8464 | ventraip.com.au
<https://ventraip.com.au/> 

On Mon, Oct 29, 2018 at 6:16 AM Matt Selbst <matt.j.selbst at gmail.com
<mailto:matt.j.selbst at gmail.com> > wrote:

Right, so for the sake of clarity as I understand it from the responses -
I'm reliant on root, auDA and Afilias name servers but NOT my registrar e.g.
Synergy Wholesale, TPP Wholesale, NetRegistry etc....

On Mon, Oct 29, 2018 at 5:59 AM Peter Fern <ausnog at 0xc0dedbad.com
<mailto:ausnog at 0xc0dedbad.com> > wrote:

On 28/10/18 11:58 pm, Chad Kelly wrote:
> On 10/28/2018 11:10 PM, ausnog-request at lists.ausnog.net
<mailto:ausnog-request at lists.ausnog.net>  wrote:
>
>> The original post was asking if the registrar is relied upon here 
>> (and the answer is no).
> But the nameservers themselves still need to be listed at the 
> registrar level so that they can be found on the public internet. 
> Otherwise you run into issues with dns lookups and them not being able 
> to resolve your dns correctly.
> They call this having registry hosts.
>

registrar != registry
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net> 
http://lists.ausnog.net/mailman/listinfo/ausnog

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net <mailto:AusNOG at lists.ausnog.net> 
http://lists.ausnog.net/mailman/listinfo/ausnog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20181029/967ae2a6/attachment.html>