Hi
almost a week ago I wrote to Switch about this problem, but I didn't get an answer so far, so I wondered whether you guys/girls knew more about this:
Warnings Test: Server doesn't listen/answer on port 53 for TCP protocol ==> ns1.tsunamihost.ch./217.150.245.14 ==> ns2.tsunamihost.ch./217.160.142.96
According to RFC 1035, Chapter 4.2
"The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance."
ftp://ftp.ietf.org/rfc/rfc1035.txt
Why do I need to allow TCP connections? To me, TCP is AXFR and I'm NOT going to allow AXFR for everyone.
Daniel
On Wed, Dec 14, 2005 at 10:40:15PM +0100, Daniel Lorch wrote:
Hi
almost a week ago I wrote to Switch about this problem, but I didn't get an answer so far, so I wondered whether you guys/girls knew more about this:
Warnings Test: Server doesn't listen/answer on port 53 for TCP protocol ==> ns1.tsunamihost.ch./217.150.245.14 ==> ns2.tsunamihost.ch./217.160.142.96
According to RFC 1035, Chapter 4.2
"The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance."
ftp://ftp.ietf.org/rfc/rfc1035.txt
Why do I need to allow TCP connections? To me, TCP is AXFR and I'm NOT going to allow AXFR for everyone.
Because of IPv6 and the bloat it adds to DNS.
Why do I need to allow TCP connections? To me, TCP is AXFR and I'm NOT going to allow AXFR for everyone.
Just allow them for the SWITCH machines. No biggie. Something like:
acl transfer-nets { ...; 130.59.211.10/32; 130.59.10.30/32; ...; };
or whichever machines at SWITCH are trying to do the transfer.
On Wed, 14 Dec 2005 22:55:24 +0100, Mickey Coggins mick@coggins.org said:
Why do I need to allow TCP connections? To me, TCP is AXFR and I'm NOT going to allow AXFR for everyone.
Just allow them for the SWITCH machines. No biggie. Something like:
acl transfer-nets { ...; 130.59.211.10/32; 130.59.10.30/32; ...; };
or whichever machines at SWITCH are trying to do the transfer.
SWITCH doesn't do any zone transfers as part of the delegation check. That would be fun, though :-)
This thread is about *queries* on top of TCP.
-- Alex
SWITCH doesn't do any zone transfers as part of the delegation check. That would be fun, though :-)
Doesn't SWITCH do any "RIPE Region Hostcount" anymore? This used to trigger a log of domain transfers on my DNS-Servers back in the time. Didn't check recently whether this is still the case or not.
Regards,
Jean-Pierre
On Fri, 16 Dec 2005 10:44:33 +0100, Jean-Pierre Schwickerath swinog@hilotec.net said:
SWITCH doesn't do any zone transfers as part of the delegation check. That would be fun, though :-)
Doesn't SWITCH do any "RIPE Region Hostcount" anymore?
Yes, we do (in fact, this month's run has just started yesterday :-) But this is completely independent of the checks performed by the domain name registry.
-- Alex
On Fri, 16 Dec 2005 12:33:49 +0100, Daniel Lorch daniel@lorch.cc said:
But this is completely independent of the checks performed by the domain name registry.
Is AXFR a requirement or not? Your FAQ doesn't say anything, your helpdesk doesn't respond, please, I need to know :)
As has been pointed out to you in this thread already, TCP port 53 is not only used for zone transfers. We do *not* check whether zone transfers are allowed on your servers. What we do check is whether your servers accept regular (non-AXFR/IXFR) queries on top of TCP.
DNS is specified to work over UDP and TCP. A resolver is not strictly required to use UDP for a query. One situation where TCP is used has been described already (after receiving a truncated response).
Note that we don't require anything. The name server check is intended to help the user to determine whether his configuration is likely going to work or not. It does not prevent you from activating your domain (contrary to the old registry system). This particular check informs you that your server will not interoperate with all possible DNS implementations and may prevent certain responses from being received by a resolver without truncation. (I do agree that the tool should supply better explanations, though. I believe this is being worked on).
-- Alex
Alexander Gall wrote:
DNS is specified to work over UDP and TCP. A resolver is not strictly required to use UDP for a query. One situation where TCP is used has been described already (after receiving a truncated response).
And remember that this "trick" (DNS man-in-the-middle sending back a response with the TC bit set to force a real TCP 3-way-handshake) is used by some DDoS mitigation devices to detect forged queries and protect DNS servers. If your resolver is firewalled too heavily, you may not be able to access some "protected" sites.
Nico.
Hi
As has been pointed out to you in this thread already, TCP port 53 is not only used for zone transfers. We do *not* check whether zone transfers are allowed on your servers. What we do check is whether your servers accept regular (non-AXFR/IXFR) queries on top of TCP.
Thanks, that's all I needed to know :)
Daniel
Hi
Doesn't SWITCH do any "RIPE Region Hostcount" anymore?
Yes, we do (in fact, this month's run has just started yesterday :-)
Doesn't hostcount mean, that you get the in-addr.arpa zone? Why are you AXFR-ing all zones, then?
Dec 15 18:50:53 jana pdns[13545]: AXFR of domain 'XXX.ch' denied to 130.59.1.80 Dec 15 18:50:53 cuba pdns[11449]: AXFR of domain 'XXX.ch' denied to 130.59.1.80
Daniel
On Fri, 16 Dec 2005 12:37:12 +0100, Daniel Lorch daniel@lorch.cc said:
Doesn't SWITCH do any "RIPE Region Hostcount" anymore?
Yes, we do (in fact, this month's run has just started yesterday :-)
Doesn't hostcount mean, that you get the in-addr.arpa zone?
No. Please have a look at http://www.ripe.net/info/stats/hostcount/.
Bill Manning used to sweep the in-addr.arpa space (http://www.isi.edu/~bmanning/in-addr-audit.html), but I think this stopped in 2001.
-- Alex
On Wed, 14 Dec 2005, Daniel Lorch wrote:
Hi
almost a week ago I wrote to Switch about this problem, but I didn't get an answer so far, so I wondered whether you guys/girls knew more about this:
Warnings Test: Server doesn't listen/answer on port 53 for TCP protocol ==> ns1.tsunamihost.ch./217.150.245.14 ==> ns2.tsunamihost.ch./217.160.142.96
According to RFC 1035, Chapter 4.2
"The DNS assumes that messages will be transmitted as datagrams or in a byte stream carried by a virtual circuit. While virtual circuits can be used for any DNS activity, datagrams are preferred for queries due to their lower overhead and better performance."
ftp://ftp.ietf.org/rfc/rfc1035.txt
Why do I need to allow TCP connections? To me, TCP is AXFR and I'm NOT going to allow AXFR for everyone.
Besides AXFRs, as stated by the RFC, there may be perfectly valid reasons for DNS over TCP, for example when answers exceed 512 bytes. As for AXFRs from unwanted sources, you can filter them with bind ACLs, as explained in another post.
Regards,
- yann
Hi
Besides AXFRs, as stated by the RFC, there may be perfectly valid reasons for DNS over TCP, for example when answers exceed 512 bytes. As for AXFRs from unwanted sources, you can filter them with bind ACLs, as explained in another post.
How does a client know in advance whether the DNS answer will exceed 512 bytes? Just curious.
If "DNS over TCP" is a requirement, then I'm going to move axfrdns to another IP and run "DNS over TCP" on the nameserver's IP. An official statement from Switch on what exactly is required would be nice :)
Daniel
Hi,
On Thu, 15 Dec 2005, Daniel Lorch wrote:
Hi
Besides AXFRs, as stated by the RFC, there may be perfectly valid reasons for DNS over TCP, for example when answers exceed 512 bytes. As for AXFRs from unwanted sources, you can filter them with bind ACLs, as explained in another post.
How does a client know in advance whether the DNS answer will exceed 512 bytes? Just curious.
Indeed, the client has no way to know in advance. When it happens, the server returns an answer with the truncated bit set (TC). The client retries then over TCP.
- yann
-
Alexander Gall -
Claudio Jeker -
Daniel Lorch -
Jean-Pierre Schwickerath -
Mickey Coggins -
Nicolas FISCHBACH -
Yann Berthier