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.
Related
I wonder how services performing reverse NS lookup work.
So basically let's say we have a server with an IP address.
That server has a ns record, to which some other domains point.
So for example here, https://viewdns.info/reversens/
When we specify ns1.example.com we see all domains pointing there.
How one would approach it programmatically?
How one would approach it programmatically?
You can't, because there is no way to do this.
What people do is the following more or less:
start with a list of domains (do searches, try dictionary words, use social media, download gTLD zone files, etc.)
resolve them, you get the nameservers
record in some database the domain <-> nameservers mapping
Now, with all the data you can trivially do reverse queries. This is how basically everyone does it (hence it is never real time, you first have to collect all information).
I'm trying to learn as much as possible about DNS, and so far I've read most of:
http://www.zytrax.com/books/dns/ch8/soa.html
and all of:
http://computer.howstuffworks.com/dns.htm
I understand that SOA and NS records contain info about the authoritative name server for a domain, but as these are just DNS records, how does the rest of the world even know where to get them?
I assume it starts at the top-level-domain (.COM .NET .ORG, etc) servers. So they must contain a SOA record for my domain? If so, how does that get there? I imagine only registrars like GoDaddy and Network Solutions are able to update those? If they contain a SOA record, why does my DNS server (that I host), need one also? I think there must be something, maybe in the domain registration records (outside of DNS?), that I'm missing.
I think I've got a pretty good understanding of most parts of the DNS system, after reading lots of articles.. but I haven't found any that answer this part, in a way that I understand it.
For example, GoDaddy and Network Solutions both let me change different options (in their web UI) to "host my own DNS server". If these options remove them from the process, so DNS servers never need to query them again, and instead query my server directly (this is what I want, no dependency on GoDaddy/NS)... when I make these changes, what (at the DNS level or otherwise) is GoDaddy/NS doing? Are they asking the top-level-domain servers to update some DNS records for my domain?
Short answer is yes. Godaddy will take care of updating your the TLDs for you. Your other assumptions are also correct except for one small detail...
DNS starts with the "root" domain and then goes to the TLDs (top level domains).
www.somedomain.com. actually brakes down like this:
. The root name servers
com - The TLD name servers
somedomain - Your NS servers
www - The host portion of the dns name.
Setting up your own DNS server is a great way to understand DNS better. Good luck!
So they must contain a SOA record for my domain?
Multiple answers possible, depending on the scenario:
delegated 2nd level:
No; the start of authority of your domain is usually at your level, so the SOA for you.cf is (only) in your nameservers. Same as the SOA for .cf is only in the nameservers of .cf, and not in the root-servers. In case your nameservers are within the same domain (i.e. ns1.you.cf in case of you.cf) then glue records are needed. This means that registry that's operating the TLD's nameservers will insert a A and/or AAAA record with the IP of ns1.you.cf in the TLD zone. Normally you (the registrant) set this in the interface of your registrar.
undelegated 3th level:
No; if your domain was sub.you.cf - but sub.you.cf wasn't delegated (no NS records exist for sub.you.cf) then the SOA is probably at you.cf. Unless...
undelegated 2nd level:
Yes; if you register a domain without having it delegated (no NS records exist for you.cf) then the SOA is at the .cf nameservers. Although most registries run delegation-only zones, some don't. Example: when you use url-fwd'ing in .cf. The SOA then is at the cf level.
I'm learning DNS. Please give me your advice.
My book tells me that Bind checks names that considered hostnames.
It says Hostnames are in the name fields of A and MX records. Hostnames are also in the data fields of SOA and NS records - yes, I agree.
However, it says that CNAMEs do not have to conform to the host-naming rules because they can point to names that are not hostnames.
I think CNAME has hostname in its data field anyway, does it not ?
Does this mean CNAMEs could be recursive so that CNAME do not have to conform host-naming rules in BIND ?
It depends on the DNS server that you are adding your CNAMEs to.
http://en.wikipedia.org/wiki/CNAME_record
For example, I have seen a few poorly written DNS servers allow for a CNAME which points back to itself. Other DNS servers like bind require strict naming and formatting for the CNAME entry or it will reject the config. Having said that, there is also and option in bind to disable strict name checking so that it allows more free-form entries.
When using CNAMEs it is best to use RFC standard entries because you rarely know all of the clients that will be consuming the CNAME. If you start using something questionable then you will run into all sorts of weird one-offs that do not work.
Let's say I have a server (DNS and other), myserver.com. Now I register a domain, mydomain.com, and set it's NS at the registrar to myserver.com - it is therefore the authoritative server, if there is any such thing.
In the authoritative records for mydomain.com, can I set the NS to ns.mydomain.com?
I have two domains set up like that, one works, the other one seems reluctant to propagate. So I'm wondering if there is something wrong with that - I mean how can you resolve the name of the NS when you need to resolve the name of the NS to resolve the name of the NS...
And, If yes, how come parallels plesk sets them automatically in this way?
Ps: there is an A record for ns.mydomain.com on that same server, pointing to the proper IP
There's a solution for this problem - it's called "glue records", i.e. A records hosted in the parent zone that contain the IP addresses of the name servers.
See http://en.wikipedia.org/wiki/Domain_Name_System#Circular_dependencies_and_glue_records
Why would you want to set the NS record for the "mydomain.com":
to "myserver.com" in the delegation record that goes into the parent zone (com.), but
to "ns.mydomain.com" at the zone apex (inside the mydomain.com. zone)
? This creates an inconsistency (two different DNS servers answer the same question with two different answers) without any apparent benefit. You should try to help the DNS system as a whole issue consistent answers.
Unless you have a good reason to make the DNS inconsistent, you should decide what the correct, canonical name for your nameserver is, and publish that name in the NS record both in the delegation and at the zone apex for "mydomain.com".
That being said, it will still work:
If a recursive resolver which does not yet know anything about "mydomain.com" asks about it, it will be told by the gTLD servers to go look at "myserver.com". The gTLD will also issue A and AAAA glue records to help find "myserver.com", but even if they don't, you have A and AAAA records for "myserver.com" in the "myserver.com" zone file (right?).
If a recursive resolver which wants to refresh its cache for the "mydomain.com" NS record, it may query the authoritative server it already knows about. This server will answer that the nameserver is "ns.mydomain.com", with a glue record. This is different from what it had in its cache before, but ultimately it will map to a server with the same IP address.
As for "parallels plesk", I know nothing about that.
I want to query Spamhaus's SBL using a domain name. I know this is possible to do because this form (Find SBL Listings by ISP Domain Name) does it and SpamAssassin does it, but I can only seem to get it to work with IP addresses. I took a quick look at the SpamAssassin code, but it has been so generalized that I could probably spend a couple hours tracking down the code that actually does something. Right now I can successfully query SBL for IP addresses like this:
#returns 127.0.0.2, so 208.73.210.0 is on the blacklist
dig +short 0.210.73.208.sbl.spamhaus.org
#returns nothing, so 72.14.225.72 isn't on the blacklist
dig +short 72.225.14.72.sbl.spamhaus.org
Querying with domain names seems to have something to do with DNS TXT records, but I don't know the right hostname to lookup. When I try something like
dig oversee.net.sbl.spamhaus.org TXT
I don't get any useful information back, but if you search with the form you find that oversee.net is associated with 208.73.210.0 which was reported as spamming on 30-Jul-2009 21:17 GMT.
Domains are in the "Domain Block List", not the SBL. Use dbl.spamhaus.org as the domain suffix.
The particular search you linked to is based on the ISP's domain name, and I don't believe it uses the same DNSBL interface.