active directory - dns settings for SERVER 2003 domain controllers for a new client of mine

I have recently taken over a new client in a windows server 2003 domain environment. The only issue i see with the setup is that the second domain controller's dns entries might be wrong, hence why i am posting here. Here is the network setup.

• two domain controllers


• Domain controllers are DC1 and DC2



• both Domain Controllers are Active Directory Integrated and have their DNS AD integrated too.




• DC1 DNS settings
  dns1: points to itself so DC1, dns2: points to nothing, it is blank?



• DC2 DNS settings
  dns1: points to main domain controller with the fsmo roles so DC1, dns2: points to itself so DC2

i have always set the DNS entries of domain controllers to themselves for the first DNS entry and to the other domain controller for the second entry. If it were me doing this for the client my settings would look like this

• DC1
  dns1 points to DC1, dns2 points to DC2




• DC2
  dns1 points to itself so DC2, dns2 points to DC1

i thought that server 2003 addressed the issue with DNS island that used to happen to domain controllers in Windows Server 2000 enviroments?

Answer

Yeah, you're dead on; best practice is to point each DC to itself (127.0.0.1) as primary, and the other DC as secondary.

Along the same lines, you may want to make sure that the zones are being replicated using the new (well, old, but newer than 2000) directory partitions; make sure that the replication method is set to "All DNS Servers in Domain/Forest", not the 2000-compat mode of "All DCs".

domain name system - Why send authoritative nameserver in DNS?

Out of curiosity, I'm checking the Wireshark DNS packets. I can see that there's a DNS query from the host, and then DNS response from the DNS server. Everything is just as expected.

However, if you further check in the query, you can see that the server also sends the NS (authoritative name server). My question is: why?

As a host, I only care about the IP. That's the main point of DNS, to resolve a name into an IP address.

Why, as a host, would I need the NS info?

Answer

Traditionally name servers don't send a short response to a query but an RFC 1034-1035 compliant full response which includes the authority section that contains Resource Records that point toward the authoritative name server(s).

The why is probably because with the distributed and delegated nature of DNS it seemed a good idea at the time to include the "source of truth" in responses.

Edit: By the way: sending the authority section is RFC compliant but not mandatory for all query responses.

In BIND this behaviour can be tuned with the minimal-responses yes | no; directive, where the default is no and the Authority and Additional sections of the query response will always be fully populated.
Other name servers CloudFlare, AWS Route 53, Infoblocks and probably others will already always send such minimal responses by default. Google's public resolvers will return an Authority section when available, Cloudflare.

---

I think the origin of that tradition to include both the authority section in as well as the actual query response finds its root in the (pseudo) code from the now obsolete RFC882 page 15-16

If the name server is not authoritative, the code copies 
the RRs for a closer name server into the response.  


The last section of the code copies all relevant RRs into the response.

To zero pad hostnames or not?

Given an array of similar hosts, what are some of the advantages and disadvantages of zero padding or not?

Zero Padding

   www-01
   www-02
   ...
   www-11
   www-12

No Padding

   www-1

   www-2
   ...
   www-11
   www-12

I've seen both in practice and have heard reasons for/against each. The only snippet I've come across referencing zero padding is a small note in the Debian addclients manpage, but no reasoning:
"Padding hostnames with zeros is not recommended." Does anyone know what background or justification might be behind this recommendation?

Pros

• Simple alphanumeric sorting


• Fixed width

Cons

• Breaks down after the maximum padded id (99, 999, ...)



• Adds slight complexity to any comparison/validation (^\w+-\d{}$ vs ^\w+-\d+$)

Answer

FWIW, we pad for consistency. That way we know that $hostname always has $x digits, so it saves a step. And saving 1 step on 3,000 machines goes a long way (about 1.5 miles, to be exact).

Of course, let's look at both sides. The Pros? For me it was discussed above. Host name consistency, and some people (myself included) enjoy looking at rows upon rows of host names that are all the same length, since I'm in charge of configuration here and all those machines with the exact same name are the exact same length in my spreadsheet and have the exact same configuration in real life. Ahh, what a relief.

The cons? The only one I can think of is that you make the padding too small, for instance padding 2 zeros and you wind up with over 100 hosts. What do you do? Forget about it? Rename the first 99 hosts? Making the padding too large really has no harm I can see, other than being able to use that space for something else (site code, workstation code, etc.).

Yes, in the end it's entirely up to you, but I think the votes on this answer will give the general community consensus, up or down.

amazon ec2 - MongoDB on EC2 - R3 vs R4

I have a 3 nodes RS on EC2.
All the nodes are running on r3.2xlarge, which has EBS Optimized turned on.

Recently, AWS released the r4 series, which is described as a better version of r3 - faster memory, better networking, lower costs.
However, the r4 series doesn't have the EBS Optimized option. It does have "12 Gbps of dedicated throughput to EBS".

Is it a good idea to move the nodes to the r4 series or the EBS Optimized option is crucial (and not overcome'd by the dedicated throughput to EBS)?

Ubuntu 12.04 services using ipv6

I currently manage two servers on Linode. The first "server-a" is running 12.04, the second "server-b" is a fresh install of 14.04.

A while ago I had some trouble with spf records on server-a and came to the realization that I needed to explicitly add (or create an A record for) the ipv6 address since the postfix service was using ipv6 to connect to gmail. This was surprising to me since I just assumed it would be using ipv4 by default. After a bit more followup I discovered that nearly all services were using ipv6 in some cases but not others.

For instance, if postfix delivers mail, or if I telnet or ssh to another host on Linode my ipv6 address shows up the log. On the other hand if I connect to my local server here at home or to one on Digital Ocean's network, ipv4 is used.

Can anyone explain when and how it is determined that ipv4 or ipv6 should be used when establishing a connection? Does it vary from service to service or is this part of a central configuration?

Answer

Services are usually accessed using a hostname, which usually means that DNS is used to look up the IP address(es) linked to that hostname. For IPv4 there will be A records, and for IPv6 there will be AAAA records. All those addresses are supposed to offer the same service, independent of the protocol used.

So if you send email to Gmail your mailserver will look up the MX (mail exchange) records for gmail.com. From my point of view those are:

gmail.com.  MX  5   gmail-smtp-in.l.google.com.
gmail.com.  MX  10  alt1.gmail-smtp-in.l.google.com.
gmail.com.  MX  20  alt2.gmail-smtp-in.l.google.com.
gmail.com.  MX  30  alt3.gmail-smtp-in.l.google.com.
gmail.com.  MX  40  alt4.gmail-smtp-in.l.google.com.

The highest priority MX is gmail-smtp-in.l.google.com, so let's look at its addresses:

gmail-smtp-in.l.google.com.  A     74.125.136.26
gmail-smtp-in.l.google.com.  A     74.125.136.27
gmail-smtp-in.l.google.com.  AAAA  2a00:1450:4013:c01::1b

So now your mailserver has three addresses it can use. DNS doesn't tell you which one is preferred. That choice is up to your local software. There is a whole RFC about the algorithm to use (RFC 6724) but it usually boils down to: use IPv6 when available, otherwise IPv4.

Postfix (≥ 2.9) will, unless explicitly configured otherwise, use both IPv4 and IPv6 when available. It will first try IPv6, and if it can't connect using IPv6 it will connect using IPv4.

Web browsers work in a different way these days since the invention of Happy Eyeballs / RFC 6555. Because connectivity problems on IPv6 would cause annoying or even unworkable timeouts a browser will try to use IPv6, but if it hasn't heard anything after ±200ms it will try to connect using IPv4 in parallel. The first connection to succeed will be used.

And of course: if the service you are using doesn't advertise any IPv6 addresses in DNS then only IPv4 will be used. And vice versa.

Azure sql server cannot create database

I am trying to create a database in Azure SQL server. However, when I try to create it, it prompts "Gen4 family is not available in this region" and cannot create the database. What is the problem?

windows server 2008 - Procedure for rebooting Domain Controllers?

We have several servers running as Domain Controllers, "DC01", "DC02", and "DC03". For some reasons, we need to reboot them.

Is there a specific procedure to follow?

Additional info: "DC01" currently holds all FSMO roles. Should I transfer the roles to another DC before rebooting it?

More information: DC01 is Windows 2008 Enterprise. DC02 and DC03 are Windows 2008 R2 Enterprise.

Answer

No need to stagger reboots. Active Directory, being a multi-master system, can sustain any order of domain controller reboots.

As for safety and redundancy, it is nice to have roles spread across different DCs, so consider that for a future project. However, that won't be a consideration for reboots.

EDIT

To address the following comment:

I read somewhere that transferring FSMO Roles, although not necessary,
might be a 'defensive move', just in case the server somehow failed to
be back up. (Thus, reboot DC02 & DC03 first, transfer the role, then
reboot DC01).

I think that it makes sense from a strictly theoretical point of view. A domain controller with all FSMO roles that goes sneakers up is a horrifying thing to endure. However, in practice, I see two problems:

1. A server should not be thought of like a tumbler of nitro glycerine on the back of an epileptic lemur. If preparing to reboot your server causes dizziness, gives you a dry mouth, and otherwise makes you want to start abusing household cleaning products, then the solution is not to start moving FSMO roles, but rather to get your server into a state of health that makes you comfortable with rebooting it. Well managed servers are robust things that can be rebooted with impugnity.


2. Moving FSMO roles, while as technically simple as a few mouse clicks in an MMC, isn't such a lighthearted thing that would cause one to play a rousing game of "FSMO, FSMO, who's got the FSMO!" for every Patch Tuesday (which coincidentally precedes "Career Change Wednesday").

In short, don't move FSMO roles except to practice good systems engineering tenets. Unless your server room is full of lemurs. In which case, hey... lemurs!