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.

XML Signature(Basic to advance)

The XML Signature Standard

The XML Signature standard is an immensely complicated beast, designed by a working group involving all the big names, and intended to be a one-size-fits-all solution to building tamper-resistant XML documents. Unfortunately, as is often the case, one-size-fits-all becomes the-only-size-fits-nobody.

In a normal application of digital signatures, we take a document to be signed, run it through a cryptographic hash function, and then apply a digital signature algorithm to the hash. If the document received is exactly identical, the signature will validate, whereas if even a single bit changes, the signature becomes invalid and the document is rejected.

Unfortunately, XML Signatures have one killer feature - the standard allows us to sign part of the document instead of the whole document, and embed the signature within the same document it’s supposed to be validating - so called inline signatures. The signatures do this by containing a “Reference” to the part of the document they sign, usually by referring to the “ID” attribute of an XML element, but in theory allowing anything in the XPath standard to be used as an expression. I can, in theory, write a signature anywhere within a document that refers to the “third to last <foo> element”, or equally vague expressions.

When validating an XML signature it’s not enough to ask the question “is this a valid signature from this signer?”. We also have to ask “is this signature present, referring to the right part of the document, applying all the right canonicalizations, from the expected signer AND valid?”. All too often, at least one of these checks is not implemented.

Getting Started with SAML Raider

While all attacks described here can be carried out without many tools, SAML Raider1, a Burp proxy plugin, is a useful tool for testing the common cases.

Checks

As described above, signatures can appear in various places within the SAML message and cover various parts of the message. By keeping the content of the message but adding new parts and modifying the structure of the remaining parts, we can craft messages that are still technically signed correctly, but may be interpreted by SAML libraries as having crucial parts signed when they are not.

Whenever the Service Provider is supposed to check something, there’s an opportunity for them to fail to do so or do so incorrectly, giving us an opportunity to bypass the signature. Enable Burp’s interception, capture the SAML request, and try these transformations. Each one should be done against a fresh, valid log-in attempt, as there is usually a nonce preventing us from replaying the same request repeatedly.

For repeated attempts, you may benefit from intercepting a single endpoint only in Burp using interception options like this:

Is a Signature Required?

The SAML standard requires that all messages passed through insecure channels, such as the user’s browser, be signed. However, messages that pass through secure channels, such as an SSL/TLS back channel, do not have to be. As a result of this, we’ve seen SAML consumers that validate any signature present, however silently skip validation if the signature is removed. The software is essentially presuming that we’ve already checked that a message coming from an insecure channel is signed, when this isn’t the case.

The impact of this is the ability to simply remove signatures, and tamper with the response as if they weren’t there. SAML raider can test this one pretty easily:

Is the Signature Validated?

Validating XML signatures is extremely complicated, as the standard expects a series of transformation and canonicalization steps to be applied first (e.g. to ignore the amount of white space). The difficulty of this makes it extremely hard to validate signatures without a fully featured XML Signature library behind you. The impacts of this are:

• Developers don’t generally understand the internals of signature validation.
• Intermediate tools, such as web application firewalls, have no idea whether signatures are valid or not.
• Libraries may have configurable options, such as lists of permitted canonicalization methods, which are meaningless to the developer.

The difficulty of implementing this standard, and the somewhat arcane nature of it, leads to the issues we will now look at.

First, testing whether the signature is validated at all is simple - change something in the supposedly signed content and see if it breaks.

Is the Signature From The Right Signer?

Another stumbling block is whether or not the receiver checks the identity of the signer. We haven’t seen this one done wrong, but SAML Raider will make this fairly easy to test.

Copy the certificate to SAML Raider’s certificate store:

Save and self-sign the certificate, so we have a self-signed copy of the same certificate:

Now we can re-sign the original request with our new certificate, either by signing the whole message or the assertion:

You could identify which of those two options is normally used by your recipient, or just try each of them.

Is the Correct Part of the Response Signed?

How XSW Attacks Work

The SAML standard allows signatures to appear in two places only:

• A signature within a <Response> tag, signing the Response tag and its descendants.
• A signature within an <Assertion> tag, signing the Assertion tag and its descendants.

The SAML standard is very specific about where signatures are allowed to be, and what they are allowed to refer to.

However, nobody implements XML signatures in all their gory complexity for use in SAML alone. The standard is generic, and so are the implementations and software libraries built for it. As a result, the separation of responsibilities looks like this:

• The XML Signature library validates according to the XML Signature standard, which allows anything to be signed from anywhere.
• The SAML library expects the XML Signature library to tell it whether or not the response is valid.

Somewhere in the middle of these two components, the rules about what we have to sign are often lost. As a result, we can often have our signature refer to a different part of the document, and still appear valid to the recipient.

By copying the signed parts of the document, and ensuring the signatures point to the copies, we can separate the part of the document that the XML Signature library checks from the part of the document that the SAML library consumes.

Automated XSW

SAML Raider will automate the most common attacks of this form for you:

Try selecting each of those options from the drop-down, clicking “Apply XSW” and sending the request on. If this doesn’t cause an error, try doing it again and changing the username or other user identifier in each place it appears in the SAML XML.

Limitations of SAML Raider

While SAML Raider will test the common cases, there are a few attacks that require a deeper understanding:

• Producing a response that will validate against an XML schema (requires hiding the shadow copy inside an element that may contain xs:any).
• Bypassing validation when both the Response, and Assertions within it are signed and checked.
• Bypassing XML signatures in non-SAML contexts, for example SOAP endpoints using WS-Security extensions.

Manual XSW

If SAML Raider’s out-of-the-box options don’t work, you may want to try a manual approach:

• Decode the Base64-encoded content to access the SAML Response XML.
• Check that the signature’s <Reference> tag contains the ID of a signed element.
• Copy the signed content somewhere else in the document (often the end of the <Response> is OK, if XML Schema validation is in play try finding somewhere to copy it that doesn’t break the schema.)
• Remove the XML signature from the copy, leaving it in the original. This is necessary as the XML encapsulated signature standard removes the signature that is being validated. In the original document, this was the contained signature, so we have to cut it out from the copy.
• Change the ID of the original signed element to something different (e.g. change a letter).
• Change the content of the original assertion.
• Re-encode as Base64, put in to the request and forward on.

If the signature validation points to the copy, it will ignore your changes. With practice, you can complete this process pretty quickly if strict time limits on requests are in play.

SAML Pentest Checklist

• Does the SAML response pass through the web browser?
• Is it signed? If not, try changing the content.
• Is it accepted if we remove the signatures?
• Is it accepted if we re-sign it with a different certificate?
• Do any of the eight transforms baked in to SAML Raider produce a result that is accepted?
• If you change such a response, is the modified response accepted?
• Might one of SAML Raider’s limitations noted above apply? If so, you may neeed.\

please do comment below if you have any question.