Requirement of a nameserver to answer? - TCP-IP

This is a discussion on Requirement of a nameserver to answer? - TCP-IP ; I can't find this in the DNS RFCs but maybe I havn't looked hard enough. I have encountered a nameserver which when sent a correctly formulated AAAA query for a name it is authoritative for responds with an ICMP "port ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Requirement of a nameserver to answer?

  1. Requirement of a nameserver to answer?

    I can't find this in the DNS RFCs but maybe I havn't looked hard enough.

    I have encountered a nameserver which when sent a correctly formulated
    AAAA query for a name it is authoritative for responds with an ICMP
    "port unreachable" message. I would expect a DNS reply containing 0
    answers. A corresponding A query is answered normally.

    The name in question is ftp.inttraworks.inttra.com and both
    authoritative nameservers behave the same. An SOA or NS query (this name
    is a delegated subdomain) also elicits a port unreachable.

    My question is, is this acceptable behaviour? All the DNS RFCs seem to
    discuss exactly what should be put in responses but not any requirement
    to send a response. It seems to be assumed that all queries will be
    replied to but I can't find it stated anywhere.

    Does anyone know if there is a rule on this point? Any pointer to an RFC
    which covers this would be appreciated.

    BTW this causes trouble with the FTP client in AIX which tries an AAAA
    lookup first and waits over a minute before trying an A if it doesn't
    get a response. We have had to disable IPV6 lookups completely on the
    client machine to "fix" this.

    Regards, Ian

  2. Re: Requirement of a nameserver to answer?

    On Sat, 28 Jun 2003 13:46:12 +0100, Ian Northeast
    wrote:

    >I have encountered a nameserver which when sent a correctly formulated
    >AAAA query for a name it is authoritative for responds with an ICMP
    >"port unreachable" message. I would expect a DNS reply containing 0
    >answers.


    I'd expect the same.
    An "ICMP port unreacheable" error indicates that no process is
    listening on that port. If the nameserver has no AAAA records, it
    should reply the query with 0 answers, *not* with an ICMP error.

    Are you sure you get an ICMP error because of the request for AAAA
    records? (Could you provide a packet trace?)


    >My question is, is this acceptable behaviour? All the DNS RFCs seem to
    >discuss exactly what should be put in responses but not any requirement
    >to send a response. It seems to be assumed that all queries will be
    >replied to but I can't find it stated anywhere.


    Why shouldn't queries be replied?
    As requests are made using UDP, which is an unreliable protocol, if
    queries are not replied, the resolver will think that the query was
    lost/corrupted, and will retry it.


    >BTW this causes trouble with the FTP client in AIX which tries an AAAA
    >lookup first and waits over a minute before trying an A if it doesn't
    >get a response.


    If the query for AAAA records is replied with 0 answers, then the FTP
    "should" query for A records almost immediately.
    If the resolver gets an "ICMP port unreacheable", it'd return an error
    to the FTP client, which would then query for A records, almost
    immediately.

    I don't understand why the FTP client should wait for about a minute
    before querying A records. Could you provide packet traces?


    --
    Fernando Gont
    e-mail: fernando@ANTISPAM.gont.com.ar

    [To send a personal reply, please remove the ANTISPAM tag]

  3. Re: Requirement of a nameserver to answer?

    Fernando Gont wrote:
    >
    > On Sat, 28 Jun 2003 13:46:12 +0100, Ian Northeast
    > wrote:
    >
    > >I have encountered a nameserver which when sent a correctly formulated
    > >AAAA query for a name it is authoritative for responds with an ICMP
    > >"port unreachable" message. I would expect a DNS reply containing 0
    > >answers.

    >
    > I'd expect the same.
    > An "ICMP port unreacheable" error indicates that no process is
    > listening on that port. If the nameserver has no AAAA records, it
    > should reply the query with 0 answers, *not* with an ICMP error.
    >
    > Are you sure you get an ICMP error because of the request for AAAA
    > records? (Could you provide a packet trace?)


    Running this on my firewall (OpenBSD 3.1) to avoid any confusion caused
    by NAT:

    First I send an A query to show that this works:

    20:50:54.921534 public1-epso1-6-cust57.hers.broadband.ntl.com.47331 >
    attlink.inttra.com.domain: 57985+ A? ftp.inttraworks.inttra.com. (44)
    20:50:55.014234 attlink.inttra.com.domain >
    public1-epso1-6-cust57.hers.broadband.ntl.com.47331: 57985*- 1/0/0 (60)

    Then I send a corresponding AAAA:

    20:52:37.089890 public1-epso1-6-cust57.hers.broadband.ntl.com.17231 >
    attlink.inttra.com.domain: 51047+ AAAA? ftp.inttraworks.inttra.com.
    (44)
    20:52:37.176064 attlink.inttra.com >
    public1-epso1-6-cust57.hers.broadband.ntl.com: icmp: attlink.inttra.com
    udp port domain unreachable

    So it's clearly lying, as it just sent a response from port 53 to my
    earlier A query.

    > >My question is, is this acceptable behaviour? All the DNS RFCs seem to
    > >discuss exactly what should be put in responses but not any requirement
    > >to send a response. It seems to be assumed that all queries will be
    > >replied to but I can't find it stated anywhere.

    >
    > Why shouldn't queries be replied?


    Well I think they should be too, but I can't find anything in an RFC
    which actually mandates it. I'm anticipating a bit of a "discussion"
    with the third party and I'd like to have my ammunition ready. I'd
    thought this would have started already, but the chap who is responsible
    for the application which is running the FTP and has the contact with
    them doesn't seem to be around ATM, I'll have to wait for him to be
    available before I can talk to them.

    > As requests are made using UDP, which is an unreliable protocol, if
    > queries are not replied, the resolver will think that the query was
    > lost/corrupted, and will retry it.
    >
    > >BTW this causes trouble with the FTP client in AIX which tries an AAAA
    > >lookup first and waits over a minute before trying an A if it doesn't
    > >get a response.

    >
    > If the query for AAAA records is replied with 0 answers, then the FTP
    > "should" query for A records almost immediately.


    And if this happens, it does. If it didn't FTP on AIX would be next to
    unusable.

    > If the resolver gets an "ICMP port unreacheable", it'd return an error
    > to the FTP client, which would then query for A records, almost
    > immediately.
    >
    > I don't understand why the FTP client should wait for about a minute
    > before querying A records. Could you provide packet traces?


    There is a slight complication here which I have discovered since my
    original post. All my AIX machines are behind a Checkpoint Firewall-1
    firewall which I do not control but whose configuration I have my
    suspicions about. I think it may be blocking the ICMP port unreachable
    response. I'll check up on this and see if I can get the firewall
    changed but I may not have any success. Of course it's not the resolver
    getting the port unreachable, it is the local caching nameserver, but
    that is running on an AIX machine too.

    However, I can reproduce the problem to some degree here at home, where
    the firewall is mine and works, with a Linux client (SuSE Enterprise
    Server 8, which is United Linux 1.0, with all official patches).
    Pointing this at just the nameserver on the firewall, which is bind
    9.1.3, and issuing the FTP:

    21:01:01.924659 public1-epso1-6-cust57.hers.broadband.ntl.com.4926 >
    attlink.inttra.com.domain: 27347 [1au] AAAA?
    ftp.inttraworks.inttra.com. (55)
    21:01:02.009020 attlink.inttra.com >
    public1-epso1-6-cust57.hers.broadband.ntl.com: icmp: attlink.inttra.com
    udp port domain unreachable
    21:01:05.940996 public1-epso1-6-cust57.hers.broadband.ntl.com.4926 >
    64.9.101.200.domain: 18584 [1au] AAAA? ftp.inttraworks.inttra.com. (55)
    21:01:06.067532 64.9.101.200 >
    public1-epso1-6-cust57.hers.broadband.ntl.com: icmp: 64.9.101.200 udp
    port domain unreachable
    21:01:09.951207 public1-epso1-6-cust57.hers.broadband.ntl.com.4926 >
    attlink.inttra.com.domain: 8977 [1au] AAAA? ftp.inttraworks.inttra.com.
    (55)
    21:01:10.042053 attlink.inttra.com >
    public1-epso1-6-cust57.hers.broadband.ntl.com: icmp: attlink.inttra.com
    udp port domain unreachable
    21:01:12.327981 public1-epso1-6-cust57.hers.broadband.ntl.com.4926 >
    attlink.inttra.com.domain: 4015 [1au] A? ftp.inttraworks.inttra.com.
    (55)
    21:01:12.421536 attlink.inttra.com.domain >
    public1-epso1-6-cust57.hers.broadband.ntl.com.4926: 4015*-% 1/0/1 (71)

    Here the tcpdump is being run against both of the authoritative servers,
    one of which seems to lack a PTR record. The 30s TTL on
    ftp.inttraworks.inttra.com's A record, and the unavailability of the SOA
    and therefore the negative caching TTL, ensure that the query goes out
    every time.

    So it's waiting 11 seconds before issuing the A query, and the ICMP port
    unreachable is getting through. Nowhere near as long as the AIX client
    waits, but still rather long. Interestingly I can't reproduce the
    problem on Solaris, which I regard as a standard "reference" platform.
    That appears to issue the AAAA and A queries simultaneously. This
    certainly avoids this particular problem but I wonder what would happen
    if a name had both RR types which I think is perfectly legal.

    My question isn't really about the behaviour of the FTP client (or I
    would not have posted it here). My concern is whether this nameserver is
    playing by the rules or not, and whether I am in the right when I
    complain to its administrators about it.

    Regards, Ian

  4. Re: Requirement of a nameserver to answer?

    IN> BTW this causes trouble with the FTP client in AIX which tries
    IN> an AAAA lookup first and waits over a minute before trying an
    IN> A if it doesn't get a response.

    FG> If the resolver gets an "ICMP port unreacheable", it'd return
    FG> an error to the FTP client, [...]

    Not necessarily. If it hasn't connect()ed the UDP socket (but is just using
    sendto() instead) it may not even receive any error indication to pass along.

    FG> Are you sure you get an ICMP error because of the request for
    FG> AAAA record?

    I can confirm his report. DNS/UDP datagrams containing "AAAA" queries sent to
    either 64.9.101.200 or 12.44.250.200 will elicit ICMP "port unreachable"
    messages.

  5. Re: Requirement of a nameserver to answer?

    IN> My question is, is this acceptable behaviour?

    It's not _acceptable_, no.

    IN> BTW this causes trouble with the FTP client in AIX which
    IN> tries an AAAA lookup first and waits over a minute before
    IN> trying an A if it doesn't get a response. We have had to
    IN> disable IPV6 lookups completely on the client machine to
    IN> "fix" this.

    This is not a new problem. DNS servers that do Bad Things when sent queries
    whose types they do not recognize are already widely recognised as being
    menaces. Sendmail had to be augmented with the WorkAroundBrokenAAAA option,
    for example, in order to work around one particular clade of such broken DNS
    servers.




  6. Re: Requirement of a nameserver to answer?

    On Tue, 1 Jul 2003 00:37:01 +0000 (UTC), marka@drugs.dv.isc.org (Mark
    Andrews) wrote:

    >>BTW this causes trouble with the FTP client in AIX which tries an AAAA
    >>lookup first and waits over a minute before trying an A if it doesn't
    >>get a response. We have had to disable IPV6 lookups completely on the
    >>client machine to "fix" this.
    >>Regards, Ian

    > Yet another broken load balancer.


    Why do you think so?


    --
    Fernando Gont
    e-mail: fernando@ANTISPAM.gont.com.ar

    [To send a personal reply, please remove the ANTISPAM tag]

  7. Re: Requirement of a nameserver to answer?

    On Mon, 30 Jun 2003 22:48:33 +0100, Jonathan de Boyne Pollard
    wrote:

    >This is not a new problem. DNS servers that do Bad Things when sent queries
    >whose types they do not recognize are already widely recognised as being
    >menaces. Sendmail had to be augmented with the WorkAroundBrokenAAAA option,
    >for example, in order to work around one particular clade of such broken DNS
    >servers.
    >
    >


    Note that both links have to do with wrong responses at the
    application layer, *not* with icmp port unreacheables (they are a
    different "problem").

    Wrong responses have to do with broken DNS servers, while icmp port
    unreacheables have to do with "something" at the kernel.


    --
    Fernando Gont
    e-mail: fernando@ANTISPAM.gont.com.ar

    [To send a personal reply, please remove the ANTISPAM tag]

  8. Re: Requirement of a nameserver to answer?

    In article <3f015ed9.6144416@News.CIS.DFN.DE>,
    Fernando Gont wrote:
    >On Mon, 30 Jun 2003 22:48:33 +0100, Jonathan de Boyne Pollard
    > wrote:
    >
    >>This is not a new problem. DNS servers that do Bad Things when sent queries
    >>whose types they do not recognize are already widely recognised as being
    >>menaces. Sendmail had to be augmented with the WorkAroundBrokenAAAA option,
    >>for example, in order to work around one particular clade of such broken DNS
    >>servers.
    >>
    >>

    >
    >Note that both links have to do with wrong responses at the
    >application layer, *not* with icmp port unreacheables (they are a
    >different "problem").
    >
    >Wrong responses have to do with broken DNS servers, while icmp port
    >unreacheables have to do with "something" at the kernel.


    My guess is that this "something" is a firewall. It's checking the
    application layer contents, and not recognizing it (presumably because it
    hasn't been updated to know about IPv6 DNS record types), and rejecting it
    in a way that it hopes will convince the "bad" client to go away.

    I can't really think of any other likely way in which an application layer
    difference could cause an ICMP error.

    --
    Barry Margolin, barry.margolin@level3.com
    Level(3), Woburn, MA
    *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
    Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

  9. Re: Requirement of a nameserver to answer?

    Barry Margolin wrote:
    >
    > In article <3f015ed9.6144416@News.CIS.DFN.DE>,
    > Fernando Gont wrote:
    > >On Mon, 30 Jun 2003 22:48:33 +0100, Jonathan de Boyne Pollard
    > > wrote:
    > >
    > >>This is not a new problem. DNS servers that do Bad Things when sent queries
    > >>whose types they do not recognize are already widely recognised as being
    > >>menaces. Sendmail had to be augmented with the WorkAroundBrokenAAAA option,
    > >>for example, in order to work around one particular clade of such broken DNS
    > >>servers.
    > >>
    > >>

    > >
    > >Note that both links have to do with wrong responses at the
    > >application layer, *not* with icmp port unreacheables (they are a
    > >different "problem").
    > >
    > >Wrong responses have to do with broken DNS servers, while icmp port
    > >unreacheables have to do with "something" at the kernel.

    >
    > My guess is that this "something" is a firewall. It's checking the
    > application layer contents, and not recognizing it (presumably because it
    > hasn't been updated to know about IPv6 DNS record types), and rejecting it
    > in a way that it hopes will convince the "bad" client to go away.


    It does the same thing with SOA and NS queries. I don't think anything
    should need to be updated to deal with these

    > I can't really think of any other likely way in which an application layer
    > difference could cause an ICMP error.


    It doesn't seem to be a firewall as such but, as Mark Andrews correctly
    deduced, a broken or misconfigured load balancer. I have now had
    (indirect) contact with the admins and apparantly they are "F5 Link
    Controllers using 3DNS and WideIP". I must admit this doesn't mean a
    great deal to me. From what they say this thing is supposed to delegate
    queries for RR types it does not balance to a bind nameserver but it
    seems that this part is not working.

    Anyway it appears that I may have been unnecessarily concerned about
    having to prove my point as these people seem quite ready to admit that
    there is a problem in their setup and tell me that they are trying to
    get it fixed. This, however, appears to be conditional on their vendor's
    admitting there is a problem and the replies I have received may well be
    very helpful with this.

    Many thanks to all,

    Regards, Ian

  10. Re: Requirement of a nameserver to answer?

    Fernando Gont wrote:
    >
    > On Tue, 1 Jul 2003 00:37:01 +0000 (UTC), marka@drugs.dv.isc.org (Mark
    > Andrews) wrote:
    >
    > >>BTW this causes trouble with the FTP client in AIX which tries an AAAA
    > >>lookup first and waits over a minute before trying an A if it doesn't
    > >>get a response. We have had to disable IPV6 lookups completely on the
    > >>client machine to "fix" this.
    > >>Regards, Ian

    > > Yet another broken load balancer.

    >
    > Why do you think so?


    I don't know how he worked it out but he's absolutely right, see my
    other reply.

    Regards, Ian

  11. Re: Requirement of a nameserver to answer?

    In article <3F01DD97.A4E874EE@house-from-hell.demon.co.uk>,
    Ian Northeast wrote:
    >Fernando Gont wrote:
    >>
    >> On Tue, 1 Jul 2003 00:37:01 +0000 (UTC), marka@drugs.dv.isc.org (Mark
    >> Andrews) wrote:
    >>
    >> >>BTW this causes trouble with the FTP client in AIX which tries an AAAA
    >> >>lookup first and waits over a minute before trying an A if it doesn't
    >> >>get a response. We have had to disable IPV6 lookups completely on the
    >> >>client machine to "fix" this.
    >> >>Regards, Ian
    >> > Yet another broken load balancer.

    >>
    >> Why do you think so?

    >
    >I don't know how he worked it out


    Experience -- special-purpose name servers like these often have very
    limited functionality. Step outside these boundaries and you can tell that
    they're not real name servers.

    --
    Barry Margolin, barry.margolin@level3.com
    Level(3), Woburn, MA
    *** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
    Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

  12. Re: Requirement of a nameserver to answer?

    JdeBP> This is not a new problem. DNS servers that do Bad Things
    JdeBP> when sent queries whose types they do not recognize are
    JdeBP> already widely recognised as being menaces. Sendmail had
    JdeBP> to be augmented with the WorkAroundBrokenAAAA option, for
    JdeBP> example, in order to work around one particular clade of
    JdeBP> such broken DNS servers.
    JdeBP>
    JdeBP>
    JdeBP>

    FG> Note that both links have to do with wrong responses at the
    FG> application layer, *not* with icmp port unreacheables (they
    FG> are a different "problem").

    They are different manifestations of the _same_ problem, which is, as I said,
    DNS servers doing Bad Things when sent queries whose types they do not
    recognize. Sending an ICMP "port unreachable" message is just as much "doing
    a Bad Thing" as is (for example) sending an erroneous "no such name" response.

    FG> Wrong responses have to do with broken DNS servers, while
    FG> icmp port unreacheables have to do with "something" at the
    FG> kernel.

    You are assuming a division of labour into "kernel" and "application" that may
    not necessarily actually exist.

    As far as the outside world is concerned, the network node is doing a Bad
    Thing. The _cause_ for it doing a Bad Thing is perhaps interesting,
    especially if one is trying to have a DNS administrator or software vendor
    make the problem go away. But from the perspective of the rest of Internet
    the _problem itself_ is simply that a Bad Thing is being done.

  13. Re: Requirement of a nameserver to answer?

    On Wed, 02 Jul 2003 14:01:25 +0100, Jonathan de Boyne Pollard
    wrote:

    >FG> Note that both links have to do with wrong responses at the
    >FG> application layer, *not* with icmp port unreacheables (they
    >FG> are a different "problem").
    >They are different manifestations of the _same_ problem,


    No. If the problem is a wrong DNS reply, then you can change/patch
    your DNS server software, and your problem will be solved.

    If the problem is about getting ICMP port unreacheables in response to
    DNS queries, then, regardless of what DNS software you run, the
    problem will still persist.

    (Besides that, please not that the OP said the same problem happened
    for SOA and NS records.)


    >which is, as I said,
    >DNS servers doing Bad Things when sent queries whose types they do not
    >recognize. Sending an ICMP "port unreachable" message is just as much "doing
    >a Bad Thing" as is (for example) sending an erroneous "no such name" response.


    As I said before, a wrong DNS reply implies a broken DNS server, while
    an ICMP port unreacheable suggests there's something wrong at *lower*
    layers of the protocol stack.


    >FG> Wrong responses have to do with broken DNS servers, while
    >FG> icmp port unreacheables have to do with "something" at the
    >FG> kernel.
    >You are assuming a division of labour into "kernel" and "application" that may
    >not necessarily actually exist.


    Does your system run an ICMP daemon? If so, it'd be an *exception* to
    the rule, and not the rule itself.


    >As far as the outside world is concerned, the network node is doing a Bad
    >Thing. The _cause_ for it doing a Bad Thing is perhaps interesting,
    >especially if one is trying to have a DNS administrator or software vendor
    >make the problem go away. But from the perspective of the rest of Internet
    >the _problem itself_ is simply that a Bad Thing is being done.


    I don't agree with your analysis. This is a technical-oriented
    newsgroup, not a management-oriented one.
    You cannot solve a problem if you don't know where the problem resides
    in.
    And you cannot blame BIND (for example) for the ICMP port
    unreacheables if it's some kind of firewall/load-balancer/whatever
    that's causing the trouble.


    --
    Fernando Gont
    e-mail: fernando@ANTISPAM.gont.com.ar

    [To send a personal reply, please remove the ANTISPAM tag]

+ Reply to Thread