Re: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
On 2013-12-06, at 12:11 , Chris Thompson wrote: > > The sense in which BIND "forces use of TCP" is that when it gets an > IXFR request over UDP, it always just replies with the current SOA. > It doesn't bother to work out whether an incremental transfer is > possible and if so whether it would fit into the UDP payload. > > Of course, if the client's supplied SOA serial is the same, this > response indicates that no zone transfer is needed. Yeah, the mechanism is clear. I was curious about the why rather than the how. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
On Dec 5 2013, Matthew Pounsett wrote: On 2013-12-05, at 01:37 , Mark Andrews wrote: Note, named will for the use of TCP in its UDP response. s/for/force/ Always? Regardless of response size? Interesting. What's the rationale for doing it that way? Just to clarify, RFC 1995 says | Transport of a query may be by either UDP or TCP. If an IXFR query | is via UDP, the IXFR server may attempt to reply using UDP if the | entire response can be contained in a single DNS packet. If the UDP | reply does not fit, the query is responded to with a single SOA | record of the server's current version to inform the client that a | TCP query should be initiated. The sense in which BIND "forces use of TCP" is that when it gets an IXFR request over UDP, it always just replies with the current SOA. It doesn't bother to work out whether an incremental transfer is possible and if so whether it would fit into the UDP payload. Of course, if the client's supplied SOA serial is the same, this response indicates that no zone transfer is needed. -- Chris Thompson Email: c...@cam.ac.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
In message <2e1626be-94f8-44e8-a73c-6521c44ba...@conundrum.com>, Matthew Pounsett writes: > > On 2013-12-05, at 01:37 , Mark Andrews wrote: > > > > >>> Note, named will for the use of TCP in its UDP response. > > > > s/for/force/ > > Always? Regardless of response size? Interesting. What's the rationale > for doing it that way? Because TCP is always checksummed. UDP isn't. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
On 2013-12-05, at 01:37 , Mark Andrews wrote: > >>> Note, named will for the use of TCP in its UDP response. > > s/for/force/ Always? Regardless of response size? Interesting. What's the rationale for doing it that way? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
In message , Matthew Pounsett writes: > > On 2013-12-04, at 21:22 , Mark Andrews wrote: > > > > > The options are processed left to right so the +notcp has to be > > after the ixfr=. > > There are two reasons I don't understand why this is the case. > > 1) Since there is only one query in the command, I don't understand why > "left to right" matters. If you could do something like > dig IN IXFR= example.com +notcp IN A www.example.com +tcp > then sure.. because changing the order of options would be ambiguous, but > you can't do that. Because tcp mode isn't a tri state (unset, true, false) but a boolean and ixfr= changes it the default (false) to true. IXFR is documented as setting TCP mode. > 2) dig is generally very forgiving of argument order, so I don't see why > the location of +notcp would be any different. In these examples the arguments are independent of each other and set a single thing (even +short). The are others that set multiple things. > > dig +short @8.8.8.8 IN A cbc.ca > 159.33.3.85 > > > dig @8.8.8.8 IN A cbc.ca +short > 159.33.3.85 > > > dig IN A cbc.ca +short @8.8.8.8 > 159.33.3.85 > > > > Note, named will for the use of TCP in its UDP response. s/for/force/ > What verb is missing from this sentence? > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
On 2013-12-04, at 21:22 , Mark Andrews wrote: > > The options are processed left to right so the +notcp has to be > after the ixfr=. There are two reasons I don't understand why this is the case. 1) Since there is only one query in the command, I don't understand why "left to right" matters. If you could do something like dig IN IXFR= example.com +notcp IN A www.example.com +tcp then sure.. because changing the order of options would be ambiguous, but you can't do that. 2) dig is generally very forgiving of argument order, so I don't see why the location of +notcp would be any different. > dig +short @8.8.8.8 IN A cbc.ca 159.33.3.85 > dig @8.8.8.8 IN A cbc.ca +short 159.33.3.85 > dig IN A cbc.ca +short @8.8.8.8 159.33.3.85 > Note, named will for the use of TCP in its UDP response. What verb is missing from this sentence? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
The options are processed left to right so the +notcp has to be after the ixfr=. e.g. dig ixfr= zone +notcp Note, named will for the use of TCP in its UDP response. Below is a query log of ixfr requests with and without tcp. 'T' indicates a TCP connection. 05-Dec-2013 13:11:35.681 client ::1#55802 (dv.isc.org): view external: query: dv.isc.org IN IXFR -ET (::1) 05-Dec-2013 13:11:49.664 client ::1#50513 (dv.isc.org): view external: query: dv.isc.org IN IXFR -E (::1) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)
I'm trying to debug an IXFR problem with a client, and using dig in its place to compare IXFR requests between it and the misbehaving client. I noticed that when I do an IXFR with dig it defaults to TCP rather than UDP. I tried forcing it over with +notcp but I still get a TCP query. >From the man page: +[no]tcp Use [do not use] TCP when querying name servers. The default behavior is to use UDP unless an AXFR or IXFR query is requested, in which case a TCP connection is used. This implies to me that it is simply the default to use TCP for *XFR, but one should be able to override it. Is that the correct interpretation of the man page? Even if that is not the correct interpretation, it seems to me that since IXFRs can and do happen over UDP, it should be possible to tell dig to do that. Is this a bug, or a design flaw? - Matt ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
