DNS Propagation

Thu Oct 14 18:51:25 UTC 2010

When you created these as name servers or used them for the first time
at Network Solutions, you had to create name server records and register
the IP address at that time.  That's how glue records get inserted into
the root servers.

Otherwise the world could not find dataprom.com.  If the world was not
given the ip address of ns1 or ns2.dataprom.com via glue records, the
world would not know how to find your name servers.

At Network Solutions, you log into your account there, go to Manage
Domains, then manage the dataprom.com domain.  On the next page that
comes up from Network Solutions, scroll down and under More Domain
Options, click on Manage Name Servers.  This is where you manage the
glue records for your name servers.

Lyle Giese
LCR Computer Services, Inc.

João Alberto Kuchnier wrote:
> Lyle,
>
> Domain registrar like Network Solutions? My domain account is set to ns1
> and ns2, no by IP address.
>
> João K.
>
> Em Qui, 2010-10-14 às 13:15 -0500, Lyle Giese escreveu:
>   
>> You need to go to your domain registrar and change the ip address
>> there for these name servers.  That data is inserted as glue records
>> to the root servers.
>>
>> Without the domain name and name servers involved I could not have
>> helped you find this issue.
>>
>> I get my own messages back from the list, but you do need to reply to
>> the list and I sometimes forget as this list server does not put the
>> list in as the from address and my reader does not pick that up.
>>
>> Lyle Giese
>> LCR Computer Services, Inc.
>>
>> João Alberto Kuchnier wrote: 
>>     
>>> Sorry about that. The domain is dataprom.com.
>>>
>>> ns1.dataprom.com -> 200.198.101.3
>>> ns2.dataprom.com -> 200.198.101.4
>>>
>>> More log errors:
>>>
>>> Oct 14 14:06:06 ns1 named[4602]: error (connection refused) resolving
>>> '96.197.97.81.sbl-xbl.spamhaus.org/A/IN': 200.198.101.4#53
>>> Oct 14 14:06:06 ns1 named[4602]: error (connection refused) resolving
>>> '96.197.97.81.bl.spamcop.net/A/IN': 200.198.101.4#53
>>> Oct 14 14:06:06 ns1 named[4602]: error (connection refused) resolving
>>> 'cpc3-seac12-0-0-cust351.7-2.cable.virginmedia.com/SPF/IN':
>>> 200.198.101.4#53
>>> Oct 14 14:06:06 ns1 named[4602]: error (connection refused) resolving
>>> 'ns1.virginmedia.net/A/IN': 200.198.101.4#53
>>> Oct 14 14:06:06 ns1 named[4602]: error (connection refused) resolving
>>> 'cpc3-seac12-0-0-cust351.7-2.cable.virginmedia.com/TXT/IN':
>>> 200.198.101.4#53
>>> Oct 14 14:06:16 ns1 named[4602]: client 200.103.142.207#50955: query
>>> (cache) '10.8-15.101.198.200.in-addr.arpa/PTR/IN' denied
>>> Oct 14 14:06:16 ns1 named[4602]: client 201.10.124.1#40978: query
>>> (cache) '10.8-15.101.198.200.in-addr.arpa/PTR/IN' denied
>>> Oct 14 14:06:16 ns1 named[4602]: client 201.10.124.1#45863: query
>>> (cache) '10.8-15.101.198.200.in-addr.arpa/PTR/IN' denied
>>> Oct 14 14:06:16 ns1 named[4602]: client 200.103.142.207#50955: query
>>> (cache) '10.8-15.101.198.200.in-addr.arpa/PTR/IN' denied
>>> Oct 14 14:06:16 ns1 named[4602]: client 201.10.124.1#50880: query
>>> (cache) '10.8-15.101.198.200.in-addr.arpa/PTR/IN' denied
>>> Oct 14 14:06:16 ns1 named[4602]: client 201.10.124.1#20633: query
>>> (cache) '10.8-15.101.198.200.in-addr.arpa/PTR/IN' denied
>>> Oct 14 14:06:33 ns1 named[4602]: client 189.26.117.170#1032: query
>>> (cache) '10.8-15.101.198.200.in-addr.arpa/PTR/IN' denied
>>> Oct 14 14:07:03 ns1 named[4602]: error (connection refused) resolving
>>> 'orsp.f-secure.akadns.net/A/IN': 200.198.101.4#53
>>>
>>> Looks like my slave DNS is refusing masters connection. Some querys are
>>> pointing to my old reverse configuration
>>> (8-15.101.198.200.in-addr.arpa). Now it is:
>>> 0-15.101.198.200.in-addr.arpa
>>>
>>> I'm not receiving the discussion list e-mails. Is that normal?
>>>
>>> Em Qui, 2010-10-14 às 11:16 -0500, Lyle Giese escreveu:
>>>   
>>>       
>>>> João Alberto Kuchnier wrote:
>>>>     
>>>>         
>>>>> Hi Everyone!
>>>>>
>>>>> Recently I enabled a new IP range on my firewall. I used this bigger
>>>>> range to organize my DNS records like mail, www, ns1, ns2, and others. I
>>>>> did this last weekend.
>>>>>
>>>>> I find out that some DNS servers updated themselves with my new
>>>>> registers. However, CheckDNS
>>>>> (http://www.checkdns.net/quickcheckdomainf.aspx) stills resolving to my
>>>>> old servers. 
>>>>>
>>>>> I changed every record, every file of all my domains, serials, firewall
>>>>> rules using the new IPs but I'm still having problems. Moreover, some
>>>>> mail servers are rejecting messages from my main domain.
>>>>>
>>>>> Here are some logs:
>>>>>
>>>>> Oct 14 11:50:48 ns1 named[2929]: error (connection refused) resolving
>>>>> 'otwbhqbg.net/A/IN': 200.xxx.xxx.xxx#53
>>>>> Oct 14 11:50:48 ns1 named[2929]: error (connection refused) resolving
>>>>> 'yuogkiz.net/A/IN': 200.xxx.xxx.xxx#53
>>>>> Oct 14 11:51:05 ns1 named[2929]: client 65.202.203.203#9026: query
>>>>> (cache) '12.8-15.xxx.xxx.xxx.in-addr.arpa/PTR/IN' denied
>>>>> Oct 14 11:51:05 ns1 named[2929]: client 65.202.203.203#1765: query
>>>>> (cache) '12.8-15.xxx.xxx.xxx.in-addr.arpa/PTR/IN' denied --> this query
>>>>> problem is pointing to my old reverse.
>>>>>
>>>>> Can someone help me?
>>>>>
>>>>> João K.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> bind-users mailing list
>>>>> bind-users at lists.isc.org
>>>>> https://lists.isc.org/mailman/listinfo/bind-users
>>>>>       
>>>>>           
>>>> Since you chose to hide the real domain names, there is not much we can
>>>> do to help.  Most of us here like to do a couple of queries so that we
>>>> can view what your dns servers are serving up for data.  It may not be
>>>> what you expect, but we can not do that in this case. 
>>>>
>>>> With that said, there always is some gap due to TTL's. 
>>>>
>>>> When changing IP addresses, it's best practice to lower the TTL on all
>>>> records effected by the change.  If your normal TTL  is set to 1 day, 2
>>>> days before the change lower that to say 1 hour. 
>>>>
>>>> When changing the zone files to the new ip addresses, put the TTL back
>>>> to what it was.
>>>>
>>>> That still won't help you with a dns checking service that forces a
>>>> longer TTL than you request.  They are doing a disservice to you and the
>>>> community if they are doing that without telling you about it.
>>>>
>>>> Lyle Giese
>>>> LCR Computer Services,Inc.
>>>>
>>>>     
>>>>         
>>>   
>>>       
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>     
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20101014/c51805b4/attachment.html>