Requirement of a nameserver to answer?

Requirement of a nameserver to answer?

Post by Ian Northeas » Sun, 29 Jun 2003 21:46:12



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

 
 
 

Requirement of a nameserver to answer?

Post by Fernando Go » Wed, 02 Jul 2003 00:35:52


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


>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?)

Quote:>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.

Quote:>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

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

 
 
 

Requirement of a nameserver to answer?

Post by Ian Northeas » Wed, 02 Jul 2003 05:28:56



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

> >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.

Quote:> >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.

Quote:> 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.

Quote:> 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

 
 
 

Requirement of a nameserver to answer?

Post by Mark Andre » Wed, 02 Jul 2003 09:37:01




Quote:>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

        Yet another broken load balancer.

        Port unreachable is not the correct response to not having
        a particular type.

        Mark

 
 
 

Requirement of a nameserver to answer?

Post by Jonathan de Boyne Pollar » Wed, 02 Jul 2003 06:48:33


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.

<URL:http://www.kb.cert.org./vuls/id/714121>
<URL:http://sendmail.org./compiling.html#DNS>

 
 
 

Requirement of a nameserver to answer?

Post by Jonathan de Boyne Pollar » Wed, 02 Jul 2003 06:31:41


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.

 
 
 

Requirement of a nameserver to answer?

Post by Fernando Go » Wed, 02 Jul 2003 19:06:12




>>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

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

 
 
 

Requirement of a nameserver to answer?

Post by Fernando Go » Wed, 02 Jul 2003 19:37:24


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


>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.
><URL:http://www.kb.cert.org./vuls/id/714121>
><URL:http://sendmail.org./compiling.html#DNS>

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

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

 
 
 

Requirement of a nameserver to answer?

Post by Barry Margoli » Wed, 02 Jul 2003 23:06:08




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

>>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.
>><URL:http://www.kb.cert.org./vuls/id/714121>
>><URL:http://sendmail.org./compiling.html#DNS>

>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.

--

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.

 
 
 

Requirement of a nameserver to answer?

Post by Ian Northeas » Thu, 03 Jul 2003 04:12:44





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

> >>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.
> >><URL:http://www.kb.cert.org./vuls/id/714121>
> >><URL:http://sendmail.org./compiling.html#DNS>

> >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:)

Quote:> 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

 
 
 

Requirement of a nameserver to answer?

Post by Ian Northeas » Thu, 03 Jul 2003 04:14:31





> >>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

 
 
 

Requirement of a nameserver to answer?

Post by Barry Margoli » Thu, 03 Jul 2003 05:15:32







>> >>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.

--

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.

 
 
 

Requirement of a nameserver to answer?

Post by Jonathan de Boyne Pollar » Thu, 03 Jul 2003 22:01:25


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> <URL:http://www.kb.cert.org./vuls/id/714121>
JdeBP> <URL:http://sendmail.org./compiling.html#DNS>

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.

 
 
 

Requirement of a nameserver to answer?

Post by Fernando Go » Fri, 04 Jul 2003 23:46:49


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


>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.)

Quote:>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.

Quote:>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.

Quote:>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

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

 
 
 

Requirement of a nameserver to answer?

Post by Paul Ja » Sat, 05 Jul 2003 01:42:31



> 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.

Nor can you blame the kernel separately from the DNS server if it's
some kind of integrated DNS-dedicated device that has no such internal
distinction.

paul

 
 
 

1. root nameserver hardware requirements

some guys here on earth are setting up a set of nameservers to take over
dns duties for a couple of isps.  they have a few thousand zones each.
they expect moderate to large growth.

the implementation they finalized on was two cobalt's running linux as
"the primary" with a hardware frontend load balancer and a netapp
(shared with other applications) for common access to the zone files.

i claim that is far more hardware than necessary and needlessly
complex.

i am wondering if anyone knows what an average hardware configuration
is for a root nameserver.  this would be a nice point of reference.
also, if performance is an issue, would it be wise to keep the
recursive/caching and nonrecursive functions on seperate machines?

i have searched the bind-users mailing list and have found several
posts to support my view, but knowing what the root servers are setup
would be very helpful in arguing my position.

any input is greatly appreciated.

-jacob martinson

2. 2 CDROMS HAVE I

3. Lame Nameserver / Non-authoritative answer weird problem.

4. FS: book--Delivering Voice over IP Networks

5. how to see which nameserver should give answer for reverse lookup ?

6. === Y2K Compliance Kit In Europe ==

7. How can I make resolver to go to next nameserver while one is not answering

8. Need old documents for PDP, Interdata, DG

9. Internal nameserver returns SOA pointing to external nameserver

10. difference in between my nameserver and mainly used nameserver...

11. Nameserver to Nameserver Queries

12. Local Nameserver and Internet Nameserver