I want to get the aliases that is returned by nslookup as below:
F:\>nslookup maans20210630125234.sandbox.operations.test.dynamics.com
Server: UnKnown
Address: 2001:4898::1050:1050
Non-authoritative answer:
Name: apimgmths6q7kyczcrkpvds6u99ofw4apdrqgxc8s7qavl14wy.cloudapp.net
Address: 52.188.3.251
Aliases: maans20210630125234.sandbox.operations.test.dynamics.com
d365-ops-dev-gwy-eastus-eus2-2.azure-api.net
apimgmttm0hgnv1tmdyrtilrp0hcvphjwrq4gtyzzfdqehnzfn.trafficmanager.net
d365-ops-dev-gwy-eastus-eus2-2-eastus-01.regional.azure-api.net
nslookup
I want equivalent of above in c sharp. I already tried Dns.GetHostEntry. It does not return aliases as mentioned in official document. How do I get the aliases in C# / .NET?
Dns.GetHostEntry(hostNameOrAddress)
"Aliases" are DNS CNAME records. So you need to find out how to query for DNS CNAME records from your DNS library. You probably need to use a low level DNS library that lets you control all low level details of a DNS query, because high level calls like GetHostEntry are designed to just give you the final answer and hiding the intermediate steps (the CNAME chain resolution).
On the command line the equivalent are:
$ dig maans20210630125234.sandbox.operations.test.dynamics.com +short
d365-ops-dev-gwy-eastus-eus2-2.azure-api.net.
apimgmttm0hgnv1tmdyrtilrp0hcvphjwrq4gtyzzfdqehnzfn.trafficmanager.net.
d365-ops-dev-gwy-eastus-eus2-2-eastus-01.regional.azure-api.net.
apimgmths6q7kyczcrkpvds6u99ofw4apdrqgxc8s7qavl14wy.cloudapp.net.
52.188.3.251
This follows all the intermediate CNAME and gives you the final IP address (as dig does A record type queries by default)
But if you specify record type CNAME you get only the first answer (and hence you will have to do yourself a loop to find out all intermediate CNAME until you get an error or the final answer):
$ dig maans20210630125234.sandbox.operations.test.dynamics.com CNAME +short
d365-ops-dev-gwy-eastus-eus2-2.azure-api.net.
Related
From the output I can understand there was no errors, yet there aren't any answers section to the query. Just to be sure the right question was even asked:
"Dig +norecurse #s.nic.dk MX www.dtu.dk"
parsing this to:
"without recursion, query dtu mail exchange servers through the nameserver s.nic.dk"
Is the query not supposed to return nameservers of dtu MX?
No, it isn't supposed to, because you are asking the authoritative name server of the TLD (s.nic.dk) for the answer. It does not have this answer, but gives you the details of the name servers that do: that is why you receive the authority section (and additional section).
However, even if you do query the authoritative name servers (for example: #dns1.dtu.dk) there is no MX record for the domain name www.dtu.dk, but rather for dtu.dk. Which means your query should be: dig #dns1.dtu.dk MX dtu.dk.
For note, the addition of +norecurse shouldn't make a difference when you're querying an authoritative name server directly.
I am trying to host a website, I changed to Name servers and all, however I am receiving this error
The webserver reported that an error occurred while trying to access the website. Please click here to return to the previous page.
Can some body help me on this?
Thank you
First ensure that the domain is resolving to the IP's you configured, for this you could use tools like dig / drill, or via the web you could use https://intodns.com/
To check the nameservers via command line:
$ dig example.com ns +short
To check for the 'A' records:
$ dig example.com
If you just change the nameservers it may take a while for them to be replicated, you can use the +trace options:
$ dig example.com ns +trace
When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow
referrals from the root servers, showing the answer from each server that was used to resolve the lookup.
If that returns the expected results, check your web server configuration.
I was looking to do something similar to
https://en.wikipedia.org/wiki/Reverse_DNS_lookup#Records_other_than_PTR_records
and place a SRV record in the reverse DNS tree.
In particular I was hoping to be able to add a srv record for a chunk
of the address space by using a wildcard. Something like the
following....
_service._tls.*.26.19.in-addr.arpa. IN SRV 1 1 443 service.example.com
However it turns out that my understanding of wildcard domains was inadequate according to:
SRV RRSet at a Wildcard Domain Name
https://www.rfc-editor.org/rfc/rfc4592#section-4.5
The above is confusing but basically explains (I think) that my
single wildcard SRV record above won't work. I think I need a SRV
record for each and every ip address I wanted to cover with the
wildcard domain.
In IPv4 I know I can use things like Bind's $GENERATE directive to automate the creation of all the records. But how would something like this be handled in IPv6 particularly if I also wanted to use DNSSEC to have all the records signed?
Any insights would be greatly appreciated.
I have ip ranges.
I would like to find ns addresses that are pointing to corresponding ip adress
I'm looking for a command to do over nslookup or dig
Expected result
http://reports.internic.net/cgi/whois?whois_nic=70.84.87.146&type=nameserver
http://dnsquery.org/nswhois/85.17.137.148
How can I do that over nslookup or dig?
Or are there any solution to have such results
You cannot have that information from DNS tools like nslookup or dig.
This is because there is no such DNS query to list this information. The way that web page works is by asking the WHOIS database from a certain WHOIS server (in this case, it is Internic's WHOIS database). A certain WHOIS database usually only contains entries for some domains (like aaa.com, bbb.net), but no entries for subdomains (like xxx.aaa.com), or for other TLDs not managed by that domain registrar (like aaa.gov, bbb.us, ccc.co.uk, ddd.fr, eee.de).
There is a CLI utility (called 'whois', available in most Linux distributions) to access the WHOIS database. You will have to specify the name or address of the WHOIS server (whois.internic.net in this case), and the query in a format understood by that WHOIS server. For example:
whois -h whois.internic.net 70.84.87.146
I setup a couple of nameservers and updated my domain to use them, and as far as I can tell everything went fine and the nameservers have been updated, or so says every whois and dnstools type site ive used, (intodns, who.is etc are all saying the same thing: the new nameserrvers are in effect, and the site points to the new ip just fine). Problem is that The site is not showing up, and dig tells me that the old ip/nameservers are still effective.
In my DNS Records I have:
domain. A IN NS ns1.newnameserver
domain. A IN NS ns2.newnameserver
ns1 IN A newipaddress
ns2 IN A newipaddress
domain. IN A newipaddress
I'm very short on time and haven't found anything on the interweb, so any help would be much appreciated
The old IP address is probably being cached by the server you queried. First of all, check that BOTH your new authoritative nameservers are publishing the correct address by querying them directly with dig:
dig #ns1.newnameserver domain. a
dig #ns2.newnameserver domain. a
Assuming those queries give correct answers, dig some other servers that aren't:
dig domain. a # Use the system's default resolvers
dig #8.8.8.8 domain. a # Use Google's public resolver
dig #some.other.ip.address domain. a
If it gives the old answer, look at the TTL. That's the numeric field listed in the answer just after the name and before "IN". That's how many seconds you have to wait until the server you queried discards its cached data and will query the authoritative servers again.
Ask those same nameservers where they think "domain." is delegated:
dig domain. ns # Use the system's default resolvers
dig #8.8.8.8 domain. ns # Use Google's public resolver
dig #some.other.ip.address domain. ns
You want to see 2 NS reocrds for "domain.", one pointing to "ns1.newnamserver" and the other one to "ns2.newnameserver", but the resolvers likewise cache that information so they might still have the old nameservers. If so, look at the TTL on those NS records too. If the TTL on those records is longer than the TTL on the A records, those resolvers may still go to the old nameservers to get "domain."'s A records even when their currently cached copy expires... so you may need to wait for that TTL to expire first, and then for the TTL on the actual A record to expire again!
Another thing you can do is query some of the authoritative nameservers for the PARENT domain of your domain to see if they are indeed delegating it to "ns1.newnameserver" and "ns2.newnameserver". This will verify that the delegation in DNS matches what's in WHOIS.
dig com. ns # If your domain's parent domain is "com."
dig #<one-of-the-servers-that-resulted-from-that-query> domain. ns
Again, you want to see 2 NS reocrds for "domain.", one pointing to "ns1.newnamserver" and the other one to "ns2.newnameserver".
If the old nameservers are still running, either:
make sure they aren't, or
make sure they've also got the new zone data
Some people will still be talking to the old nameservers, and until they either stop answering or give the right answer, they won't learn the new nameservers from the parent zone.