Curious about this DNS entry

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We have a W2k network here upgraded some time ago from NT4
There are x2 DC's, one of which is the internal network DNS server. Only
running fwd lookup zones.
I noticed on one of our member servers that there was a dnsapi entry in the
application log (event id 11157) where it could not update the PTR records.
OK no problem as there is no reverse lookup.
What did puzzle me was that it appears to have sent an update to 192.175.48.1.
I had a look further back in the archived logs and it has been doing this
for at least a year. This IP is 'pingable' and can be traced back to
prisoner.iana.org.
Can someone explain what this is about?
Thanks
 
Rob said:
We have a W2k network here upgraded some time ago from NT4
There are x2 DC's, one of which is the internal network DNS server.
Only running fwd lookup zones.
I noticed on one of our member servers that there was a dnsapi entry
in the application log (event id 11157) where it could not update the
PTR records. OK no problem as there is no reverse lookup.
What did puzzle me was that it appears to have sent an update to
192.175.48.1. I had a look further back in the archived logs and it
has been doing this
for at least a year. This IP is 'pingable' and can be traced back to
prisoner.iana.org.
Can someone explain what this is about?
Thanks
Click to expand...

Since you don't have a reverse lookup zone, DNS clients that are trying to
register PTR records are sending updates to the internet server that holds
the Public SOA master server for the IP address. In you case, since it is in
a private IP address range, it goes to prisoner.iana.org.

If you will create a local reverse lookup zone on your DCs it will become
the local SOA master server, and it will take authority over the PTR record.
 
Rob said:
Thanks Kevin.
Is this coded into the networkservice then and not configurable?
Click to expand...

This is the way all DNS servers work. It does not matter what DNS server you
are using. If a DNS registration request is sent to a DNS server, the DNS
server will attempt to locate the Authoritative server for the record,
regardless of the record type, and send the update to that server. If it is
an A record, it will attempt to locate the Authoritative DNS for the domain
name. If it is a PTR, DNS will attempt to locate the Authoritative server
for the reverse lookup and send the PTR registration request to it.. Then
the DNS update is always sent to the Master server for the record. You
cannot change this, and it is why all AD integrated DNS zones will have the
its own name on the SOA Master server, to reduce cross network registration
requests.
 
Thanks kevin you've been very helpful.

Kevin D. Goodknecht Sr. said:
This is the way all DNS servers work. It does not matter what DNS server you
are using. If a DNS registration request is sent to a DNS server, the DNS
server will attempt to locate the Authoritative server for the record,
regardless of the record type, and send the update to that server. If it is
an A record, it will attempt to locate the Authoritative DNS for the domain
name. If it is a PTR, DNS will attempt to locate the Authoritative server
for the reverse lookup and send the PTR registration request to it.. Then
the DNS update is always sent to the Master server for the record. You
cannot change this, and it is why all AD integrated DNS zones will have the
its own name on the SOA Master server, to reduce cross network registration
requests.
Click to expand...
 
Back
Top