Difference between A,CNAME and Alias record

What is a CNAME record?

CNAME stands for Canonical Name. CNAME records can be used to alias one name to another.

For example, if you have a server where you keep all of your documents online, it might normally be accessed through docs.example.com. You may also want to access it through documents.example.com. One way to make this possible is to add a CNAME record that points documents.example.com to docs.example.com. When someone visits documents.example.comthey will see the exact same content as docs.example.com.

To use CNAME records, select CNAME from the Add Record drop down in the advanced editor. Then enter the hostname you would like to alias from and the fully-qualified domain name you would like to alias to. You may also enter @ in the Alias for field to represent the domain itself.

For example, if the domain were example.com and you wanted www.example.com to point to example.com you could put www in the name field and @ in the alias for field.

What is an ALIAS record?

An ALIAS record is a virtual record type that we created to provide CNAME-like behavior on apex domains.

For example, if your domain is example.com and you want it to point to a host name like myapp.herokuapp.com, then you cannot use a CNAME record, but you can use an ALIAS record. The ALIAS record will automatically resolve your domain to one or more A records at resolution time and thus resolvers see your domain simply as if it had A records.

How does it work?

The DNSimple name servers are currently based on an open source Erlang DNS server that we developed along with the help of others in the DNS community. The erl-dns server provides a mechanism for plugging in custom handlers (here is a sample custom handler) and we use that extension mechanism for providing an ALIAS handler. Each time a request hits the DNSimple name servers for either an A or AAAA record type the custom handler is invoked and attempts to resolve the ALIAS into its appropriate IPv4 or IPv6 address, respectively. It does this by asking a resolver to resolve the domain. At the moment we are running PowerDNS’s resolver running locally on each system for this purpose.

If the resolution succeeds then the handler extracts the A and AAAA records and returns them to the erl-dns server process, which then goes on its merry way. It also sticks the result in an in-memory cache (you’ll see why in a second).
If the resolution fails, for example due to a timeout, then the cached response is returned, if one exists. We have the request timeout set quite low (500 milliseconds) and we may even move it lower in the future. If there is no response in the cache then the request is retried again, up to a maximum number of retries. If the request ultimately fails then we return an empty result set.

To support secondary DNS servers, especially ones that connect to us and pull zones using AXFR, we must resolve the ALIAS in a different way. Currently we resolve it as part of the secondary DNS setup process initially and then run a scheduled job to update the ALIAS record at secondary name servers by resolving them again, removing the old records and writing the new records to our zone transfer database, and then finally sending a NOTIFY message to the appropriate secondary name servers.

The actual implementation is handled by a small Go application which our Rails application calls, either from within Rails execution or in an aynchrnonous job, to handle the resolution. The Go application currently calls to Google’s public resolvers to resolve the ALIAS record.

When creating an ALIAS record you will notice than additional TXT field is created, this field is optional and it can be used for debugging purposes.

What is an A record?

An A record maps a domain name to the IP address (IPv4) of the computer hosting the domain. Simply put, an A record is used to find the IP address of a computer connected to the internet from a name.

The A in A record stands for Address. Whenever you visit a web site, send an email, connect to Twitter or Facebook or do almost anything on the Internet, the address you enter is a series of words connected with dots.

For example, to access the DNSimple website you enter www.dnsimple.com. At our name server there is an A record that points to the IP address 208.93.64.253. This means that a request from your browser to www.dnsimple.com is directed to the server with IP address 208.93.64.253.

A Records are the simplest type of DNS records, yet one of the primary records used in DNS servers.

You can actually do quite a bit more with A records, including using multiple A records for the same domain in order to provide redundancy. Additionally, multiple names could point to the same address, in which case each would have its own A record pointing to the that same IP address.

Querying A records

You can use dig to determine the A record associated to a domain name. The result is contained in the ANSWER section and it contains the fully-qualified domain name (FQDN), the remaining time-to-live (TTL) and the IP address.

$ dig A api.dnsimple.com

; <<>> DiG 9.8.3-P1 <<>> A api.dnsimple.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5792
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;api.dnsimple.com.  IN A

;; ANSWER SECTION:
api.dnsimple.com. 59 IN A 208.93.64.253

;; Query time: 80 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Jul 31 22:21:31 2016
;; MSG SIZE  rcvd: 50

A record structure

In DNSimple we represent A record with the following information:

Name	The host name for the record, without the domain name. This is generally referred as “subdomain”. We automatically append the domain name.
TTL	The time-to-leave in seconds. This is the amount of time the record is allowed to be cached by a resolver.
Address	The IPv4 address the A record points to.

Managing A records

You can create, update and delete A records for your domain using the DNSimple record editor.

What is Desktop virtualization?

What is desktop virtualization? Its many things to many people.

1. Virtual Desktop Infrastructure (VDI)
2. Session Virtualization
3. RemoteApp

In this post we will only cover what desktop virtualization is and what components, needs and challenges are addressed by desktop virtualization.

The Microsoft Virtual Academy has a great jumpstart session on VDI.  here is the overview recording.(see the link at the bottom of this post for the entire session)

VDI gives you the ability to store and offer full virtual machines (OS, Applications, Data…) on a server which may be accessed by multiple clients or devices.

Session Virtualization allows users to access entire desktops (remote desktops or “sessions”) running on servers in the datacenter. It’s Terminal Services on steroids.

RemoteApp allows you to deliver remote applications to users instead of full desktops. It enables a publishing process that allows apps on session or VDI hosts to be provided to users. It allows RemoteApps to run side by side with local apps and integrates with the Start menu to make it simple for users to find and launch RemoteApps.

In this post we’ll take a high level look at deploying VDI (full virtual machines) in Windows Server 2012. So let’s get going

1. Open Server Manager (ideally from the Server you want to host the Session Broker role), Click on Add Roles and Features , Select Remote Desktop Services Installation and Click Next

2. Select Deployment Type of Standard deployment

3. Select Virtual machine-based desktop Deployment and Click Next

4. Click Next on the Review of role Services screen

5. Specify which server to act as the RD Connection Broker Server and Click Next

6. Specify which server to act as the RD Web Access Server and Click Next

(In our example, we’re elected to host the RD Web Access role on the same host as the Session Broker role.)

7. Specify the RD Virtualization Host and Click Next

In our example we’re using the same host for all 3 roles.  The Hyper-V role will be installed if it isn’t already.

8. Confirm Selection and check mark on Restart Destination Server automatically if Required, Click Deploy

After completion of this process, you have successfully deployed VDI desktop virtualization to this box.  Now you need to configure the machine pool.  That’s next…

Virtual Desktop Collection

There are two types of virtual desktop collections available: personal and pooled. You have the option to let Remote Desktop Services automatically manage pooled virtual desktops in a collection, or you can manually manage them. We will concentrate on automatically managed pooled virtual desktop collections.

A managed pooled virtual desktop collection offers the following capabilities:

• Automatically create pooled virtual desktops based on a virtual desktop template.
• Automatically install security updates and applications based on a virtual desktop template.
• Live migration with local caching.
• User profile disk support. A user profile disk stores user profile information in a separate virtual hard disk so that user profile settings are persistent across pooled virtual desktops.

With either managed or unmanaged, the administrator can configure the pool to store the user profiles on User Profile disks separate from the machines.

Create a Pooled – Managed Virtual desktop Collection

1. Open Server Manager, Click Remote Desktop Services and Select Overview

2. In Deployment Overview Section, Click Tasks and Select Edit Deployment properties.

3. Expand Active Directory and Select the Organization Unit if you would like to add the Virtual desktops to the domain , Click Apply

4. Select Collections tile

5. In Collection Section, Click Tasks and Select Create Virtual Desktop Collection , Click Next

6. Type the Name of the Collection and Click Next

7. Select the Pooled Virtual desktop collection and Click Next

8. Specify the Virtual Desktop Template which must be pre-configured in Hyper V (ensure that your template image is syspreped) and Click Next.

9. Click Next

10. Specify the unattended installation settings and Select the OU

11. Specify the Users and Groups and Specify the Prefix and Suffix for the Virtual Desktop

12. Specify Virtual Desktop allocation and Click Next

13. Specify Virtual desktop storage and Click Next

14. Specify User Profile disk if you want with the UNC Path and Click Next

15. Confirm Selections and Click Create

16. View Progress and Click Close

17. In Collection Section, Right Click VDI( Collection Name) and Select Task Status details

Secrets OF JAVASCRIPT

Hi all,

Data from around the world

The same origin policy prevents a website's JavaScript from seeing the result of a request made to a different domain. This is essential because that request would send along any cookies stored for that domain. If you happen to be authenticated on the other site, and visit a malicious site, then the evil page could request, say, your account balance summary from the other site.

Note that the same origin policy doesn't necessarily prevent the request per se – it just prevents the response from being accessible. A malicious site can e.g. just redirect your browser, or submit a form, or include an image or an iframe – in all those cases a request is made to your site; the evil site just doesn't see the response. It doesn't have access to the iframe's DOM, painting a cross-domain image to a canvas will taint it, and so on. In some cases, it's possible for a site to say that it's okay to see the data on a different domain, but this isn't the default.

Let's look at <script> elements now. If such an element's src attribute is set, then the browser will load the script and execute it in the current page. It will do this regardless of origin (otherwise, you e.g. couldn't serve jQuery from Google's CDN). It's not possible for a site to read the content of a script that was loaded from a different domain, but any side effects of executing the script are very visible – like the jQuery object suddenly existing in your page.

This cross-domain script loading is what JSONP utilizes. If you have, say, a public API where you're entirely okay with the data being accessible cross-domain, you can enable other sites' JavaScript to use your data by returning JSONP. This essentially means you're returning JavaScript (which, as explained above, will be executed despite the different origin). The consuming site lets you know that it has prepared a function for your script to call, and what that function's name is. You return a JavaScript file that calls this very function with your data.

function theCallback(data) {
    alert("The temperature is " + data.temperature_celsius + " °C");
}
var script = document.createElement("script");
script.src = "http://some-weather-service.com/api?city=Boston&callback=theCallback";
document.head.appendChild(script);

The callback parameter tells the weather service what function to call in its JSONP response, and thus the API's response looks like this:

theCallback({"temperature_celsius":20,"temperature_fahrenheit":68})

which makes your site work as intended.

As an aside: You should only use JSONP APIs from sites that you trust, since you're allowing those sites to send you arbitrary JavaScript that you will happily execute on your own domain.

My precious

So we've established that it's possible to execute JavaScript that comes from a different domain; a site that wants to allow cross-origin access can send valid JavaScript that any site can thus embed. Now let's look at the case where the site doesn't want to allow this; it only wants the data to be accessible to requests coming from its own site.

As far as simple reading of the request's response goes, same-origin takes care of this. But you obviously also want to prevent the above “execute as JavaScript” trick from working. The lowest-hanging fruit is just making sure that your response doesn't look like a function call. However, there is such a thing as a function call in disguise – Phil Haack wrote a blog post and a more detailed follow-up on this topic, which will tell you why you shouldn't return JSON responses whose outer wrapper is an array.

But there's an even more subtle vulnerability which appears when you don't return JSON at all. Here's a real-life example I found (it was fixed in the meantime). Assume your site uses a CSRF token, and you want to make sure that a browser tab always has the up-to-date token, even when it changes. This could be because you cycle the token at regular intervals or just because in a different browser tab your user logged out and logged in again. That's why you have a route that returns the current CSRF token for the active session, so the browser can regularly poll for it.

Same-origin policy prevents other sites from seeing this token in any way, since you neither wrap it in a function call, nor in an array – in fact, you wrap it in nothing at all; you just return the token as a plain text. Your token is a 24-digit hexadecimal number, like b2039487e51a6bfdc7299de0, and these 24 characters are all that your route returns. Nothing in there that can cause a function to be executed, so even if a malicious site included

<script src="http://your-awesome-site.com/current-csrf-token"></script>

in its HTML, it wouldn't have access to the token.

Right? Nope.

Not as hidden as you'd think

Let's see what happens when a browser executes a “script” that contains nothing more than b2039487e51a6bfdc7299de0. If you try it out, you'll see that not a lot happens, except that the JavaScript console will show an error:

ReferenceError: b2039487e51a6bfdc7299de0 is not defined

The first thing to note is that this is not a syntax error. Because b2039487e51a6bfdc7299de0 is a valid JavaScript identifier, this 24-character long “script” is syntactically valid JavaScript, and the browser happily runs it. So what happens when the JavaScript engine encounters an identifier? It will look for a variable in the current scope by this name. Since the script is executed in a global context, the current scope is the window object. The engine checks whether window["b2039487e51a6bfdc7299de0"] exists, which it obviously doesn't, and thus throws an exception.

This looks like something that the malicious site cannot gain any information from, but unfortunately in Firefox, it can. Firefox supports Proxy objects by default. Chrome also supports them, but only if you enable experimental JavaScript (and with a slightly different syntax than Firefox – point being: this exploit can be made to work in Chrome as well, but currently only for users who have the experimental JS features turned on).

Proxy objects are essentially property accessors on speed. If you're used to Python, think “overriding __getattr__.” If you're used to C#, think “TryGetMember on DynamicObject.” Together with prototype magic, they enable us hook into the “looking for a variable in the current scope” process. If the user visits the following page in Firefox, the JavaScript can identify the token:

<html>
    <head>
        <script type="text/javascript">
            window.onload = function () {
                window.__proto__ = new Proxy(window.__proto__, {
                    has: function (target, name) {
                        if (/^[a-f0-9]{24}$/.test(name))
                            alert("Your CSRF token on your-awesome-site.com is " + name);
                        return name in target;
                    }
                });
                var s = document.createElement("script");
                s.src = "http://your-awesome-site.com/current-csrf-token";
                document.head.appendChild(s);
            }
        </script>
    </head>
    <body></body>
</html>

– and an alert is just the least evil thing the site can do with the token.

Observant readers may have noticed that the above only works if the token starts with a letter, since only then is it a valid identifier. But for a random hexadecimal digit that's six out of sixteen, thus a 37.5% chance. That's not too shabby. And of course it depends on what kind of data your plain-text API returns.

If the return values are predictable, and the evil site only cares about a yes-or-no question, it doesn't even need proxy objects. For example, let's say a similar route returns the user name of the currently logged-in user, and all the malicious site wants to know is whether a visitor is logged in as “balpha” on your-awesome-site.com. For that, they would just have to create a property called "balpha" with a get accessor on the global object. These are supported by all major browsers.

What's to take away from this? If you respond with plain text data to a GET request, don't be too sure that the same origin policy will save you. Either wrap your data in a JSON object (not an array!), or only respond to POSTrequests with such data (unless you're a REST zealot enthusiast, in which case POST won't always be an option), or both. Other possible mitigations include the while(1) trick, or at the very least making sure that your secret payload is not syntactically valid JavaScript.

please comment for more information and read more blog, Thank you.