What are the DNS 952 subdomain conventions - dns

Ran into an error with my Openshift configuration saying my route must conform to the DNS 952 subdomain conventions.
What are they?

RFC 952 is simply at https://datatracker.ietf.org/doc/html/rfc952 but itself later revised by other RFCs.
The recent DNS Terminology RFC (8499) gives you the definition and links you need, have a look at https://datatracker.ietf.org/doc/html/rfc8499#section-2

According to Microsoft's article about naming conventions
For DNS host names:
DNS names can contain only alphabetical characters (A-Z), numeric characters (0-9), the minus sign (-), and the period (.). Period characters are allowed only when they are used to delimit the components of domain style names.
and the disallowed characters are:
DNS host names can't contain the following characters:
comma (,),
tilde (~),
colon (:),
exclamation point (!),
at sign (#),
number sign (#),
dollar sign ($),
percent (%),
caret (^),
ampersand (&),
apostrophe ('),
period (.),
parentheses (()),
braces ({}),
underscore (_), and
white space (blank)
So if you configure Openshift using a template.yml be sure to not have any extra braces (from parameters), or use any of the other illegal characters.

Related

Must a SDP line start with the attribute character or can it start with Whitespace? RFC is not clear

RFC 4566 is the controlling RFC for SDP syntax.
It states in Section 5 - SDP Specification that:
An SDP session description consists of a number of lines of text of
the form:
<type>=<value>
where <type> MUST be exactly one case-significant character and
<value> is structured text whose format depends on <type>. In
general, <value> is either a number of fields delimited by a single
space character or a free format string, and is case-significant
unless a specific field defines otherwise. Whitespace MUST NOT be
used on either side of the "=" sign.
However, nowhere is it clear whether there can be whitespace before the case-significant character.
Section 9.0 which provides the BNF grammar is also ambiguous on this issue. All SDP entriess I have seen appear to start the attribute lines from the first position but is whitespace allowed at the start of an SDP entry is the question.
The answer provided to a somewhat similar but definitely different question I had asked earlier sheds some light but is not definitive on this particular issue.
Spaces before the case-significant character is not allowed. The BNF/ABNF does not show that you can add spaces before the lines defined in session-description. They even explicit say which letter you have to use like v=....

Regex Search/Replace is... inverted

Up to a few days ago my Sublime text 3 was working just fine. I could search/replace regular strings and use regular expressions patterns as well and when a capture group got a match, all of them were highlighted perfectly.
However, since yesterday, everything I search is matching... reversely. Here:
image:\s*"?(.*?)"?
This should match a fixed string image, followed by a colon, any number of spaces, if any, and anything between optional quotes.
Not a big deal, right? However Sublime is capturing the string image instead of what I've defined to be captured. Even if there are no spaces or quotes, it should at least match what's after the colon, not before it:
I did a fresh install, reinstalling and reconfiguring the very few plugins I use, trying to, maybe, get rid of any sort of caching, without luck.
And this is a major setback for me 'cause I can't do batch replacements all over a project.
There are only two things I did differently than my regular development routine:
Installed String 2 Lower Hyphen Plugin to speed-up the creation of some dashed separated URI slugs BUT when fresh installing I didn't add it back and the problem persisted.
For the first time, I used the expression <open files> to do a batch replacement in a specific set of files I had manually opened since they're in different directories.
Nothing more than that.
I can workaround the issue by changing the .*? to a .* but this is a palliative measure since I always used the non-greedy version without problems
Does anyone know what could be happening?
I'm not sure how your regex used to match any differently, let's think about what the regex is saying:
image: - the literal image:
\s* - any amount of whitespace, including none
"? - an optional quote
(.*?) - lazily capture anything except a newline character into capture group 1
"? an optional quote
So for your example text to match, it matches image: and the space after it, then, there is no quote, the next instruction is lazy so it captures nothing into capture group 1, then there is no quote, so that is the full extent of the match.
If you always want to capture the value in capture group 1, regardless of whether it was a quoted or unquoted string, you could instead consider using an expression like:
\bimage:\s*"?((?(?<=")[^"]*|.*$))"?
\b word boundary, to ignore image: not being the start of a word
image: literal image:
\s* any amount of whitespace, including none (depending on your source document and requirements, it may be better/more defensive to specify a literal space so that newlines won't be matched here)
"? optional quote
( begin capture group 1
(?(?<=") conditional - lookbehind to see if a quote matched
[^"]* if a quote matched, then match all non-quote characters (of course, we could also check for escaped quotes if your file is YAML format or similar, but URLs shouldn't contain quotes, so we're leaving it out as per the original regex.)
| otherwise, if the conditional didn't match, i.e. there was no quote after image:
.*$ match everything until the newline - again, if this is YAML, you may want to consider excluding comments etc.
) end conditional
) end capture group
"? optional quote (this will never match at $ if the conditional fails)

VIM: can't fully understand this substitution

I have taken this line of code from a book to format html code into a string-concatenated form for use in javascript in vim. I can't seem to understand what the numbers '1' and '2 represent and what the question marks are for at the end of the regexes. I'm used to seeing substitutions like %s/foo/bar/g, so the absence of forward slashes confuses me a bit. Summarized, I don't understand the '1' and '2', the question marks after the dollar sign and before the carriage return, and why the forward slashes are not used.
vmap <silent> ;q :s?^\(\s*\)\(.*\)\s*$? \1 + '\2'?<CR>
Forward slashes are typically used as the separator, but the substitute command uses the first character after the 's' as the separator, allowing it to be changed to anything. It seems the author thought that all the slashes might be confusing, so changed it to a '?'. This is how the command would appear with the more traditional forward slashes:
:s/^\(\s*\)\(.*\)\s*$/ \1 + '\2'/<CR>
So the above would mean, search forward, finding lines starting with any amount of whitespace, followed by any number of any characters, and any amount of whitespace, and then substitute it for <space><the first whitespace><space>+<space>'<the other characters>'. I think it was intending to strip any trailing whitespace, but in my testing it doesn't do that, because the .* will match everything to the end of the line.
As it was said in other answers, the / delimiter can be replaced by some other char : when many slashes are used in the command, it may be more clear; see a question about it, https://stackoverflow.com/a/36568901/3271687.
\1, \2, \n... match the nth sub-expression used in the pattern. A sub-expression is defined with \( and \). So in your example:
:s?^\(\s*\)\(.*\)\s*$? \1 + '\2'?
\s* --> note that this part can't be reached, it's useless
, \1 is replaced by the spaces found in \(\s*\), and \2 is replaced by all the chars (the whole rest of the line) found in \(.*\).

Weird whitespace in TXT record

We've added a TXT record for DKIM validation (copy-pasted the DKIM string), but there seems to be a weird character in the record that:
doesn't appear at all in the DNS manager
doesn't appear at all in the DKIM Core validator
do appear as empty quotes in the mail-tester.com validator
do appear as a whitespace within quotes during dig in Linux
This character makes the DKIM invalid, so my questions are: What is it, why isn't it detected and how do I remove it?
DKIM Core:
mail-tester.com:
Dig output:
dkim._domainkey.example.com. 3600 IN TXT "v=DKIM1\; k=rsa\; g=*\; s=email\; h=sha1\; t=s\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKCyTnwDTY7yp1Xd/ApOgq7rzfSB8N2s+cX0sHzpwAt/I60KGGLV/qq/Wx462PX7LiL9O9UngvjoH6VILDJAnS3xGVHkVXIC9lzPcgTREV56AisCfIXa9t6ZELvXDAHJY1YfghPOUlh0KnXzL37W2hwTj4J3tJt1iEeKNgYnEwxQ" "IDAQAB\;"
Quick answer
The DKIM specification (RFC 6376 Sec. 3.6.2.2) dictates that
Strings in a TXT RR MUST be concatenated together before use with no intervening whitespace.
In other words: The whitespace in between the strings does not have any relevance. The strings inside the quotes are simply processed as one.
Technical background
TXT records consist of what's called character strings. Each of these consists of up to 256 bytes, where the first byte ("octet") carries the length of the string (see RFC1035 Sec. 3.3). When displayed, character strings are typically bounded by quotes " on either side (RFC1035 Sec. 5.1). The quotes are not stored and don't count towards the length.
That means that if the value is no more than 255 bytes long (plus quotes), one character string suffices. If it is longer, the TXT record will contain multiple character strings (RFC1035 Sec. 3.3.14).
The interpretation of the multiple character strings depends on the specific scenario, and for DKIM it is specified as described above. So, what you are seeing is a technical artifact, and not an erroneous space.

Is it possible to use double # in an email address?

I know Yahoo and Gmail do not accept it. But I want to know if it's possible for a person to create an email address with double # in address and if they can receive emails with that address?
For example: info#stackoverflow.com#example.com.
I do not want to use this non standard format, but I want to know if a hacker can do it?
According to the wiki, it is allowed.
Space and special characters "(),:;<>#[\] are allowed with restrictions (they are only allowed inside a quoted string, as described in the paragraph below, and in addition, a backslash or double-quote must be preceded by a backslash).
No it is not allowed. See the RFC Section 3.4.1
An addr-spec is a specific Internet identifier that contains a
locally interpreted string followed by the at-sign character ("#",
ASCII value 64) followed by an Internet domain. The locally
interpreted string is either a quoted-string or a dot-atom. If the
string can be represented as a dot-atom (that is, it contains no
characters other than atext characters or "." surrounded by atext
characters), then the dot-atom form SHOULD be used and the quoted-
string form SHOULD NOT be used. Comments and folding white space
SHOULD NOT be used around the "#" in the addr-spec.
As this question's answer says:
The local-part of the e-mail address may use any of these ASCII characters:
Uppercase and lowercase English letters (a-z, A-Z)
Digits 0 to 9
Characters ! # $ % & ' * + - / = ? ^ _ ` { | }
Character . (dot, period, full stop) provided that it is not the first or last
character, and provided also that it does not appear two or more times
consecutively.
so it is usually not allowed :)

Resources