How does Reverse DNS work behind the scene - a layman explanation

Ever wonder what actually happen behind the scene when you do a reverse DNS query?

It is quick and it return a value.

 $ time dig -x 8.8.8.8 +short  
 dns.google.  
 real     0m0.019s  
 user     0m0.005s  
 sys     0m0.005s

In this article, I will explain to you want happen behind the scene.

when the query pass to your resolver, what your resolver does, when you ask it for the ptr (which is 8.8.8.8.in-addr.arpa )

 $ dig ptr 8.8.8.8.in-addr.arpa @a.root-servers.net  

which will tell them: "I don't know about in-addr.arpa - you need to ask the in-addr.arpa server" which correspond to

 ;; AUTHORITY SECTION:  
 in-addr.arpa.          172800     IN     NS     a.in-addr-servers.arpa.  
 in-addr.arpa.          172800     IN     NS     b.in-addr-servers.arpa.  
 in-addr.arpa.          172800     IN     NS     c.in-addr-servers.arpa.  
 in-addr.arpa.          172800     IN     NS     d.in-addr-servers.arpa.  
 in-addr.arpa.          172800     IN     NS     e.in-addr-servers.arpa.  
 in-addr.arpa.          172800     IN     NS     f.in-addr-servers.arpa.  

then the resolver asks one or more of them:

dig ns 8.8.8.8.in-addr.arpa @a.in-addr-servers.arpa

again, it will get delegated to the next servers, which handle "8.in-addr.arpa"

8.in-addr.arpa.		86400	IN	NS	arin.authdns.ripe.net.
8.in-addr.arpa.		86400	IN	NS	z.arin.net.
8.in-addr.arpa.		86400	IN	NS	y.arin.net.
8.in-addr.arpa.		86400	IN	NS	r.arin.net.
8.in-addr.arpa.		86400	IN	NS	x.arin.net.
8.in-addr.arpa.		86400	IN	NS	u.arin.net.

the game continues:

dig ns 8.8.8.8.in-addr.arpa @z.arin.net

"you gotta ask level 3, they know about 8.8.in-addr.arpa"

8.8.in-addr.arpa.	86400	IN	NS	ns1.level3.net.
8.8.in-addr.arpa.	86400	IN	NS	ns2.level3.net.

and the final delegation from level 3 is to the google nameservers:

dig ns 8.8.8.8.in-addr.arpa @ns1.level3.net

[...]

;; AUTHORITY SECTION:
8.8.8.in-addr.arpa.	3600	IN	NS	ns4.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns2.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns3.google.com.
8.8.8.in-addr.arpa.	3600	IN	NS	ns1.google.com.

and only from them will you get the final anser for 8.8.8.8:

 dig PTR 8.8.8.8.in-addr.arpa @ns1.google.com  
 ; <<>> DiG 9.10.6 <<>> PTR 8.8.8.8.in-addr.arpa @ns1.google.com  
 ;; global options: +cmd  
 ;; Got answer:  
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20871  
 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1  
 ;; WARNING: recursion requested but not available  
 ;; OPT PSEUDOSECTION:  
 ; EDNS: version: 0, flags:; udp: 512  
 ;; QUESTION SECTION:  
 ;8.8.8.8.in-addr.arpa.          IN     PTR  
 ;; ANSWER SECTION:  
 8.8.8.8.in-addr.arpa.     86400     IN     PTR     dns.google.  
 ;; Query time: 132 msec  
 ;; SERVER: 2001:4860:4802:32::a#53(2001:4860:4802:32::a)  
 ;; WHEN: Thu Nov 26 10:53:58 CET 2020  
 ;; MSG SIZE rcvd: 73  

That's it!

Implementing DNSSEC and DANE for email - Step by step

Note, this article is written and contributed by a good friend gryphius, so all credit goes to him. I'm just copy and paste his awesome work here. :-)

After various breaches at the certificate authorities it has become clear that we need a way to authenticate a server certificate without the need to trust a third party. “DNS-based Authentication of Named Entities“ (DANE) makes this possible by publishing the certificate in the DNS. Find more information about DANE here.

In this tutorial we show an example implementation of DANE for email delivery.

What you need

• a DNSSEC capable nameserver (in this example: powerdns)
• a DNSSEC capable registrar  (in this example: gandi.net)
• a mail server with TLS Support (in this example: postfix )
• to test the secured email delivery: a second mailserver with DANE support ( postfix >=2.11, DNSSEC capable resolver )

We start off with a postfix server already configured to accept mail for our domain, but no TLS support so far. Let’s add this now by generating a self-signed certificate:
in this state, a sending server can encrypt the transmission, but it can not verify the self-signed server certificate, so it  will treat the TLS connection as anonymous:

postfix/smtp[13330]: Anonymous TLS connection established to mail.example.com[...]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)

In order to enable DANE support, our domain’s DNS zone must be secured with DNSSEC. Our example domain is hosted on a powerdns authoritative server securing a zone on a current powerdns is pretty easy:

The key from the last command must be copied to the registrar. At gandi.net the form to add a DNSSEC key looks like this:



Once the key is added and synchronized on the registry’s DNS servers, you can test DNSSEC funconality at http://dnssec-debugger.verisignlabs.com/

Now, back on the mailserver hosting our domain we have to create a hash of the SSL-certificate:

Using this value  we can add the DANE TLSA record for our mailserver in the DNS zone:

In powerdns, add a record:

Name	_25._tcp.mail.example.com (replace mail.example.com with your real mx hostname)
Type	TLSA
Content	3 0 1 02059728e52f9a58a235584e1ed70bd2b51a44024452ec2ba0166e8fb1d1d32b

the “3 0 1” means: “we took a full domain-issued certificate, and created a sha256 hash of it”. For other possible values see RFC6698 section 7.2 – 7.4.

Now we can test the new DANE TLSA records at https://www.tlsa.info

And finally, let’s test it from another postfix box. For this to work, the sending server must use a DNSSEC resolver (for example unbound) and postfix >=2.11 with DANE enabled:

and voilà, our connection is now verified even though we’re using a self-signed certificate:

postfix/smtp[17787]: Verified TLS connection established to mail.example.com[...]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

References:

• https://www.kernel-error.de/postfix/postfix-dane-tlsa
• https://sys4.de/de/blog/2014/05/24/einen-tlsa-record-fuer-dane-mit-bind-9-publizieren/

Overwrite tmnet DNS in router DIR-615

In the past, I have read into how the site was "blocked" in Malaysia where web surfers unable to load some websites. I don't know what is the fuss about it as it certainly create a lot of talks in the social websites. The term blocked would probably be at IP level where if the access by a machine to a address of IP a.b.c.d is unreachable, then that is a really blocked. But the funny things is, some ISPs in malaysia do not actually blocked the IPs but merely make some hostname unable to resolve into IP.

So in this article, I'm gonna show you how you can get back your freedom. There are many public DNS out there. Just google public DNS would give you a lot of list. In fact, google has public DNS too. When you choose the DNS, be sure it is public trust able and speed of your machine to the DNS server is matter when you want a quick web browser able to determine the IP address quickly.

With that said, I'm gonna show you how you can overwrite the DNS entries in tmnet router DIR-615. You need to ssh to your router in order to accomplish this. I have tried many times in the web interface, though it has text box for you to specify, apparently you cannot specify to the list that you want, it always default to tmnet DNS. This is annoying!

What you need is a terminal, ssh program installed, username = operator , password = h566UniFi

After you have ssh into the router, these are all the steps you need to do.

# cat /var/etc/resolv.conf
# This file is generated by gen_resolv.php
nameserver 1.9.1.9
nameserver 202.188.0.133

# sed 's/1.9.1.9/192.168.10.2/' -i /var/etc/resolv.conf
# sed 's/202.188.0.133/8.8.8.8/' -i /var/etc/resolv.conf
# cat resolv.conf
# This file is generated by gen_resolv.php
nameserver 192.168.10.2
nameserver 8.8.8.8

So I have an internal IP because there is a internal DNS service running. 8.8.8.8 would be the google public DNS.

Well, that's all you need, the site where it is unable to resolve to an IP, you can check by ping to the hostname, it should return a valid IP. That's all folks, I hope you learn something and gain back your right.