# Resolving zone domain



## Seeker (Jul 19, 2009)

I've set one namserver in my registrar's panel.
It had 2 fields for NS and IP:

ns1.domain.com
5.5.5.5

I've set BIND with zone for domain.com
When domain.com is requested in browser(using TOR for testing), it should first hit my port 53 to get DNS info and then port 80 (share same IP)

Now, around 2 days passed and I still can't resolve domain.com from the outside(using TOR for testing)
Anyway, I've set up PF to log any access to port 53
There is none requests to port 53!!

And when I put IP instead of a URL
http://5.5.5.5/
It immediately shifts to http://domain.com/ and then results in error message "can't resolve http://domain.com/"
Now that is VERY confusing!

http://5.5.5.5/ always loaded page before!
What exactly is shifting http://5.5.5.5/ to http://domain.com/


----------



## Seeker (Jul 20, 2009)

I've used zoneedit free nameservers so now am accessile BUT
I wana see what kind of zone it created

I've read about named-xfer tool but am unable to locate it, nor in port nor anywhere.
How could it be?!
Where is named-xfer tool?


----------



## SirDice (Jul 20, 2009)

Just use dig:
`$ dig @mydomainserver mydomain.org AXFR`


----------



## DutchDaemon (Jul 20, 2009)

Which should result in 'Transfer failed', unless those nameservers are lacking in security ..


----------



## Seeker (Jul 20, 2009)

It does results in 'Transfer failed'

```
# dig mydomainserver mydomain.org AXFR
```

But if "*@*" is not omited like:

```
# dig @mydomainserver mydomain.org AXFR
```
Then info is listed and SOA 2 times?? Very unneeded. Bug?


----------



## DutchDaemon (Jul 20, 2009)

Running the command without @ will simply run [cmd=]dig A domain1 domain2[/cmd]. That's something different.


----------



## Seeker (Jul 20, 2009)

DutchDaemon said:
			
		

> Running the command without @ will simply run [cmd=]dig A domain1 domain2[/cmd]. That's something different.



I see...

```
# dig @mydomainserver mydomain.org AXFR
```
Did not resulted in 'Transfer failed'.
You say that is bad? Why? PS: NS are zoneedit.

How do I put all this in one command:

```
# dig +cl +multiline example.com soa
# dig +cl +multiline example.com a
# dig +cl +multiline example.com ns
# dig +cl +multiline example.com mx
```
As I can get *only* soa or a or ns or... you get it... record.

PS: look once again *post above* as I've edited it.


----------



## DutchDaemon (Jul 20, 2009)

Seeker said:
			
		

> ```
> # dig @mydomainserver mydomain.org AXFR
> ```
> Did not resulted in 'Transfer failed'.
> You say that is bad? Why?



Nameservers should only allow zone transfers to trusted parties (trusted/identified by either IP address or TSIG keys). Getting someone's complete zonefile provides an excellent starting point for hackers who want to profile a network (to find attack vectors, to inject spoofed packets or even to pose as an authoritative nameserver serving altered data). Maybe you are 'trusted' to the Zoneedit nameservers in some way.


----------



## Seeker (Jul 20, 2009)

I guess they trust me based on my IP address.

But aren't zones supposed to be public information?
It is intended for public to reach you by resolving domains to your machine IP.
Same for mx records...
All those records are public and are forming zone.
So, if one gets 'Transfer failed', all he needs to do is query step by step A, then NS, then MX..., in a same way how apps would do it, in order to recreate zone


----------



## DutchDaemon (Jul 20, 2009)

Zone files themselves are not meant to be public information. When someone queries a nameserver for a particular record they will already know the hostname -- they just want the IP address for it, or the domain's MX records. The entity querying the nameserver will know nothing else about the zone. The same goes for email: you know you're sending mail to someone@some.domain, but you have no idea whether someoneelse@some.domain exists, unless you get your hands on that domain's user list / virtusertable / overview of mailboxes. And no one in their right mind is handing out their virtusertable, I can assure you.

Querying NS and MX records will only get you so many hosts, some of which may not even be part of the domain at all. Querying A records has no point, unless you know which A records to query ... Without knowing the hostnames, you won't have anything to query. That's why you want them in a non-transferable zone file. Hostnames are available on a need-to-know basis.


----------



## Seeker (Jul 20, 2009)

Ok, I see.
Before I continue, just to say that everything is working now...

Can you help me explain this:
At start, I've setup BIND, with zone for *domain.com*
Then I've logged in my registrar control panel, clicked on add new nameserver and supplied:

ns1.domain.com
5.5.5.5

After that my domain was unresolvable, from the outside(internet), but fully resolvable locally.

my next step was to use zoneedit.com's NS-es and then all started to work.
Now, I am third NS and am slaving zone.


----------



## SirDice (Jul 20, 2009)

Seeker said:
			
		

> ns1.domain.com
> 5.5.5.5


Did you actually use your own Internet IP address?

If you are behind a router, did you forward both tcp and udp port 53?


----------



## Seeker (Jul 20, 2009)

I've used directly accessible public IP.
The guy at registrar manually pinged my IP, so he could be sure my ISP isn't blocking.
He reached DNS ports 53 with both protocols tcp and udp.


----------

