If I am right the nameServerSet could give me the option to specify the DNS servers to handle request for a domain, this could be useful if I want to use my own domains like for doing white label.
From the docs: nameServerSet
nameServerSet Optionally specifies the NameServerSet for this
ManagedZone. A NameServerSet is a set of DNS name servers that all
host the same ManagedZones. Most users will leave this field unset.
But what are the posible "string" values to use?
Related
We use mTLS authentication between clients and Kafka cluster and some ACLs configured on topics.
A client has in his subject name the email address, like:
Owner: EMAILADDRESS=user#my-domain.com, CN=my-service, OU=my-ou, O=my-org, L=my-loc, ST=my-state, C=my-country
But when the client calls kafka cluster we see the email address converted with his [OID code].
[2022-07-13 10:37:32,549] INFO Principal = User:1.2.840.113549.1.9.1=#3uR2XK21ru2nwVymHN9u4B7wQCs4wrhcPavdGktA,CN=my-service,OU=my-ou,O=my-org,L=my-loc,ST=my-state,C=my-country is Denied Operation = Write from host = 10.10.10.2 on resource = Topic:LITERAL:my-topic for request = Produce with resourceRefCount = 1 (kafka.authorizer.logger)
Could someone explain me why this happen and how to get the email address literal instead?
[OID code] https://oidref.com/1.2.840.113549.1.9.1
You cannot get the email address as a literal because Kafka parses the principal DN (Distinguished Name) as described in rfc2253, which doesn't support the EMAILADDRESS attribute. Unsupported attributes are encoded as in your example.
The next step depends on what you're trying to achieve.
If you are trying to use the email address in the ACL rule, then you can do one of:
if you can, issue certificates where the email address is in one of the supported attributes, such as within the CN.
use a script to encode it and get the correct value, which you can use as-is in the ACL rule.
If you don't mean to use the email address, and instead you mean to use other attributes which appear as literals (like the CN), you can either:
If you have access, the best option is to issue certificates without an email in the subject name and create ACL rules accordingly.
Another option might be to use Kafka ssl principal mapping rules to strip the email address and
leave the rest for use in ACL rules. This rule should do the work:
RULE:^1.2.840.113549.1.9.1=.,(CN=.)/$1
Furthermore, EMAILADDRESS oid is deprecated as mentioned here: https://oidref.com/1.2.840.113549.1.9.1 altNames should be used instead. You can see an example here: On certificates, what type should E-mail addresses be when in subjectAltName.
I need to know about child nameserver, What is it and for what purpose can we use that ?
I have seen an option in whois.com about child name server which has to be pointed out to an ip address, I have tried to use as an subdomain, but I can use subdomain by another way, so basically what is use of that actually ?
Quoting from a source I found using Google:
"Child Name Servers are private labelled name servers which are registered with domain registry under your own domain name.
eg. ns1.domainname.com, ns2.domainname.com
Child Name Servers needs to be registered with registry and also it's A record needs to be pointed to IP address of DNS Server before they can be used as name servers with other domain names. Child Name Servers can be only registered by owner of the primary domain name."
You could use them for a number of reasons; e.g.
If the parent nameserver is run by a DNS provider, the child nameserver could allow you to host the names in the subdomain yourself ... and update them without relying on the DNS provider's (possibly clunky) APIs.
Within a large organization it could allow the management of different subdomains to be done by different groups.
You might do it if you wanted a subdomain to contain dynamic names.
I have seen an option in whois.com ...
I think you might be confused about the purpose of the WHOIS service. It is purely for documenting which people (notionally) control which domains. To implement a child domainserver, you just need an A record in the parent domainserver that points to the child.
In a network capture between a Windows client and an Active Directory server, I see that the field cname-string contains user#domain.com (to be precise, it is the field as-req -> req-body -> cname -> cname-string -> CNameString).
According to RFC 4130 in Section 5.2.2. Realm and PrincipalName:
name-string:
This field encodes a sequence of components that form a name, each
component encoded as a KerberosString. Taken together, a
PrincipalName and a Realm form a principal identifier. Most
PrincipalNames will have only a few components (typically one or
two).
Also in Section 5.3. Tickets:
cname
This field contains the name part of the client's principal
identifier.
To me, that means cname should only contain the username without the domain. The domain is obtained via the realm and together they form the principal identifier (basically paraphrasing the RFC here).
Am I wrong? Have you come across setups where the domain was part of the cname? How did the target service handle that? I see that the realm is added again to the cname, resulting user#domain.com#domain.com, which obviously prevents a correct matching.
There is at least one case when this can happen: enterprise principals. You should see the NT-ENTERPRISE somehwere as well as CANONICALIZE bit set. The AD contains an upnSuffix for the supplied enterprise principal. See also RFC 6806 for this.
Just want to see if I understand this correctly.
CNAME record specifies an alias, in the following form:
alias CNAME canonical-domain
Which means if something is trying to look up alias, it will find the CNAME record and start searching for canonical-domain instead.
A record directly maps a host to an IP
host A IP-addr
So if I have 2 domains eventually pointing to the same IP addr, one is a canonical domain and another is an alias domain, I would use an A record for the canonical domain->IP mapping, and a CNAME record for the alias->canonical mapping.
Why can't I just use 2 A records, one being canonical->IP mapping and the other being alias->IP mapping? Is it so that you only have to update the IP once if you ever need to change it? (Analogy would be CNAME is a softlink and A record is a file in a filesystem)
Why can't I just use 2 A records, one being canonical->IP mapping and
the other being alias->IP mapping?
You can - that's perfectly normal.
Is it so that you only have to update the IP once if you ever need to
change it?
Yes, that's right.
A common configuration is to have the canonical name being the server's real hostname, and then CNAME records for the sites hosted on that server pointing at that.
Note that you can't have a CNAME for a bare domain name (e.g. stackoverflow.com) . A CNAME record can't coexist with the NS and SOA records that are expected to exist at the apex of a zone.
(Analogy would be CNAME is a softlink and A record is a file in a
filesystem)
That's not an analogy I'd use.
I want to get all countries ip addresses range from IANA's whois server, Not from maxmind or ip2location site. IANA is authentic site hence I would like to get all ipaddress ranges for countries from that site. Is it possible to query the WHOIS server such a way??
Its not possible to directly get the ip addresses allotted to any country like that.
IP numbers are allocated to regional internet registries.
There are 5 of them , ARIN , APNIC , AFRINIC , LACNIC , RIPE
And again , these RIR allot ip ranges to ISPs of a country.
By doing a whois query for an ip you can find out which RIR is the IP allocated to. The whois response will also contain the country and ISP of the ip address.
Basically you need to whois-query all ip ranges and aggregate the data and form a database. Such a database can be then used to provide all ip addresses belonging to a certain country.
IANA does not have this information so, no, there is no way to get it from them.
IANA only allocates big IP prefixes to RIR (Regional Internet Registries). For instance 31.0.0.0/8 has just been allocated to the RIPE-NCC (by the way, one less IPv4 prefix, time to enable IPv6 if it is not already done), which covers all Europe and a good part of the Middle East. So, these adresses may go to Ireland, Jordan or Greece and you cannot tell it from IANA allocations. Even the RIR whois (whois.ripe.net for the RIPE-NCC) won't tell you with enough details because a prefix may be assigned to a multinational IAP (Internet Access Provider).