DNS Not Resolving PTR Records



  • I have two dns servers sitting behind a pfsense haproxy for load balancing. I am also using the DNS resolver with forwarding turned off and some ACLs for my private networks to resolve DNS zones delegated to me. Forward lookups work fine using dig however reverse lookups fail with the following error; "Question section mismatch: got 0.0.0.0.in-addr.arpa/PTR/IN". Reverse queries done directly on the servers work fine. My domain is th3t1ck.com. Anyone have any ideas?


  • LAYER 8 Global Moderator

    "My domain is th3t1ck.com"

    What does that have to do with a PTR??  Did you setup your in-addr.arpa zone?

    Are you talking rfc1918 space or public space?  Was the PTR actually delegated to you??



  • I included my domain in case someone wanted to "dig" around.
    We are talking about public address space and I have a reverse zone setup. The IPs are delegated to me by my ISP and it worked before I moved my DNS servers behind pfsense.


  • LAYER 8 Global Moderator

    I am thinking you don't actually understand how PTR work..

    ;; QUESTION SECTION:
    ;93.169.11.172.in-addr.arpa.    IN      PTR

    ;; AUTHORITY SECTION:
    169.11.172.in-addr.arpa. 3600  IN      SOA    ns1.swbell.net. rm-hostmaster.ems.att.com. 1 10800 900 604800 7200

    Doesn't look delegated to your ns to me for that address

    So I show network delegated to you I assume… You would have to adjust the NS the PTR points at arin..

    NetRange:      172.11.169.88 - 172.11.169.95
    CIDR:          172.11.169.88/29
    NetName:        SBC-172-11-169-88-29-1212053540
    NetHandle:      NET-172-11-169-88-1
    Parent:        SIS-80-8-2012 (NET-172-0-0-0-1)
    NetType:        Reassigned
    OriginAS:     
    Customer:      Daniel <snipped>If the address space has been delegated, then on your arin account you can adjust the NS for the reverse
    https://www.arin.net/resources/request/reversedns.html

    Depending on how they delegated it to you, they might not have given you control of the NS?  I delegate small chunks of the /16 I manage.. And I don't give them NS control.. Who controls address space would have to modify your PTRs..

    As you see above I don't show any PTR for IP that domain resolve too...  Nor do I even see you pointing the NS for the domain to your network.. Current that domains NS are

    ;; ANSWER SECTION:
    th3t1ck.com.            3600    IN      A      172.11.169.93

    ;; AUTHORITY SECTION:
    th3t1ck.com.            3593    IN      NS      pdns08.domaincontrol.com.
    th3t1ck.com.            3593    IN      NS      pdns07.domaincontrol.com.

    If you want some advice.. Please do not host your own NS if you don't fully understand how it all works.. There is rarely any reason to host your own NS to the public net.. There are plenty of places to do that either for free or small fee..


    </snipped>



  • The nameservers you see are GoDaddy. They are slaves to my master server but they are no longer getting updates since I moved it behind pfsense. Again, this was all working fine before I moved it behind pfsense. Looks like I'll just forget about pfsense if this is the treatment you give folks asking for help.

    P.S. - I like how you enjoy putting people down instead of helping them. I see you do that quite often.



  • +1 for that.

    Johnpoz, you are often helpful here, but then you have to ruin it with arrogance and disrespect.
    It's unnecessary. Leave the negativity out and you'd be a hero.


  • LAYER 8 Global Moderator

    And again what does that have to do with the Reverse or PTR??  That is the forward.. I showed you who the SOA is for the PTR..  They have no records for your IP.  If you have been delegated the control in arin, then you can setup the NS for the reverse zone.  If not then you would need the actual owners of the IP space to set them up for you.

    You have lots of things wrong with your domain.. For starters no reverse for your authoritative ;)  Which is what your seem to be working.  2nd your "slaves" do not have NS records for your SOA.. But you have glue for ns01.th3t1ck.com.

    As to putting down??  No freaking idea what your taking about.. Just posting what I see.. and helping you understand what you have questions on.. Did I not point out exactly how to get your reverse working?  Which clearly you don't seem to understand how reverse zones are delegated - since if you did, why are you here? ;)

    If your going to run your SOA on your network, it should at least answer for what its authoritative for.  And your also not accepting email for your dnsadmin you have listed in your SOA…

    So again if you want to setup PTR for you IPs in your /29 you will have to setup the NS at arin, if that has been delegated to you.  Or you will have to get with the parents of your IP block to either delegate the NS role to you or have them create the PTRs.



  • Isn't there 2 issues here ?

    1. PTR resolving (maybe an expired Zone due to 2')
    2. Missing update to the GD DNS slaves

    Re 2:
      Did you allow TCP/53 towards GD

    Did you change the IP that GD saw your master as , when moving behind the pf' ?
      Ie. If GD used bind9 they would prob. have an ACL for who was allowed to "push" updates.

    /Bingo


  • LAYER 8 Global Moderator

    "1. PTR resolving (maybe an expired Zone due to 2')"

    What part do you people not understand about how PTR zones work? The current SOA for that zone is not him, nor is it a slave of his that is for sure..

    169.11.172.in-addr.arpa. 3600  IN      SOA    ns1.swbell.net. rm-hostmaster.ems.att.com. 1 10800 900 604800 7200

    ;; QUESTION SECTION:
    ;169.11.172.in-addr.arpa.      IN      NS

    ;; ANSWER SECTION:
    169.11.172.in-addr.arpa. 7200  IN      NS      ns3.sbcglobal.net.
    169.11.172.in-addr.arpa. 7200  IN      NS      ns1.swbell.net.
    169.11.172.in-addr.arpa. 7200  IN      NS      ns2.swbell.net.

    ;; QUESTION SECTION:
    ;1.1.164.151.in-addr.arpa.      IN      PTR

    ;; ANSWER SECTION:
    1.1.164.151.in-addr.arpa. 7112  IN      PTR    ns1.swbell.net.



  • @johnpoz:

    "1. PTR resolving (maybe an expired Zone due to 2')"

    What part do you people not understand about how PTR zones work? The current SOA for that zone is not him, nor is it a slave of his that is for sure..

    Well i didn't study the zone delegation (my bad)  ;)

    But i actually had a similar prob. some years ago , that the zone was expired  (8days) , due to an ip addy change , and no zone updates.

    I suppose this still leaves the zone update issue (2)

    /Bingo


  • LAYER 8 Global Moderator

    His ns1 that is the SOA being out of sync with his slaves has zero to do with the Reverse zone/PTR.. His forward has zero to do with the reverse zone.  He looks to have the /29 delegated to him in arin.

    He needs to point to the NS he wants to use as the authoritative for that PTR, or he needs to get with his netblocks parent to setup the PTR for him.  Really has zero to do with whatever he is doing in a forward zone.  His forward zone could be non existent for all it matters for reverse or in-addr.arpa. zones..

    Now he could whatever he wanted for his local machines an that zone.. But to the public that netblock currently does not point to any server that are under his control.. Unless he has access to the swbell network AT&T..


Log in to reply