Rob Olmos's questions

When using a mail delivery service, like AWS SES or SendGrid, is there any benefit to including their SPF records for the domain in the RFC5322.From (header-from) header?

With how they operate by default, they use their own RFC5321.MailFrom (envelope-from), which is what SPF is supposed to check against according to the standards.

However, I'm wondering if there's still a benefit, like broken mail servers or mail servers that may check the RFC5322.From against SPF anyways for a spam check. Or just don't bother because it's never checked. Curious if anyone has any field experience about that.

For example, AWS SES uses a subdomain of amazonses.com in the RFC5321.MailFrom. This question assumes that has not been changed with a custom "MAIL FROM" setting.

I'm aware of the ability to logout inactive SSH sessions after a period of time but leaving something like "top" open works around that.

This question is more in the context of forceful disconnects and likely with cert-based keys.

For example, take a cert-based key that's only valid for 24 hours. I'm wondering if it's possible to have SSH automatically disconnect the open session when the cert end date is reached?

For the situations I'm thinking of forceful disconnects won't be an issue.

If there's a way to forcefully disconnect all sessions after a period of time, like 24 hours. That would be also be useful.

One particular use case applying to this question is that we have some resources in AWS EC2 and Google Cloud Compute with a cron job to do a nightly disk snapshot.

Is there a way to use Stackdriver to monitor the snapshot is invoked and send an alert if it doesn't?

Basically this would operate like a heartbeat, but it's only sent every 24 hours.

I think one method is to use something like "metric absence" but I don't think CloudWatch nor Stackdriver can do something like a window greater than 24 hours.

Other use cases would be any other cron job we want to monitor that are application specific, like import jobs or batch jobs.

I know there's other services that can handle this like Cronitor or OpsGenie's Heartbeats but I'm looking for a method within the same environment without additional costs.

What is the best method to send an alert via SNS for an AWS EBS volume that has been marked as "impaired"?

Within Console > EC2, under Instances > Status Check tab, you can set a CloudWatch alert.

However, there is no ability under the Volume > Status Check tab.

I discovered under Health Events there's a couple but they're only for "volume lost" and "degraded performance". Not exactly for an impaired volume.

The volume doesn't receive a lot of activity so monitoring any performance metrics likely isn't a good solution.

Basically I'm monitoring the php-fpm error.log file with a custom config:

<source>
  type tail
  format none
  path /var/log/php-fpm/error.log
  pos_file /var/lib/google-fluentd/pos/php-fpm-error.pos
  read_from_head true
  tag php-fpm-error
</source>

With a custom log metric like this:

resource.type="gce_instance"
resource.labels.instance_id="123456"
logName="projects/example/logs/php-fpm-error"
"exited with code 127"

In the Metrics Explorer I can see the error event on the metric pretty clearly if I select "Count" as the Aggregation. However, in the Alert policy I don't see a way to specify an Aggregation.

Is the best method to just put the alert policy as "above count of 0" with "for most recent value"? It seems odd because the metric value is something really small like 0.02.

Thanks

According to RFC 2181 https://www.rfc-editor.org/rfc/rfc2181#section-10.3

10.3. MX and NS records

The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

Why is this restriction in place?

I assume due to resolving overhead but is it really that costly nowadays?

From experience with an incorrect MX record that used a CNAME exchange no problems were experienced during the course of a couple years except for a couple mail relays that couldn't find the MX exchange.

I'm installing CentOS 6.1 on a server and exploring the encryption settings in combination with software RAID.

• Should I encrypt the drive partition, the software RAID device, or both?
• Should I encrypt swap?

Wondering the pros/cons of each approach in case I mentally missed something.

Thanks

I recently received a reply to my concerns about some DNS servers being slower than others despite all servers being anycast:

In practice, most resolvers won't be impacted by the slower paths to some of the name servers in the set. Most resolvers employ various techniques to provide fast lookups, such as preferring name servers that were previously seen to be faster, sending simultaneous queries to multiple name servers, or pre-fetching queries before the TTL has expired.

I was not aware that resolvers used these techniques and I was unsuccessful at searching for more info about this.

1. Are there any names for these techniques?
2. Which resolvers employ which of these techniques?

Is it poor configuration to return the root name servers in the additional section for a CNAME lookup that points to another domain? Particularly the one I'm seeing this with is a CNAME hosted by Network Solutions with the CNAME pointing to a different domain & TLD.

I ask if this is poor configuration because all these additional records result in exceeding the size of the UDP packet forcing the query to be re-done with TCP.

dig www.unitedstatesartists.org +trace

A name server response:

example.org. 86400  IN      NS      ns15.worldnic.com.
example.org. 86400  IN      NS      ns16.worldnic.com.
;; Received 95 bytes from 199.249.120.1#53(b2.org.afilias-nst.org) in 79 ms

;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
www.example.org. 7200 IN    CNAME   load-01-123.us-west-1.elb.amazonaws.com.
.  518400  IN      NS      a.root-servers.net.
.  518400  IN      NS      b.root-servers.net.
.  518400  IN      NS      c.root-servers.net.
.  518400  IN      NS      d.root-servers.net.
.  518400  IN      NS      e.root-servers.net.
.  518400  IN      NS      f.root-servers.net.
.  518400  IN      NS      g.root-servers.net.
.  518400  IN      NS      h.root-servers.net.
.  518400  IN      NS      i.root-servers.net.
.  518400  IN      NS      j.root-servers.net.
.  518400  IN      NS      k.root-servers.net.
.  518400  IN      NS      l.root-servers.net.
.  518400  IN      NS      m.root-servers.net.
;; Received 526 bytes from 205.178.190.8#53(ns15.worldnic.com) in 173 ms

Returning the additional records or not is random. Sometimes when they don't return the additional there's still a truncated response and dig retries in TCP.

example.org. 86400  IN      NS      ns15.worldnic.com.
example.org. 86400  IN      NS      ns16.worldnic.com.
;; Received 95 bytes from 199.19.56.1#53(a0.org.afilias-nst.info) in 82 ms

;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
www.example.org. 7200 IN    CNAME   load-01-123.us-west-1.elb.amazonaws.com.
;; Received 107 bytes from 205.178.190.8#53(ns15.worldnic.com) in 164 ms

Update 2010-12-08

With more testing found:

• Network Solutions responds with a SERVFAIL (server failure) with a recursive query (dig's default if not +trace) yet still gives the correct answer.
• Setting dig's +norecurse works fine but not always. Sometimes a SERVFAIL is returned - Not good. Details of possibly why follows below
• Network Solutions' inclusion of the root servers in the authoritative and additional section causes the UDP truncation and requires TCP to complete.

Overview of the following capture:

• Non-recursive request record from ns15
• ns15 answer includes root servers in auth and additional and marks reply as truncated
• Non-recursive request is retried in TCP due to truncated UDP
• Similar answer from ns15 using TCP except "recursion desired" is incorrectly set and "server failure" code is also set

We've already created a ticket with them but we'll see if it goes anywhere. Follows is the DNS packets from tshark details earlier:

First question (via UDP):

Domain Name System (query)
    Transaction ID: 0x27ef
    Flags: 0x0000 (Standard query)
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable

First answer (via UDP):

Domain Name System (response)
    [Request In: 1]
    [Time: 0.078623000 seconds]
    Transaction ID: 0x27ef
    Flags: 0x8600 (Standard query response, No error)
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .1.. .... .... = Authoritative: Server is an authority for domain
        .... ..1. .... .... = Truncated: Message is truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... 0... .... = Recursion available: Server can't do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... .... 0000 = Reply code: No error (0)

Second question (via TCP):

Domain Name System (query)
    Length: 56
    Transaction ID: 0xbc37
    Flags: 0x0000 (Standard query)
        0... .... .... .... = Response: Message is a query
        .000 0... .... .... = Opcode: Standard query (0)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ...0 .... = Non-authenticated data OK: Non-authenticated data is unacceptable

Second answer (via TCP, notice "recursion desire"):

Domain Name System (response)
    [Request In: 6]
    [Time: 0.147357000 seconds]
    Length: 107
    Transaction ID: 0xbc37
    Flags: 0x8102 (Standard query response, Server failure)
        1... .... .... .... = Response: Message is a response
        .000 0... .... .... = Opcode: Standard query (0)
        .... .0.. .... .... = Authoritative: Server is not an authority for domain
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...1 .... .... = Recursion desired: Do query recursively
        .... .... 0... .... = Recursion available: Server can't do recursive queries
        .... .... .0.. .... = Z: reserved (0)
        .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
        .... .... .... 0010 = Reply code: Server failure (2)

I have a 2TB USB drive plugged into CentOS 5.5 that will be formatted with ext3 and will only be used for file-level backups.

I've always partitioned my drives but a while ago when I had setup Amazon EBS the docs said to just format the whole device (eg. mkfs /dev/sdf instead of /dev/sdf1) and ext3 would warn you but allow you to do so, which it did.

As I understand it, partitioning in this case will only be necessary if I want to boot from the USB drive which will not be happening and I really want to save those 512 bytes.

Skip or keep the single partition? Why?

Thanks

Why did HTTPS win? Does anyone know of any specific reasons why Netscape and Microsoft both choose HTTPS instead of S-HTTP (RFC 2660)?

It appears to me that S-HTTP is more flexible and does not require a separate IP or port to serve the correct certificate because S-HTTP is able to utilize the Host header. Was IP space a concern at that time?

I can see the argument that HTTPS encrypted more of the connection data than S-HTTP, but I don't see much of the point if you can just as easily tell which website the user accessed because there's only one site per IP (most of the time) and the certificate usually says what domain anyways.

My Answer: SSL created in 1993/1994 by Netscape and HTTPS was naturally added on to it around the same time in 1994. The original goal of HTTPS being to retrofit existing protocols into security without any changes. S-HTTP didn't come along until 1999 and required HTTP 1.1 so by then HTTPS was so entrenched there was little benefit to implement S-HTTP. Thanks everyone.